Re: [rtcweb] Please require user consent for data channels

[Michael Tuexen <[e-mail]>]

> On 12 Jul 2015, at 21:19, Daniel Roesler <[e-mail]> wrote:
> 
> Thanks very much for the responses! Going to try and address both inline below.
> 
> On Sat, Jul 11, 2015 at 9:26 PM, Matthew Kaufman <[e-mail]> wrote:
>> 
>> On the IPv6 Internet, the IP address you use to reach the web site is almost
>> certainly the same as your "local" IP address. There's no additional
>> information exposed by allowing an application to discover that information
>> directly via JavaScript.
>> 
>> The IPv4 Internet is essentially out of addresses and in the process of
>> being retired. I don't believe there's any reason at this point to disable
>> functionality in order to improve compatibility with this legacy network.
>> 
> 
> I disagree with this sentiment. IPv4 will be around for many more
> years and many ISPs still do not assign their customers IPv6
> addresses. If IPv6 is replacing IPv4 so readily, why not only offer
> WebRTC through IPv6? It's a huge double standard to say that we won't
> support privacy issues of one network while at the same time
> supporting connectivity though it.
> 
>> 
>> ps. You can also gather all these addresses for any browser with Flash
>> Player installed by asking Flash to connect via RTMFP to a server, whereupon
>> it will report the full enumeration of available IPv4 and IPv6 addresses to
>> that server.
> 
> Yes, however flash can easily be blocked using click-to-enable (i.e.
> user consent) and will not be installed on the majority of modern
> browsers (mobile devices). WebRTC will be. What I'm asking for here is
> a similar flash-blocking behavior to what is possible in Chromium
> (built-in setting) and Firefox (via FlashBlock addons), so that users
> can choose to click-to-enable based on context (just like they need to
> already in getUserMedia).
> 
> On Sun, Jul 12, 2015 at 1:49 AM, Sergio Garcia Murillo
> <[e-mail]> wrote:
>> Hi,
>> 
>> While acknowledging that there might be a potential privacy issue, I don't
>> think agree on your analysis on the issue that you have made nor your
>> proposal.
> 
> I'd like to strongly encourage everyone here to stop treating this
> issue as "might be a potential privacy issue". There have been
> numerous news articles[1][2][3][4], discussion by
> VPNs/Tor[5][6][7][8], my github proof-of-concept has over 1,500 stars
> and 195 forks[9], the Mozilla Firefox bug has over 100 comments and is
> marked as sec-moderate[10], and we are now seeing it exploited in the
> wild to detect VPN users[11]. This is not "might be a potential
> privacy issue". This is an existing, significant privacy issue.
> 
> [1]: https://torrentfreak.com/huge-security-flaw-leaks-vpn-users-real-ip-addresses-150130/
> [2]: http://lifehacker.com/how-to-see-if-your-vpn-is-leaking-your-ip-address-and-1685180082
> [3]: https://threatpost.com/webrtc-found-leaking-local-ip-addresses/110803
> [4]: http://news.softpedia.com/news/WebRTC-in-Firefox-and-Chrome-Reveals-IPs-Behind-VPN-471881.shtml
> [5]: https://www.expressvpn.com/blog/explaining-webrtc-ip-leak-vulnerability-affecting-web-browsers/
> [6]: https://trac.torproject.org/projects/tor/ticket/5578
> [7]: https://ipleak.net/
> [8]: https://www.privateinternetaccess.com/forum/discussion/8204/
> [9]: https://github.com/diafygi/webrtc-ips
> [10]: https://bugzilla.mozilla.org/show_bug.cgi?id=959893
> [11]: https://twitter.com/incloud/status/619624021123010560
> 
>> 
>> The information available in the ICE gathering process and made available to
>> the JS app is the following:
>> 
>> -Host candidates, mostly private IP addresses
>> -Server reflexive candidates, exposing the public IP address as shown by the
>> TURN/STUN server
>> -Relay candidates, hosted by the TURN server
>> 
>> My understanding of the issue is that the leak happens when the application
>> is able to retrieve information not already available to it.
>> That happens either when the user is using a VPN and have multiple public IP
>> addresses or using an external PROXY so the http/ws connection have a
>> different originator public IP address. AFAIK there should be no potential
>> danger in leaking the private IP4 addresses (here you got mine, in case you
>> are interested 127.0.0.1 and 192.168.64.2 ;). I have not much background on
>> IPv6, so please complete any missing info and how would it affect here.
> 
> If you read the above articles and discussion surrounding the leak.
> The concern is not around local or private IPs, it's around public IPs
> for VPN users. Personal VPN use is extremely widespread
> internationally, mostly for censorship and content-blocking
> circumvention. Chinese users use them to get around the great
> firewall. Australian users use them to be able to watch Netflix. Tor
> is often not a suitable option because the web service they are trying
> to reach blocks Tor (e.g. bank website) or is too data heavy (e.g.
> streaming video).
> 
>> From the popularity of the issue, it's clear that the vast majority of
> users thought that using a VPN hid their real IP address from the
> websites they were visiting. It has been a huge shock (including for
> me) that default VPN configurations let the browser (and thus WebRC)
> know the real IP. Is that an operating system or VPN software issue?
> Either way, due to WebRTC this real IP access issue has now spread to
> javascript, so that any website can access your real IP.
> 
> "AFAIK there should be no potential danger in leaking the private IP4 addresses"
> 
> Here's a real-life example of the danger this has. China started
> injecting malicious javascript into people's Baidu searches when those
> searches came from outside China[12]. This was used to DDOS Github,
> but what if that javascript contained a webrtc data channel setup? All
> of a sudden, China could obtain the real Chinese IPs of citizens who
> were using VPNs. The result of this could definitely be
> life-threatening. Again, just saying "use Tor" means those citizens
> cannot use many modern internet services (especially streaming video).
> Personal VPNs are a fantastic compromise that provide access at quite
> good speeds while retaining a good-enough-for-Netflix level or
> privacy. WebRTC's real IP leaking removes this middle ground
> compromise.
> 
> [12]: http://arstechnica.com/security/2015/03/github-battles-largest-ddos-in-sites-history-targeted-at-anti-censorship-tools/
> 
>> 
>> I don't think it is a good idea to tight the solution of requesting user
>> permission, to not leak IP information, as theoretically a user could be
>> interested in using webrtc (audio/video/datachannels) and still don't
>> disclose their public IP address (i.e. forcing all the data to go via a TURN
>> server).
>> 
>> One possible solution would be that the browser don't gather/announce
>> host&reflexive candidates when an HTTP proxy is set, and only use turn relay
>> candidates instead. The second solution (which I think it is already
>> discussed somewhere else) would be to allow the user to configure a TURN
>> server to override the app settings and force all connection to go through
>> it. (Then build a chained-TURN infrastructure into TOR and you could have a
>> killer combo ;)
> 
> I'm fully supportive of removing the real IPs from the onicecandidate
> results. However, as we saw in April's discussion thread and now in
> this thread, identifying that IP is a complex topic that likely
> doesn't have an easy answer and might require significant browser or
> operating system-level changes. So, I'm suggesting here that an easier
> solution is to make data channels require user-consent (again, just
> like what already happens with audio and video channels).
> 
>> 
>> Regarding the issue that the browser becomes a CDN peer, not sure if anyone
>> has ever raised the issue before. From my point of view, there is not, but
>> in any case, I think it is orthogonal to the leak issue.
> 
> It is orthogonal to the privacy issue, but this user-consent proposal
> also helps address this issue, too.
Don't you ask for user consent for a peer connection?

Best regards
Michael
> 
> Thanks again for the responses!
> Daniel
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>