Privacy/IPAddresses

WebRTC WG has asked for privacy and security considerations around the disclosure of a user's local IP address in WebRTC: Real-Time Communication in Browsers. This wiki is a place to collect some of the considerations.

What might be revealed by a local IP Address

• Persistent identifier (UID)

In many circumstances a local IP address is assigned statically so can be used to uniquely identify the device. It is also possible to target an external STUN or TURN server with a wildcard DNS entry, using an arbitrary subname component that encodes a UID.

• Geographical location

IP address lookup based geolocation can sometimes identify the approximate position of the user such as the City and Country.

• Network infrastructure provider
• Personally identifying information (linkable to other sources of PII, or PII directly)
• De-anonymization / de-pseudonymization
• Extra bits for fingerprinting [see Fingerprinting Guidance]

See persistent identifier.

• Internal network topology behind a NAT

The local IP address and its proximate devices can be scanned via JavaScript for example to identify other devices in the local network that are hosting web servers.

Circumstances when user's local IP may differ from that shown publicly

• VPN
• NAT
• Tor
• Split browsing

Revealing to whom?: Peer, Server, Relay

Any party that can execute JavaScript in the browser can obtain this information. This could not only be a browser extension that supports content scripting such as an ad blocker, but in fact any any first-party or third-party web resource returning HTML content.

This is a "drive-by" attack, i.e. it is triggered whenever a page is simply visited, with no need for further interaction such as clicking on a link. The user would be completely unaware that the information had been obtained.

In the case where activists or journalists are using VPN's or TOR to disguise their activities from the prying eyes of agents of oppressive regimes, this could be a life or death issue because their real (local) IP address would be seen.

Mechanism whereby the local IP Address is exposed

Any embedded iframe can execute JavaScript that makes the browser initiate a transaction to a STUN server that can return the local IP address, along with the external IP and port number that can get through the firewall or NAT back to the browser.

All that is needed is to create a RTCPeerConnection object and a data channel on that, supplying a parsing function to the onicecandidate event handler.

The browser will send a request to the default STUN server which contains the local IP address, which the STUN server sends back. This response is then available to the event handler to be parsed, and that way the local IP address is obtained. This can then be sent to the origin server via an XHR, cookie, image creation etc.

This is already being used on the public web. It has been detected on http://nytimes.com [1] & [2] as part of a gamut of techniques for detecting ad fraud.

Using wildcard DNS entries as persistent identifiers

In addition, as has been pointed out by Daniel Roesler [3] an attack is possible whereby a public STUN server is created with a wildcard DNS entry. The RTCPeerConnection can be supplied with an object specifying any STUN server on the public internet, and an arbitrary prefix can then encode a unique device/user identifier.

var ICE_config= {
  "iceServers": [
    {
      "url": "stun:UID1a4f6e3d76b.tracker.com"
    }
  ]
}

var rtc = new RTCPeerConnection(ICE_config);

The tracking entity would also need to control the relevant DNS server to detect the hostname (containing the tracking UID) requested by the DNS lookup.

For this attack it not even necessary to create a properly functioning STUN server as the UID parsing is carried out within the controlled DNS server.

This is the only Web API I or Daniel are aware of that allows for the arbitrary sending of UDP or TCP packets without this being reported by browser development tools.