What is the WebRTC leak test? [Guide]

Hearing FUD around WebRTC IP leaks and testing them? The stories behind them are true, but only partially.

WebRTC IP leak tests were popular at some point, and somehow they still are today. Some of it is related to pure FUD while another part of it is important to consider and review. In this article, I’ll try to cover this as much as I can. Without leaking my own private IP address (192.168.123.191 at the moment if you must know) or my public IP address (80.246.138.141, while tethered to my phone at the coffee shop), lets dig into this topic together ⛏️

Premier to IP addresses

IP addresses are what got you here to read this article in the first place. It is used by machines to reach out to each other and communicate. There are different types of IP addresses, and one such grouping is done between private and public addresses.

Private and public IP addresses

Once upon a time, the internet was built on top of IPv4 (and it still mostly is). IPv4 meant that each device had an IP address constructed out of 4 octets – a total of around 4 billion potential addresses. Less than the people on earth today and certainly less than the number of devices that now exist and connect to the internet.

This got solved by splitting the address ranges to private and public ones. A private IP address range is a range that can be reused by different organizations. For example, that private IP address I shared above? 192.168.123.191? It might also be the private IP address you are using as well.

A private IP address is used to communicate between devices that are hosted inside the same local network (LAN). When a device is on a different network, then the local device reaches out to it via the remote device’s public IP address. Where did that public IP address come from?

The public IP address is what a NAT device associates with the private IP address. This is a “box” sitting on the edge of the local network, connecting it to the public internet. It essentially acts as the translator of public IP addresses to private ones.

IP addresses and privacy

So we have IP addresses, which are like… home addresses. They indicate how a device can be reached. If I know your IP address then I know something about you:

• Private IP address is a small window towards that local network. Enough such addresses and someone can get a good understanding of the architecture of that network (or so I am being told)
• Public IP addresses can tell you where that user is. To some extent:

A quick look at that public IP address of mine from above, gives you the following information on WhatIsMyIpAddress.com:

So…

• My ISP is HOT Mobile
• But… this is a cellular hotspot tethered from my smartphone
• And I am definitely not located in Ashdod, although I did grew up there as a kid
• Suffice to say, this isn’t a Static IP address either
• A thing to consider here – a seemingly innocent website knows my public IP address. There’s no real “privacy” in public IP addresses

It is somewhat accurate, but in this specific case, not much. In other cases it can be pretty damn accurate. Which means it is quite private to me.

One thing these nasty IP addresses can be used for? Fingerprinting. This is a process of understanding who I am based on the makeup and behavior of my machine and me. An IP address is one of many characteristics that can be used for fingerprinting.

If you’re not certain if IP addresses are a privacy concern or not, then there’s the notion that most probably IP addresses are considered privately identifiable information – PII (based on ruling of US courts as far as I can glean). This means that an IP address can be used to identify you as a person. How does that affect us? I’d say it depends on the use case and the mode of communications – but what do I know? I am not a lawyer.

Who knows your IP address(es)?

IP addresses are important for communications. They contain some private information in them due to their nature. Who knows my IP addresses anyway?

The obvious answer is your ISP – the vendor providing you access to the internet. It allocated the public IP address you are using to you and it knows which private IP address you are coming from (in many cases, it even assigned that to you through the ADSL or other access device it installed in your home).

Unless you’re trying to hide, all websites you access know your public IP address. When you connected to my blog to read this article, in order to send this piece of content back to you, my server needed to know where to reply to, which means it has your public IP address. Am I storing it and using it elsewhere? Not that I am directly aware of, but my marketing services such as Google Analytics might and probably does make use of your public IP address.

That private IP address of yours though, most websites and cloud services aren’t directly aware of it and usually don’t need it either.

WebRTC and IP addresses

WebRTC does two things differently than most other browser based protocols out there:

1. It enables peer-to-peer communications, directly between two devices. This diverges from the classic client-server approach where a server mediates each and every message between clients
2. WebRTC uses dynamic ports generated per session when needed. This again is something you won’t see elsewhere in web browsers where ports 80 and 443 are so common

Because WebRTC diverges from the client-server approach AND uses dynamic ephemeral ports, there’s a need for NAT traversal mechanisms to be able to.., well… pass through these NATs and firewalls. And while at it, try not to waste too much network resources. This is why a normal peer connection in WebRTC will have 4+ types of “local” addresses as its candidates for such communications:

1. The local address (usually, the private IP address of the device)
2. Server reflexive address (the public IP address received via a STUN request)
3. Relay address (a public IP address received via a TURN request). This one comes in 3 different “flavors”: UDP, TCP and TLS

Lots and lots of addresses that need to be communicated from one peer to another. And then negotiated and checked for connectivity using ICE.

Then there’s this minor extra “inconvenience” that all these IP addresses are conveyed in SDP which is given to the application on top of WebRTC for it to send over the network. This is akin to me sending a letter, letting the post office read it just before it closes the envelope.

IP addresses are necessary for WebRTC (and VoIP) to be able to negotiate and communicate properly.

This one is important, so I’ll write it again: IP addresses are necessary for WebRTC (and VoIP) to be able to negotiate and communicate properly.

It means that this isn’t a bug or a security breach on behalf of WebRTC, but rather its normal behavior which lets you communicate in the first place. No IP addresses? No communications.

One last thing: You can hide a user’s local IP address and even public IP address. Doing that though means the communication goes through an intermediary TURN server.

Past WebRTC “exploits” of IP addresses

WebRTC is a great avenue for hackers:

1. It is a new piece of technology, so the understanding of it is limited
2. WebRTC is complex, with a lot of different network protocols and attack surfaces via its extensive APIs
3. IP addresses are needed to be exchanged, giving access to… well… IP addresses

The main exploits around IP addresses in browsers affecting the user’s privacy were conducted so far for fingerprinting.

Fingerprinting is the act of figuring out who a user is based on the digital fingerprint he leaves on the web. You can glean quite a lot about who a user is based on the behavior of their web browser. Fingerprinting makes users identifiable and trackable when they browse the web, which is quite useful for advertisers.

The leading story here? NY Times used WebRTC for fingerprinting

There’s a flip side to it – WebRTC is/was a useful way of knowing if someone is a real person or a bot running on browser automation as indicated in the comments. A lot of the high scale browser automations simply couldn’t quite cope with WebRTC APIs in the browser, so it made sense to use it as part of the techniques to ferret out real traffic from bots.

Since then, WebRTC made some changes to the exposure of IP addresses:

• It doesn’t expose local IP addresses to the application if the user haven’t allowed access to the camera or microphone
• If it still needs local addresses, it uses mDNS instead

Who knows your local IP address in WebRTC?

There are different entities in a WebRTC session that need to have your local IP address in a WebRTC session:

1. Your browser. Its “innards” which runs the WebRTC stack needs to know your local IP address. And it does. So does your browser for that matter
2. The other peer. This can be another web browser or a media server. They need that IP address to reach back to you if they’re on the same network as you are. And they can only know that if they try reaching out to you
3. The web application. Since WebRTC has no signaling, the application is the one that sends the local IP address to the other peer
4. Browser extensions. These may have access to this information simply because they have JavaScript coding access to the web page conducting the communications. Since the web application has a clear view of the IP addresses in the SDP messages, so does any browser extensions that have access to that web page and web application
5. TURN servers. Not yours, but your peer’s TURN server. Since that TURN server may act as a mediator for the traffic. It needs your local IP address to try (and mostly fail) to connect to it

The other peer, the web application and the TURN server don’t really need that access if you don’t care about the local network connectivity use case. If connecting a WebRTC session on the local network (inside a company office, home, etc) isn’t what you’re focused on, then you should be fine with not sharing the local IP address.

Also, if you are concerned about your privacy to the point of not wanting people to know your local IP address – or public IP address – then you wouldn’t want these IP addresses exposed either.

But how can the browser or the application know about that?

VPNs stopping WebRTC IP leaks

When using a VPN, what you are practically doing is making sure all traffic gets funneled through the VPN. There are many reasons for using a VPN and they all revolve around privacy and security – either of the user or the corporate whose VPN is being used.

The VPN client intercepts all outgoing traffic from a device and routes it through the VPN server. VPNs also configure proxy servers for that purpose so that web traffic in general would go through that proxy and not directly to the destination – all that in order to hide the user itself or to monitor the user’s browsing history (do you see how all these technologies can be used either for anonymity or for the exact opposite of it?).

WebRTC poses a challenge for VPNs as well:

• It uses multiple addresses and ports. Dynamically. So it is a bit harder to track and reroute
• IP addresses are found inside the body of HTTP and WebSocket messages themselves and not only in the protocol headers. They can be quite hard to find in order to delete/replace
• WebRTC uses UDP, which typically doesn’t get a special treatment by web proxies (which tend to focus on HTTP and WebSocket traffic)
• Did I mention it is rather new? And VPN vendors know little about it

To make all this go away, browsers have privacy policies built into them. And VPNs can modify these policies to accommodate for their needs – things like not allowing non-proxied UDP traffic to occur.

How much should you care about WebRTC IP leaks?

That’s for you to decide.

As a user, I don’t care much about who knows my IP address. But I am not an example – I am also using Chrome and Google services. Along with a subscription to Office 365 and a Facebook account. Most of my life has already been given away to corporate America. 🔗

Here are a few rules of thumb I’d use if I were to decide if I care:

• If you’re blocking JavaScript in your browser then you probably have nothing to worry about – WebRTC won’t work without it anyway
• Assuming you’re not using Skype, Facebook Messenger, Whatsapp and others because you don’t want them to know or track you, then you should think twice about using WebRTC as well. And if you use it, make sure to “plug” that “IP leak” in WebRTC
• Using a VPN? Then it means you don’t want your IP addresses publicly known. Make sure your VPN handles WebRTC properly as well
• You replaced Google Search with DuckDuckGo in your browser? Or other search engines because they were said to be more privacy conscious? Then you might want to consider the WebRTC angle of it as well

In all other cases, just do nothing and feel free to continue using WebRTC “as is”. The majority of web users are doing just that as well.

Do you want privacy or privacy?

This one is tricky 😎

You want to communicate with someone online. Without them knowing your private or public IP address directly. Because… well… dating. And anonymity. And harassment. And whatever.

To that end, you want the communication to be masked by a server. All of the traffic – signaling and media – gets routed through the intermediary server/service. So that you are masked from the other peer. But guess what – that means your private and public IP addresses are going to be known to the intermediary server/service.

You want to communicate with someone online. Without people, companies or governments eavesdropping on the conversation.

To that end, you want the communication to be peer-to-peer. No TURN servers or media servers as intermediaries. Which is great, but guess what – that means your private and public IP addresses are going to be known to the peer you are communicating with.

At some point, someone needs to know your IP addresses if you want and need to communicate. Which is exactly where we started from.

Oh, and complicated schemes a-la TOR networking is nice, but doesn’t work that well with real time communications where latency and bitrates are critical for media quality.

The developer’s angle of WebRTC IP leaks

We’ve seen the issue, the reasons for it and we’ve discussed the user’s angle here. But what about developers? What should they do about this?

WebRTC application developers

If you are a WebRTC application developer, then you should take into account that some of your users will be privacy conscious. That may include the way they think about their IP addresses.

Here are a few things for you to think about here:

• Does your service offer P2P communications? (you probably need local IP addresses for that in the messages)
• If your traffic flows solely via media servers, consider removing host candidates from the device side. They will be mostly useless anyway
• You’re probably passing the IP addresses in SDP messages in your network. Are you storing them or logging them anywhere? For how long? In what format?
• Test your service in various privacy-challenging environments:
  • Web proxies
  • Strict firewalls
  • VPNs of various types

VPN developers

If you are a VPN developer, you should know more about WebRTC, and put some effort into handling it.

Blocking WebRTC altogether won’t solve the problem – it will just aggravate users who need access to WebRTC-based applications (=almost all meeting apps).

Instead, you should make sure that part of your VPN client application takes care of the browser configurations to place them in a policy that fits your rules:

• Make sure you route WebRTC traffic via the VPN. That includes both signaling (easy) and media (harder). I’d also check the data channel routing while at it if I were you
• Handle UDP routing. Don’t just go for the simple TCP/TLS-only approach, as this will ruin the quality of experience for your users
• Test against multiple different types of WebRTC applications out there. Don’t only look at Google Meet – there are plenty of others people are using

WebRTC leak test: The FAQ version