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

[Daniel Roesler <[e-mail]>]

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.

Thanks again for the responses!
Daniel