ipleak.net circumvents WebRTC blocking

[vbagirov]

Steps to reproduce

1. Enable 'Block WebRTC' in AdGuard's Stealth Mode
2. Go to https://ipleak.net/

Expected behavior

Screenshot:

https://lh4.googleusercontent.com/bkvc_c8tF-IS9HvLOSyDHqjy728sLvlY7gWVBq_Uqcz5Nd6txJUx2_4IdG0eSdyhZkgDwEkyNgLhC38=w1366-h637

### Actual behavior

Screenshot: https://uploads.adguard.com/vbagirovnlvjr.png

Your environment

• Chrome 61
• Windows 10, v.1703
• AdGuard 6.2.433.2167

[ameshkov]

@adbuker do you see STUN requests in the filtering log?

[adbuker]

yes, I see stun-request in the filtering log and it is blocked as it was by design. As it can be seen from the code, they use onicecandidate handler to get info.

[ameshkov]

inspect chrome://webrtc-internals

[adbuker]

For establishing a p2p connection between two computers (p1 and p2), you must find out a local IP of the p1 (i.e. the address in the local network), the global IP of the p1's provider and send these IPs to the p2 (and then the same procedure for p2).

It's quite easy to get local IP, but to determine global IP you have to use STUN/TURN servers. The main purpose of such servers is to send back the global IP when a request from the computer behind the NAT-router is received. When the option "Block WebRTC" is enabled, AdGuard blocks such requests (as you can see in the filtering log - https://uploads.adguard.com/buker_mhchu.png), so determining of "your" global IP address will become impossible. Thus, establishing of p2p connection is also impossible.

The IP address of the computer, specified in https://ipleak.net/, is the local IP address only. Therefore, the establishing WebRTC connection cannot be ensured.
Checking "WebRTC - leaks" in the service https://ipleak.net/ is based on checking ONLY the existence of the object, that defines the WebRTC connection (this is the member of WebRTC API and named as RTCPeerConnection). However, the COMPLETENESS of this object (in the sense of the ability to determine the global IP, and thus the possibility of establishing such connection) is not checked.

To sum up, in fact, there is no WebRTC leak in case of "Block WebRTC" option is enabled.

[vbagirov]

Closing it then.

[ameshkov]

Guys, let's keep this open. Public IP is protected indeed, but it does not mean we shouldn't do better with JS. Assigned to v6.3

[Atavic]

Is https://browserleaks.com/webrtc any better?

[ameshkov]

@Atavic both use more or less the same algorithm, so you can observe the same issue on browserleaks

[Atavic]

Useless tests, as explained above by @adbuker

[adbuker]

resolved in adguard-windows/pull-requests/48