Recently it has been revealed that there is (and has been) a way to expose your real IP address when using a VPN or other proxy. The method revolves around using the WebRTC (Web Real-Time Communication) API and STUN (Session Traversal Utilities for NAT). Fortunately, there are some simple fixes for this issue.
To test if your browser(s) are unprotected, enable your VPN connection and go here: https://diafygi.github.io/webrtc-ips/
As you can see from the screenshot above, when using a vulnerable Chrome browser, my real IP address was gleaned despite having an active VPN connection. The solutions to fix this problem are detailed below:
*** UPDATE Aug 3, 2015 *** — Google has now released a new extension to block all WebRTC requests.
1) Simply titled “WebRTC Network Limiter,”this plugin will stop normal WebRTC requests along with indirect requests, such as via an iframe.
According to the release notes, this small 7kb addon will do the following:
What it does:
This configures WebRTC to not use certain IP addresses:
– IP addresses not visible to the public internet (e.g. addresses like 192.168.1.2)
– any public IP addresses associated with network interfaces that are not used for web traffic (e.g. an ISP-provided address, when browsing through a VPN)
Once the extension is installed, WebRTC will only use public IP addresses associated with the interface used for web traffic, typically the same addresses that are already provided to sites in browser HTTP requests.
You can (and probably should) download and install the WebRTC Network Limiter addon for Chrome [here].
***UPDATE***: As this issue has gained a lot of attention, the WebRTC testing page was recently updated to test WebRTC requests using an iframe, and it appears that the WebRTC-Block plugin for Chrome does NOT BLOCK all types of WebRTC requests. We have reached out to the creator(s) of WebRTC Block to find out if they are able to update their extension to stop all forms of WebRTC requests. We will keep you posted on any updates we get from them, and if any new extensions or solutions arise. At this time there are limited options for Chrome users to eliminate the issue completely. Using FireFox with the fix described below, or an alternative browser that is not affected or does not implement WebRTC is currently the safest option. Chrome users can take the following steps to help reduce the risk of WebRTC but none of these options currently eliminate the issue entirely. 1) The WebRTC Block extension still helps. It properly blocks standard WebRTC requests that are not loaded via an iFrame.
Pairing Option #1 with a script blocking extension is the best option if you are unable to use an alternative browser.
ScriptBlock – This is the smaller sized plugin of the two, sized at 148k. An example interface is shown below:
ScriptSafe – This plugin is slightly larger at 248k, and also works very well to block website scripts. The interface example is shown below:
Once installed, you can test if it works by reloading the page [here]. If you do not see any IP addresses showing, then you are protected (see screenshot below).
FireFox has more options to use for blocking scripts, like NoScript, but the easiest way to block WebRTC requests is the following:
1. In a new or existing tab, type the following: “about:config”
2. Click the “I’ll be careful, I promise!” button.
3. In the Search box, type “media.peerconnection.enabled” (see below image)
4. Double-click the “media.peerconnection.enabled” line, and it will automatically change the value to False (see below)
5. That’s it!
Now that you have configured your browser(s) to not allow WebRTC requests, confirm that you are no longer leaking your real IP address.
1. Turn on your VPN connection if it is not on.
3. If the page does not show any IP addresses at all, then you have correctly configured your browsers. The page should look like this:
Update: Please follow the same steps above for all of your browser profiles (if applicable), to make sure this vulnerability is completely fixed on your computer.
Update2: Thanks to our subscribers and commenters for bringing up the new issue with WebRTC being accessible through an iframe.