So your VPN is leaking because of Chrome’s WebRTC…

We have covered the “WebRTC is leaking your IP address” topic a few times, like when I reported what the NY Times was doing and in my WebRTC-Notifier. Periodically this topic comes up now and again in the blogosphere, generally with great shock and horror. This happened again recently, so here is an updated look into this alleged issue.

The recent blog post titled VPN Leak by voidsec highlighting how 19 out of more than 100 VPN services tested “leak” IP addresses via WebRTC is a quite interesting read. Some of the details about WebRTC are not quite correct the results are interesting nonetheless. At is core this is someone who sat down to test a long list of services and their behaviour, one by one. This is not the most exciting research task, but exhaustive studies like this often find something interesting.

Google WebRTC lead Justin Uberti noted something interesting: many of services listed as vulnerable have “proxy” in the name. A lot of them are Chrome extensions. Installing some of them showed they merely change proxy settings. Well… lets play a bit with WebRTC and proxies.

Testing SOCKS proxies

What is the easiest way to test the behavior of WebRTC behind a SOCKS proxy? If you have ssh installed and a host to test with it is pretty easy:

The above will run a local SOCKS proxy on port 3128 . Change your Chrome or system proxy settings to use it. Now run the test site provided…

This shows both the IP address of the host I ssh’d into as well as my actual public IP address. This was quite surprising since I thought this had been addressed ages ago.

RTCWeb IP Handling

The WebRTC IP handling draft explains the problems arising from WebRTC allowing web pages to enumerate IP addresses as part of the ICE process and specifies a number of modes that represent different tradeoffs between performance and privacy. Mode 4 is the strictest. It blocks UDP when a proxy is set:

Mode 4: Force proxy: This is the same as Mode 3, but all WebRTC
media traffic is forced through a proxy, if one is
configured. If the proxy does not support UDP (as is the
case for all HTTP and most SOCKS [RFC1928] proxies), or the
WebRTC implementation does not support UDP proxying, the use
of UDP will be disabled, and TCP will be used to send and
receive media through the proxy. Use of TCP will result in
reduced media quality, in addition to any performance
considerations associated with sending all WebRTC media
through the proxy server.

https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-06#section-5.2

How to make Chrome use a Proxy?

Re-reading the draft showed that Chrome is behaving as specified here, Mode 4 is not the default mode, so one shouldn’t expect it to automatically route to a proxy.

So… is there a Chrome API to make it behave as specified in Mode 4? It turns out there is with this:

webRTCIPHandlingPolicy

Since Chrome 48. Allow users to specify the media performance/privacy tradeoffs which impacts how WebRTC traffic will be routed and how much local address information is exposed. This preference’s value is of type IPHandlingPolicy, defaulting to default.

https://developer.chrome.com/extensions/privacy#property-network

It has a mode called disable_non_proxied_udp. The API for this has been available since Chrome 48, released in January 2016.

Chrome Network Limiter Extension

The easiest way to change to this mode for testing is to use the Network Limiter extension published by the WebRTC team back in late 2015. In the options choose:

Use my proxy server (if present)

Then go to the test site again. It will no longer show your local IP address from WebRTC:

Leak stopped! Well, the public IP address leak at least..

What about Firefox?

In Firefox there are different settings for this which users can change themselves easily:

• media.peerconnection.ice.default_address_only – setting this to true essentially provides mode 2
• media.peerconnection.ice.no_host – setting this and the default_address_only provides mode 3
• media.peerconnection.ice.proxy_only – setting this to true forces mode 4, disabling UDP

Update: For extensions, Firefox supports the same webextension APIs as Chrome.

Make sure your VPN provider uses the browsers Privacy Settings

So much of this leak could be stopped if those vulnerable “VPN” providers (and calling a proxy ‘VPN’ is quite a stretch in my opinion) would actually use the privacy options provided by Chrome. Quite notably, EFFs privacy badger does the right thing and uses those APIs (even though it does not set them to the strictest mode either).

If you are the developer of one of those extensions that are listed as vulnerable, by all means, use the APIs available. Mind you that more media traffic might run over your proxy servers as a result. And while you are at it make sure you do not wrongly blame WebRTC in your marketing materials.

Thanks to Paolo Stagno for doing this research! I had assumed that much of this problem was related to VPNs working in a mode where some packets were routed via the VPN and others were not. It always helps to attempt to solve the right problem.

{“author”: “Philipp Hancke“}