7

It has come to my attention recently that WebRTC could leak the real IP address even behind a VPN. How exactly is it possible for WebRTC to get my real IP address?

A VPN typically creates a new interface and all packets are routed (when I check the routing table) to that interface. How does WebRTC learn about my real IP address then? Is it somehow not using that interface created by the VPN?

I have read that WebRTC uses STUN, TURN and ICE protocols to get the real IP address. How are they able to get that information?

Would a firewall rule be able to prevent this leak?

EDIT: I use a VPN in a NATed network, which means my computer does not know about my ISP-provided IP address. So, is it possible for WebRTC to get it and how?

Gradient
  • 2,253
  • 6
  • 25
  • 36
  • Doesn't this require a "proxy" [such as a web-browser](https://restoreprivacy.com/webrtc-leaks/)? – user2864740 Feb 11 '18 at 23:16
  • What do you mean? My browser still uses my OS network stack. How can it discover my real IP? – Gradient Feb 11 '18 at 23:26
  • The standard leak appears to come via *JavaScript access* in Web-browsers. The browser runs *inside* the network. The *JavaScript, running on the browser, inside the network* (but provided by a *foreign web-site*) can use TURN to get the IP which it then sends to an external agent. – user2864740 Feb 11 '18 at 23:30
  • In the case of that leak, the VPN itself *does not leak* the information. There was "rouge code" running *on the local network* that leaked the information. – user2864740 Feb 11 '18 at 23:31
  • 4
    I still don't understand. Javascript/Firefox/WebRTC/STUN/TURN all run on my computer and uses my OS network stack. They can't really escape that. That is what I can't understand with this leak. What is happening in my computer that makes them know about my real IP address? (My computer itself does not even know about my ISP-provided IP address if using a VPN in a NATed network.) – Gradient Feb 11 '18 at 23:48
  • Is this a theoretical question or you have observed it yourself? I'm asking because the way you explained it - it does not sound realistic. – zerkms Feb 11 '18 at 23:54
  • It is a theoretical question. According to my own tests, it did not leak. But, from what I read, it seems like it does anyway. In fact, it might not be true and a leak really does not happen in this case. I edited my question. I am not sure if a leak of my ISP-provided IP can really happen in a NATed network. – Gradient Feb 12 '18 at 00:52
  • 2
    the alleged leak mostly affected VPNs which were misconfigured. A properly configured VPN which routes *all* traffic over the vpn interface will not leak. – Philipp Hancke Feb 12 '18 at 09:27
  • 1
    It's been a while since I've done VPN, but classic VPN solutions often just create a new interface as you describe and makes this new interface and IP the **default route**. That is so that existing TCP connections can still function and still enable code that wants to create a socket on a specific interface. If you do a `route print` and `ipconfig /all` from the command line and post your results, it usually reveals how the VPN is working. It wouldn't surprise me if modern VPN blocks the old route though. In any case, worrying about your public IP address getting leaked... – selbie Feb 13 '18 at 07:33
  • ... shouldn't be a concern. Because every website you go to while not on VPN is most definitely getting your public IP address. But I'm open to understanding what you are really concerned about with regards to IP address protection. – selbie Feb 13 '18 at 07:34

1 Answers1

1

A WebRTC connection involves three entities:

  • the two peers (the offerer and the answerer), which are usually web browsers but may also be servers;
  • the signalling server, which is usually the web server the peers are interacting with.

When the peers decide to connect to each other, they exchange a set of messages (the offer, the answer, the ICE candidates, collectively known as SDP messages). These messages contain various data, such as information about supported codecs and cryptographic keys, and in particular they contain the IP addresses of the peers. Since these messages are communicated to the signalling server, the signalling server may use them to learn about your IP addresses.

The peers decide which of their IP addresses to include in the SDP messages. Ideally, when using a VPN, only the VPN's IP addresses should be included. However, since the SDP is generated by the browser, doing that correctly requires cooperation between the VPN and the web browser, something that is difficult to do properly.

To work around the issue, recent browsers do not include local (RFC 1918) addresses in the SDP. This works fine if your host only has RFC 1918 addresses, but fails if it has global addresses, for example because it has IPv6 connectivity. You may how your browser behaves with the Trickle-ICE script, which displays the addresses communicated by your browser to a signalling server.

In my opinion, the only reliable way to keep your IP private is to run your browser in a virtual machine that only knows about your VPN address. Any other workaround is just too error-prone to be reliable.

jch
  • 5,382
  • 22
  • 41