DNS, WebRTC, and TLS Leaks: The Most Common Errors

When you connect to a VPN or use a proxy, it is assumed that your real IP address and online activities remain hidden. But in practice, this is not always the case. There are so-called leaks, that is, technical mechanisms due to which some of the data can be transmitted outside the protected channel.

DNS, WebRTC, and TLS leaks are situations where technical data, such as the DNS server, the real IP, or connection parameters, are exposed due to network or browser settings. Such leaks do not reveal the history of visited sites, but may reveal a discrepancy between the IP address, DNS server, and other connection parameters, which can trigger anti-fraud systems.

In this article, we will look at how DNS, WebRTC, and TLS leaks occur, how to detect them, and what measures can be taken to reduce the risks.

What are DNS, WebRTC, and TLS Leaks in Reality?

DNS, WebRTC, and TLS relate to different levels of network interaction. Therefore, the mechanisms for data exposure differ in each case. In one case, requests bypass the protected channel, in another case, the browser directly transmits network information, and in the third case, the parameters of the encrypted connection are analyzed.

Let's analyze each type separately to understand the risks and protection methods.

DNS Leaks

DNS (Domain Name System) is a system that translates familiar website names into IP addresses. When you enter an address in your browser, the device first sends a DNS query to find out which IP to connect to, and only then a connection to the site is established. 

When using a VPN, it is assumed that all requests pass through an encrypted tunnel and are processed by the DNS servers of the VPN provider itself. However, in some cases, the system continues to send DNS requests directly to the Internet provider's server. This is called a DNS leak.

In this case, the provider sees which domains the device is requesting, even if the main traffic passes through the VPN. At the same time, the content of pages and transmitted data remain encrypted. The sites themselves and anti-bot systems do not have access to the user's DNS queries. They can only indirectly detect the problem, for example, if the DNS server belongs to one country or provider, and the public IP address belongs to another network.

The reasons can be different: incorrect network settings, lack of built-in protection against DNS leaks in the VPN, protocol conflicts, or operating system features.

WebRTC Leaks

WebRTC (Web Real-Time Communication) is a technology built into modern browsers that allows direct connections between users. It is used for video calls, voice communication, online conferences, and data transfer directly in the browser window without installing additional software.

For the connection to work correctly, WebRTC requests the device's network information, including the local and external IP address. In some cases, WebRTC can transmit network information directly, bypassing the VPN tunnel. The browser can transmit the real IP address through special data exchange mechanisms (for example, ICE candidates are a list of possible network addresses and routes that the device offers for direct connection), even if the site's traffic goes through a VPN or proxy.

As a result, a web page with WebRTC enabled is able to determine the user's real IP. At the same time, the VPN continues to work, but some of the network information is disclosed directly. That is why WebRTC leaks are considered one of the most common problems that reduce the level of anonymity when using a VPN or proxy.

TLS Fingerprint: What is it and Why Does it Give You Away?

TLS (Transport Layer Security) is a protocol that encrypts data between the browser and the site. Thanks to it, the connection is displayed as HTTPS, and the content of pages remains protected from interception. But TLS has a side effect that few people think about — the TLS fingerprint.

When a browser connects to a site via HTTPS, it first sends the server a ClientHello message, something like a "business card." It indicates which encryption methods the client supports, which TLS extensions it uses, and in what order it lists them. This message is not encrypted, and the server sees it even before a secure connection is established.

Each browser and each program sends its own unique set of parameters in ClientHello. Chrome lists ciphers and extensions in one order, Firefox in another, and a Python script or a bot based on standard libraries in a third. This combination is the TLS fingerprint. It can be compared to handwriting: you write the same letters, but you can be distinguished from others by your characteristic style.

There are standard methods for calculating such fingerprints — these are JA3 and the more modern JA4. They take parameters from ClientHello (list of ciphers, extensions, supported algorithms) and turn them into a short hash, that is, a string of characters that can be used to match the client with a known browser or program.

Why TLS Fingerprint is Important

Many anti-bot systems and fraud protection systems analyze the TLS fingerprint passively. For this, they do not need to execute scripts on the page or check cookies, it is enough to look at ClientHello. If the request comes with a User-Agent header from Chrome, and the TLS fingerprint corresponds to the Python library, then the server instantly understands that it is not a real user in front of him. Such a connection may be marked as suspicious, receive a captcha, or be blocked.

This is the first line of defense, which works even before analyzing the behavior on the page. That is why even perfectly configured HTTP headers will not help if the TLS fingerprint gives out automation.

How to Check for DNS, WebRTC, and TLS Leaks

Checking for leaks is a mandatory step if you use a VPN or other anonymization tools. Let's take a look at how to check this in practice.

Checking for DNS Leaks

A DNS leak is easiest to detect through online services. The check takes a few minutes and does not require special skills.

You can use:

• IPleak;
• DNSLeaktest;
• Browserleaks.

To check, first connect to a VPN or proxy, then open one of the services for testing DNS. Sometimes the result loads immediately, but in some cases you need to run a test.

The report will show the DNS servers through which your requests pass. If the VPN provider's servers or public DNS (such as Cloudflare or Google) are specified, the protection is working correctly. If the name or IP of your Internet provider is displayed, this is a sign of a DNS leak.
You can also check the DNS used without online services.

If you have Windows:

1. Open the command prompt (Win + R → cmd).
2. Enter the command: nslookup example.com
3. The Server line will indicate the DNS server that processes the request.

If you have macOS / Linux:

In the terminal, run: nslookup example.com or dig example.com

If, when the VPN is enabled, your provider's DNS is displayed, then the requests bypass the tunnel and the protection is configured incorrectly.

Checking for WebRTC Leaks

You can check for a WebRTC leak through special online services. The procedure resembles testing for DNS.

You can use:

• Browserleaks;
• IPleak;
• Hide.me.

To check, first connect to a VPN or proxy, then open one of the services. Usually the result is displayed automatically, but sometimes you need to run the test manually.

The report will show the public IP address and network parameters that the browser transmits via WebRTC. If your real provider's IP address is displayed instead of the VPN IP, then WebRTC is disclosing the data directly. If only the VPN server IP is specified, there is no leak. Some services simply inform whether there is a leak.

In addition to online tests, it is important to check whether WebRTC is enabled in the browser itself.

If you have Firefox, enter about:config in the address bar. In the search bar, find the media.peerconnection.enabled parameter. If the value is true, then WebRTC is active. If false, then WebRTC is disabled.

In Chrome and Edge, there is no built-in WebRTC status indicator. You can check its operation through the internal diagnostics page: open chrome://webrtc-internals (or edge://webrtc-internals) in the address bar. If activity of connections is displayed there when visiting sites or tests, WebRTC is working. If connections are not created, then the transmission is limited.

In the Brave browser, open "Settings → Privacy and security." There you can find the parameters for processing WebRTC and determine whether the transmission of local IP addresses is allowed.

Checking the TLS Fingerprint

You can check your TLS fingerprint through the tls.peet.ws service. It shows the ClientHello parameters of your browser, the calculated JA3/JA4 hash, and allows you to compare it with the fingerprints of popular browsers. So you can see if your connection looks like a regular Chrome or stands out from the rest.

How to Protect Yourself from Leaks

Protecting against leaks requires a comprehensive approach. It is not enough to simply turn on the VPN, it is important to properly configure the system and the browser, and also regularly check the connection. Let's start with protection against DNS leaks.

Protection against DNS Leaks

The first step is to choose a VPN service with built-in protection against DNS leaks. This feature is usually called DNS Leak Protection and means that all DNS queries are automatically routed through the protected servers of the VPN itself.

Such protection is implemented by many large providers, such as NordVPN, ExpressVPN, and Proton VPN. When using such services, DNS queries are not sent directly to the provider, even if the system is configured by default.

The second level of protection is manual configuration of DNS servers. You can specify public DNS that are not associated with your Internet provider. The most common options are Cloudflare (1.1.1.1) and Google (8.8.8.8).

You can configure DNS in the network connection settings of the operating system. In Windows, this is done in the adapter properties, in macOS — in the "Network" section. Also, some modern browsers allow you to enable the use of secure DNS directly in the settings.

The combination of a VPN with activated DNS leak protection and manually set DNS servers significantly reduces the risk of transmitting requests directly to the provider.

Protection against WebRTC Leaks

WebRTC works at the browser level, so the protection is configured there. If you are using a VPN but have not restricted WebRTC, the browser can still reveal your real IP.

The first way is to disable WebRTC in the browser settings. In Firefox, this is done through the about:config page: you need to find the media.peerconnection.enabled parameter and set the value to false. After that, the browser will stop using WebRTC to establish direct connections.

In Chrome and Edge, it is impossible to completely disable WebRTC using standard tools. In this case, use extensions that block the transmission of network data via WebRTC. Popular options are uBlock Origin (with additional settings) and WebRTC Control. They limit the transmission of the real IP through browser mechanisms.

The third option is to use browsers with enhanced privacy. For example, Brave does not block WebRTC by default, however, this parameter can be changed in the browser's privacy settings.

After making changes, it is recommended to re-check the connection through an online test to make sure that the real IP is no longer displayed.

Protection Against TLS Leaks

It is impossible to disable sending ClientHello, because without it, an encrypted connection will not be established. The task is not to hide the fingerprint, but to make it not stand out among millions of ordinary users.

The most reliable way is to use a browser based on Chromium of the current version. In this case, your TLS fingerprint will coincide with the fingerprint of a huge number of Chrome users, and anti-bot systems will not see anything suspicious.

Problems arise when something non-standard appears in the chain: an outdated browser, an atypical TLS library, or an automation tool. The fingerprint immediately becomes rare, and therefore noticeable.

Linken Sphere does not have this problem. The browser works on the current Chromium engine, so each profile sends the same set of ciphers and extensions as a regular Chrome of the corresponding version when connecting. The TLS fingerprint will not be unique, it will simply coincide with thousands of real users. This is what is needed for correct masking.

Conclusion

You can reduce the risk of leaks if you follow a few simple rules:

1. Use a reliable VPN with DNS Leak Protection and Kill Switch.
2. If necessary, manually specify public DNS servers.
3. Check the status of WebRTC in the browser and disable it, if required.
4. Regularly check the connection for DNS and WebRTC leaks.

Such measures do not guarantee complete anonymity, but they significantly increase the level of protection.