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 better off.
These requests do not show up in developer consoles and
cannot be blocked by browser plugins
I'm using FF with a WebRTC-blocking plugin, and it does successfully block the proof-of-concept exploit (it's called "Happy Bonobo Disable WebRTC", an admittedly shady name, but there are surely others).
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.
Vulnerability 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.
I agree. For the vast majority of use cases, this doesn't seem to be an exceptionally big issue. Almost all major websites collect IP addresses and don't explicitly prompt the user that this is happening. It seems the OP is really highlighting the edge case for users who want quasi-absolute security.
It 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 need to stop treating non-routability alone as a firewall mechanism. Any information that this WebRTC mechanism reveals could also be exploited by any random client application, or in the case of http-based protocols, by anyone who can embed an iframe or submit a form. Consider how you'd design a network in which every device had a routable IP address, and go ahead and design it that way anyway as a defense-in-depth measure. Use encrypted and authenticated protocols even on your "private" network.
There is a permission request to access the camera but this is triggered by a call to getUserMedia(). This would be done if setting up a peer connection to transmit voice and/or video. However, if you want to set up a WebRTC data channel no such prompt occurs.
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 list MAY be empty. The list need not include the address of the server, even if the server is to act as an introducer for the client. The list SHOULD NOT include link-local or loopback addresses.
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)
This is interesting and seems to indicate that there is a small edge case for people who want as much privacy as possible.
The larger topic for me is that webRTC has to make tradeoff for developers. And, I for one, love what it does. If you look at legacy comms development in the peer to peer space (e.g. Skype) the process was orders of magnitude more difficult than using a webRTC implementation. So, as a developer, sacrificing a prompt that grants an IP detection notice seems like a worthwhile tradeoff.
Also, I think webRTC is still in draft form and is still being modified in working sessions (although I'm not 100% sure of this). It would be great if Apple would get on board with webRTC for ios.
I agree that WebRTC is very powerful and makes peer-to-peer communication from browsers easily accessible for developers. And I also love what it does. However, the issue raised in the post is seen from the point of view of the user. Convenience for the developer probably won't be a concern to a user who is concerned about IP leakage. Yes, the WebRTC API is still being standardised so perhaps this issue will be addressed in future
WebRTC 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.
[+] [-] diafygi|11 years ago|reply
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 better off.
[+] [-] Udo|11 years ago|reply
[+] [-] JoeAltmaier|11 years ago|reply
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.
[+] [-] algorithm_dk|11 years ago|reply
[+] [-] Eridrus|11 years ago|reply
[+] [-] ryanseys|11 years ago|reply
[+] [-] jmartinpetersen|11 years ago|reply
[+] [-] jjbiotech|11 years ago|reply
[+] [-] mcguire|11 years ago|reply
[+] [-] softdev12|11 years ago|reply
[+] [-] JoshTriplett|11 years ago|reply
That said, long-term, I think networks need to stop treating non-routability alone as a firewall mechanism. Any information that this WebRTC mechanism reveals could also be exploited by any random client application, or in the case of http-based protocols, by anyone who can embed an iframe or submit a form. Consider how you'd design a network in which every device had a routable IP address, and go ahead and design it that way anyway as a defense-in-depth measure. Use encrypted and authenticated protocols even on your "private" network.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] arkitectual|11 years ago|reply
One example would be if you happened to use WebRTC with two peers on the same VPN.
[+] [-] 0x0|11 years ago|reply
[+] [-] Golgi_SDK|11 years ago|reply
[+] [-] echeese|11 years ago|reply
[+] [-] AdrianRossouw|11 years ago|reply
[+] [-] echeese|11 years ago|reply
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 list MAY be empty. The list need not include the address of the server, even if the server is to act as an introducer for the client. The list SHOULD NOT include link-local or loopback addresses.
[+] [-] marquis|11 years ago|reply
[+] [-] softdev12|11 years ago|reply
The larger topic for me is that webRTC has to make tradeoff for developers. And, I for one, love what it does. If you look at legacy comms development in the peer to peer space (e.g. Skype) the process was orders of magnitude more difficult than using a webRTC implementation. So, as a developer, sacrificing a prompt that grants an IP detection notice seems like a worthwhile tradeoff.
Also, I think webRTC is still in draft form and is still being modified in working sessions (although I'm not 100% sure of this). It would be great if Apple would get on board with webRTC for ios.
[+] [-] Golgi_SDK|11 years ago|reply
[+] [-] jakub_g|11 years ago|reply
[1] https://www.browserleaks.com/webrtc#webrtc-device-id
[+] [-] juberti|11 years ago|reply
[+] [-] toonse|11 years ago|reply
[+] [-] eugeneionesco|11 years ago|reply