This is known for years, unbelievable how many people still exploit this for page clicks.
Excuse Me Sir, Your WebRTC Is Leaking
21–30 of 39 posts
Re: Excuse Me Sir, Your WebRTC Is Leaking
#22Vulnerability doesn't seem like the correct word to describe this issue. It's more of an exposure of potentially sensitive information (your local IP address if you're using a VPN) as a result of WebRTC's protocol design.
I haven't thought about it enough, but I suspect it's more of a problem on the VPN side; IP addresses were never intended to be private or sensitive. My suspicion is that this is another case of NAT being the reason we can't have nice things.
Re: Excuse Me Sir, Your WebRTC Is Leaking
#23WebRTC can also be used for fingerprinting (apparently Chrome only) in a similar way as cookies. [1] has an explanation and test of it, as well some other fingerprinting methods.
Re: Excuse Me Sir, Your WebRTC Is Leaking
#24Flash has been able to do this for years: https://tools.ietf.org/html/draft-thornburgh-rtmfp-flash-02#... The "setPeerInfo" command is sent by the client to the server over the NetConnection control flow to inform the server of candidate socket addresses through which the client might be reachable. This list SHOULD include all directly connected interface addresses and proxy addresses except as provided below. The li…
Flash can be blocked, or not installed. If you are running a modern Chrome or Firefox, there is no way to stop this from running. (edit: apparently you can now block WebRTC entirely in Firefox, but Chrome has to be recompiled)
Re: Excuse Me Sir, Your WebRTC Is Leaking
#25Interesting, maybe browsers should add a permission prompt like they do for web camera access before allowing a webrtc stun request?
Why would you want to disable STUN requests? Wouldn't they just return the public-facing IP that the server already knows about?
Re: Excuse Me Sir, Your WebRTC Is Leaking
#26Relevant Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=959893 My test: https://diafygi.github.io/webrtc-ips/ The main two issues are that a data connection doesn't require user consent (unlike video/audio) and the browser checks all network interfaces as connection candidates (so VPN users on Windows and Mac expose their real IPs). As I proposed in the bug, if we fix those two things, we would be a lot be…
All true; but a perfect solution would not involve more prompts to the user. Crying wolf and all that; too many and nobody reads the prompts any more.
The exposure of your IP address(es) is a very mild risk; not in a class with security risks, more like cookies. It just helps de-anonymize you, if you care about that.
Re: Excuse Me Sir, Your WebRTC Is Leaking
#27Interesting, maybe browsers should add a permission prompt like they do for web camera access before allowing a webrtc stun request?
Why would you want to disable STUN requests? Wouldn't they just return the public-facing IP that the server already knows about?
Did you even read the article and click the demo link? :) https://diafygi.github.io/webrtc-ips/
Re: Excuse Me Sir, Your WebRTC Is Leaking
#28It seems like the problem that WebRTC wants to solve could be solved another way, by putting more of the discovery logic into the browser rather than the application. WebRTC wants to find peers on the local LAN, and communicate with them directly. Why not let the browser find peers, and then hand the WebRTC application a connection without exposing where that connection leads? That said, long-term, I think networks n…
The problem is that in order for WebRTC to work correctly for all use cases all local IPs must be sent to the remote client.
One example would be if you happened to use WebRTC with two peers on the same VPN.
Re: Excuse Me Sir, Your WebRTC Is Leaking
#29It seems like the problem that WebRTC wants to solve could be solved another way, by putting more of the discovery logic into the browser rather than the application. WebRTC wants to find peers on the local LAN, and communicate with them directly. Why not let the browser find peers, and then hand the WebRTC application a connection without exposing where that connection leads? That said, long-term, I think networks n…
The problem is that in order for WebRTC to work correctly for all use cases all local IPs must be sent to the remote client. One example would be if you happened to use WebRTC with two peers on the same VPN.
We have added an initial solution for this issue in Chrome 42. Users can set the following preference:
"webrtc": { "multiple_routes_enabled": false },
For the location of the prefs file, see http://www.chromium.org/administrators/configuring-other-pre....
This forces all WebRTC connections to only use server-reflexive and relay ICE candidates, and only on the default IP route. While this may cause a QoS hit (two users behind NAT can no longer keep their traffic internal to the NAT), it does allow the issue mentioned here to be fully addressed without disabling WebRTC altogether.
Re: Excuse Me Sir, Your WebRTC Is Leaking
#30WebRTC can also be used for fingerprinting (apparently Chrome only) in a similar way as cookies. [1] has an explanation and test of it, as well some other fingerprinting methods. [1] https://www.browserleaks.com/webrtc#webrtc-device-id
These ids work just like cookies; scoped to each user and origin. If you clear cookies, the ids are cleared as well.