webrtc leaks case study

Leak case study 2: WebRTC leaks

Last updated:

Your public IP addresses form part of an individual’s identity on the web, enabling sites, apps, and third parties to track their activity across the web and associate it with that specific individual. With a VPN, sites see the VPN server’s public IP address instead of the user’s, protecting their identity.

However, WebRTC may at times enable websites to see the user’s public IP address, representing a privacy-compromising leak. This case study from our Digital Security Lab describes how WebRTC leaks occur, and how to test for them using the ExpressVPN Leak Testing Tools.

WebRTC overview

WebRTC is a set of open technologies which allows web pages to provide peer-to-peer (P2P) communications via a web browser. Most modern browsers now fully support the WebRTC standard.

WebRTC, among other things, gives web browsers the ability to detect both a user’s public IP addresses and also their local IP addresses. This ability is key to facilitating P2P communications using just web browsers, without additional apps or plugins.

WebRTC leaks

WebRTC leaks are a form of IP leak. Webpages can use JavaScript WebRTC APIs to ask the browser for a device’s IP addresses. Once they have gathered these IP addresses they can send them to their servers and use them to identify who is accessing a particular web page or service.

Most VPN applications effectively protect against IPv4 addresses leaking via WebRTC, however many VPN applications tend to overlook IPv6 addresses leaking in the same way.

How does WebRTC detect IP addresses?

WebRTC uses two main techniques to determine a device’s IP addresses: STUN/TURN servers and Host Candidate Discovery.

STUN/TURN servers discover IP addresses by checking what public IP address is used to access them. Usually these are not the cause of VPN IP leaks.

Host Candidate Discovery is more problematic when it comes to WebRTC leaks. This functionality allows browsers to directly inspect your system and network interfaces and see what IP addresses are associated with them.

All active network interfaces on a device need IP addresses to function. For example, for an active Wi-Fi connection there will be a corresponding network interface on a device. This interface will in turn have an IP address.

WebRTC can reveal these IP addresses, which ordinarily couldn’t be seen externally to the device, to webpages.

Why are IPv6 leaks problematic?

IPv4 addresses are in short supply—there simply aren’t enough to go around! Usually, IPv4 addresses are shared between people. In order to do this, a system called Network Address Translation (NAT) is used. This system allows devices to assign “Local IPv4” addresses to their network interfaces while sharing a common public IP address, usually via the ISP. These local IP addresses are used globally by millions of computers around the world and are hard to direct associated with a specific individual.

The problem with IPv6 is that addresses are not in short supply. There are a lot of them! This means that individual people are usually each assigned a unique IPv6 addresses. When such an IPv6 address is assigned to a network interface, it means that WebRTC can discover an IP address that identifies who you are, even if that IP address isn’t normally visible to the outside world.

What types of leaks are there?

There are two types of WebRTC leaks, of differing severity. Which a user may be vulnerable to depends on whether they grant specific WebRTC related permissions to a webpage. In both cases, a good VPN should protect from the leaks.

Note that browser manufacturers may use different methods to implement WebRTC, so it’s possible for one browser to leak and another not to, even with the same device setup and VPN provider.

Persistent leaks (no permissions required)

By default, webpages are not granted WebRTC permissions. It is, however, still possible for the pages to access some of a user’s IP addresses using the WebRTC APIs. In these situations, websites can easily track the user via their IP addresses without their knowledge.

Triggered leaks (permissions required)

Webpages can explicitly request permissions to use WebRTC-related functionality. These permissions are actually classified as Microphone and Camera permissions. The reason for this is that WebRTC is a technology geared towards P2P communication such as voice calls or videoconferences.

When either of these permissions are granted, the webpage gets access to a wider range of IP addresses on the device, which makes a leak possible. In some browsers those permissions persist across sessions, i.e. if a user has given permissions to the webpage once, the webpage retains those permissions when the user to returns to the page in the future.

Note that individual webpages must be granted permissions separately, so granting permissions for one site does not grant permissions for another.

While these leaks are less severe than the persistent leaks above, as they require active granting of permissions by the user, we still consider them to be of concern. WebRTC is growing in popularity and users can expect to see more and more sites using the technology over the coming years. If a VPN doesn’t hide IP addresses when a user grants permissions to a site, then they are left with only two options:

  • Not use any WebRTC enabled sites and services
  • Accept the security and privacy risks associated with exposing their IP address

Testing for leaks

These tests can be performed on any desktop computer. When performing leak tests we recommend that you have IPv6 available on your test device, as this is the most likely situation in which VPN providers leak.

Manual testing

You can manually test for leaks using an online WebRTC leak test.

Repro Steps

  • Ensure the leak test page is closed
  • Ensure your VPN application is disconnected
  • Visit a WebRTC leak test page
  • Make a note of all public IP addresses you see in the test output
  • Close the leak test page
  • Connect to your VPN
  • Reopen the WebRTC leak test page
  • If you see any of the IP addresses you just made a note of above, then you have a leak

Note that we explicitly ask you to close the leak test page in order to avoid browser caching issues. Many browsers will cache IPs detected via WebRTC, thus reloading the webpage is not a reliable way to run the test.

Note that some test pages only tests for the most severe class of leaks, i.e. the “Persistent Leaks” discussed above. To test whether you leak when permissions are granted to your browser we suggest you use the leak testing tools below.

Testing using the ExpressVPN Leak Testing Tools

The ExpressVPN Leak Testing Tools are an extensible suite of open-source Python tools designed for both manual and automated leak testing of VPN applications. Please see our introduction to the tools for instructions on downloading and setting up the tools.