WebRTC IP Address Handling Requirements
Extracted elements (24)
Blunt solutions that disable WebRTC entirely or make it significantly harder to use are considered undesirable because WebRTC's peer-to-peer connections facilitate decentralized systems with their own privacy benefits. The document takes a nuanced, mode-based approach instead.
Mode 2 (default route plus associated local addresses) is the recommended default rather than Mode 3 because there is no currently defined mechanism that can both avoid disclosing private local IP addresses and also allow direct peer-to-peer connections. The spec explicitly notes this tension.
Organizations wishing to force all external WebRTC traffic through a proxy or enterprise TURN server can achieve this via organizational firewall policy rather than requiring a stricter default mode. This allows direct connections for intra-organization traffic while still controlling external traffic paths.
WebRTC traffic should not be sent through proxy servers by default because WebRTC typically must use TCP when communicating with proxies, which degrades media quality; additionally, proxies may be overloaded by WebRTC's long-lived, high-bandwidth connections.
The IP address exposure concerns addressed by this document predate WebRTC; Adobe Flash Player provided similar peer-to-peer functionality via RTMFP since 2008, so the privacy problems are not novel to WebRTC.
Applications SHOULD deploy a TURN server with support for both UDP and TCP connections to ensure connectivity can still be established when Mode 3 or Mode 4 is in use.
Applications SHOULD detect when they don't have access to the full set of ICE candidates by checking for the presence of host candidates. If no host candidates are present, Mode 3 or 4 is in use.
Implementations MAY choose stricter modes than the recommended default, for example if a user indicates they want all WebRTC traffic to follow the default route.
In cases where user consent for Mode 1 has not been obtained, Mode 2 (default route plus associated local addresses) SHOULD be used as the default behavior.
In Mode 1, WebRTC MUST use all network interfaces to attempt communication with STUN servers, TURN servers, or peers. This mode converges on the best media path but discloses the most address information.
In Mode 2, once an interface is chosen, the private IPv4 and IPv6 addresses associated with that interface MUST be discovered and provided to the application as host candidates, ensuring direct connections can still be established.
In Mode 2, WebRTC MUST follow the kernel routing table rules so media packets take the same route as HTTP traffic. If an enterprise TURN server is present, the preferred route MUST be through that TURN server.
In Mode 3, associated private IP addresses MUST NOT be provided to the application; only addresses discovered via STUN and TURN on the default route are gathered. This may cause traffic to hairpin through a NAT or fall back to an application TURN server.
In Mode 4, when the application's HTTP traffic is sent through a proxy, WebRTC media traffic MUST also be proxied. If the proxy does not support UDP, or the implementation does not support UDP proxying, UDP is disabled and TCP is used.
Mode 1 (enumerate all addresses) MUST NOT be used unless user consent has been provided. Implementations may tie this consent to getUserMedia device-permission consent or provide a specific consent mechanism.
For multihomed clients using split-tunnel VPNs, WebRTC ICE can discover not only the public address for the VPN but also the ISP public address over which the VPN is running, defeating anonymity goals. This is considered the most significant privacy concern.
If a client is behind a proxy but has direct Internet access, WebRTC STUN checks can bypass the proxy and reveal the client's public IP address. This also applies to enterprise TURN server scenarios where direct Internet access is permitted.
Private IP addresses can act as identifiers allowing web applications running in isolated browsing contexts (normal vs. private browsing) to determine they are on the same device, potentially correlating application sessions and defeating context isolation.
When a client is behind a NAT, WebRTC ICE can reveal private RFC 1918 addresses to web applications. In the worst case, these can contain 24 bits of entropy with an indefinite lifetime, representing a significant fingerprinting surface.
Four modes of WebRTC IP-handling behavior are defined: Mode 1 (enumerate all addresses), Mode 2 (default route plus associated local addresses), Mode 3 (default route only), and Mode 4 (force proxy). Each mode represents a different trade-off between media performance and privacy.
To determine the associated local address for Mode 2, the implementation resolves the web application host URI, creates a UDP socket bound to the wildcard address, connect()s to the remote IP (without sending packets), and queries the local address via getsockname(). This yields the correct source address for the kernel routing path.
To follow normal IP routing (Modes 2 and 3), implementations should bind() peer-to-peer sockets to wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), allowing the OS to route WebRTC traffic identically to HTTP traffic.
WebRTC implementations MUST use ICE to establish peer-to-peer connections, discovering multiple IP addresses via STUN and TURN. The addresses collected typically include an endpoint's private physical or virtual addresses and its public Internet addresses, which are then provided to the web application.
This document describes potential privacy and security concerns associated with WebRTC peer-to-peer connections—including VPN leak, private IP fingerprinting, and proxy bypass—and provides a four-mode framework with recommendations for implementations to address these concerns.