WebRTC leak: when a page finds the address behind your proxy

WebRTC is the part of the browser that makes video calls and peer-to-peer connections work. To connect two people directly, it has to find every route to the machine it runs on, so it asks the network. A page can start that process with a few lines of JavaScript, read the results, and close the connection without ever placing a call.

How a WebRTC leak happens

When a page creates an RTCPeerConnection, the browser gathers ICE candidates: the addresses a peer could use to reach it (MDN). Host candidates are the machine's own network interfaces. Server-reflexive candidates, srflx, come from asking a STUN server "what address do you see me at?" over UDP.

That UDP request is the leak. A browser proxy carries web traffic, and most proxies do not carry UDP at all. So unless the browser is told otherwise, the STUN request goes straight out of your network, and the STUN server answers with your real public address. The page reads it from the candidate. The IETF's RFC 8828 names this case directly: when a client is behind a proxy but direct internet access is permitted, "WebRTC's STUN checks will bypass the proxy and reveal the public IP address of the client."

How it works: Matched to the exit

What a site does with it

A site that sees a proxy exit in Frankfurt and a WebRTC candidate in Vienna knows two things: the visitor is behind a proxy, and where they really are. Every profile on one computer that leaks shows the same home address, so the leak links them all to each other as well, whatever their browser fingerprints say. For anyone keeping accounts apart, that undoes the proxy entirely.

Local addresses were once part of the leak too. Chrome now replaces host candidates with random .local mDNS names, so a page sees a name like a1b2c3….local instead of 192.168.1.20. The real local address still appears once a page has been granted camera or microphone access, and it is the same for every profile on the machine.

How to check for one

Connect through your proxy, then open a WebRTC test page such as BrowserLeaks' WebRTC test. Read every public address it lists. If one of them is your own address and not the proxy's exit, you have a leak. Run it again after any change, because a fix you cannot see working is a guess. The Chrome settings, policies and extension that close the leak by hand are in fix a WebRTC leak in Chrome.

How Mosaic handles it

When a profile has a proxy and the setting that blocks non-proxied UDP is on, as it is by default, Mosaic launches the engine with --webrtc-ip-handling-policy=disable_non_proxied_udp, so WebRTC cannot send UDP around the proxy. It stops WebRTC from going around the proxy; it does not route WebRTC through it. mDNS hiding stays on, as in stock Chrome. Measured on our own engine, one fresh browser per run: with no policy, WebRTC gathered 2 candidates, one carrying the computer's real public address; with the policy, it gathered 0, with RTCPeerConnection still present. That is what any machine on a network that blocks UDP looks like, where a browser with no WebRTC at all looks like nothing real.

We found our own mistakes on the way there. Two of the three WebRTC switches our launcher used to send, --webrtc-ip and --force-webrtc-ip-handling-policy, do not exist in Chromium, which accepts an unknown switch without a word. Since then, a switch name is checked against the engine binary before we rely on it. The engine also gives each profile its own local address for the case where camera or microphone access is granted, and each profile's timezone and language follow its proxy's exit (matched to the exit), so the address a site does see agrees with the rest of the profile.