• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
webrtcHacks

webrtcHacks

Guides and information for WebRTC developers

  • Home
  • About
    • Chad Hart
    • Philipp Hancke
  • Subscribe
  • Contact
  • Show Search
Hide Search

Technology Chrome, ip leakage, proxy, VPN Philipp Hancke · April 2, 2018

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.

Brussel’s Mannneken Pis. Original photo by Flickr user Francisco Antunes (CC BY 2.0)

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:

1
ssh -D localhost:3128 your-host

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“}

Technology Chrome, ip leakage, proxy, VPN

Related Posts

  • Optimizing WebRTC Power Consumption (Markus Handell)Optimizing WebRTC Power Consumption (Markus Handell)
  • How is WebRTC doing and who is driving usage? (Hint: Google Meet)How is WebRTC doing and who is driving usage? (Hint: Google Meet)
  • Apple’s not so private relay fails with WebRTCApple’s not so private relay fails with WebRTC
  • Dealing with HTMLMediaElements and srcObjects in WebRTC applicationsDealing with HTMLMediaElements and srcObjects in WebRTC applications

RSS Feed

Reader Interactions

Comments

  1. Hmm says

    September 15, 2018 at 6:31 am

    Latest version of Chrome 69.0.3497.92 now leaks your approximate location. It’s not your IP address but it’s in the same area so if you’re using a VPN, you can trick Chrome or Google.

    Interestingly they still carry on after that location privacy issue was in the news recently

    Reply
    • Chad Hart says

      September 20, 2018 at 6:32 am

      Were you referring to this issue? https://krebsonsecurity.com/2018/06/google-to-fix-location-data-leak-in-google-home-chromecast/

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

  • Sponsored. Become a webtcHacks sponsor

Email Subscription

Subscribe to our mailing list

* indicates required

Twittering

Tweets by @webRTChacks
webrtcHacksguides and information for WebRTC developers

Footer

SITE

  • Post List
  • About
  • Contact

Categories

  • Guide
  • Other
  • Reverse-Engineering
  • Standards
  • Technology

Tags

apple Blackbox Exploration Brief camera Chrome code computer vision DataChannel debug e2ee Edge extension gateway getUserMedia ICE ims insertable streams ios ip leakage janus jitsi MCU Microsoft NAT opensource Opus ORTC Promo Q&A raspberry pi Safari SDES SDP sfu signaling simulcast standards TURN video vp8 w3c Walkthrough Web Audio webrtc-internals wireshark

Follow

  • Twitter
  • YouTube
  • GitHub
  • RSS

webrtcHacks · copyright © 2023