Re: [rtcweb] Please require user consent for data channels
Lorenzo Miniero <lorenzo@meetecho.com> Sun, 12 July 2015 19:36 UTC
Return-Path: <lorenzo@meetecho.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1406E1A8892 for <rtcweb@ietfa.amsl.com>; Sun, 12 Jul 2015 12:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.02
X-Spam-Level:
X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKMIVGj2D6IJ for <rtcweb@ietfa.amsl.com>; Sun, 12 Jul 2015 12:36:00 -0700 (PDT)
Received: from smtpcmd01231.aruba.it (smtpcmd01231.aruba.it [62.149.158.231]) by ietfa.amsl.com (Postfix) with ESMTP id B18A61A888A for <rtcweb@ietf.org>; Sun, 12 Jul 2015 12:35:59 -0700 (PDT)
Received: from rainpc ([80.116.203.23]) by smtpcmd01.ad.aruba.it with bizsmtp id rXbw1q0090WoBYY01Xbws7; Sun, 12 Jul 2015 21:35:57 +0200
Date: Sun, 12 Jul 2015 21:35:56 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Daniel Roesler <diafygi@gmail.com>
Message-ID: <20150712213556.19f6a696@rainpc>
In-Reply-To: <CA+65OspKCvwFh0GebiuUrhdtaL9zxYKLw04HdKEfewLCWQ+ZpQ@mail.gmail.com>
References: <CA+65OspMD_PVjk0BXh7t4LtjmFDcDatoeNjFQOO_OVtC-Br+OA@mail.gmail.com> <55A22A1B.4000202@gmail.com> <CA+65OspKCvwFh0GebiuUrhdtaL9zxYKLw04HdKEfewLCWQ+ZpQ@mail.gmail.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/lceOa10Ox2ZInXVaMyK8633vIwE>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Please require user consent for data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jul 2015 19:36:03 -0000
On Sun, 12 Jul 2015 12:19:03 -0700 Daniel Roesler <diafygi@gmail.com> 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 <matthew@matthew.at> 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 > <sergio.garcia.murillo@gmail.com> 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). > I don't see how that would fix anything. Setting up a recvonly audio/video PeerConnection won't get you any user-consent request either. Forcing TURN in those cases seems more like it. Lorenzo > > > > 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 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Please require user consent for data cha… Daniel Roesler
- Re: [rtcweb] Please require user consent for data… Matthew Kaufman
- Re: [rtcweb] Please require user consent for data… Sergio Garcia Murillo
- Re: [rtcweb] Please require user consent for data… Daniel Roesler
- Re: [rtcweb] Please require user consent for data… Lorenzo Miniero
- Re: [rtcweb] Please require user consent for data… Michael Tuexen
- Re: [rtcweb] Please require user consent for data… tim panton
- Re: [rtcweb] Please require user consent for data… Bernard Aboba
- Re: [rtcweb] Please require user consent for data… Matthew Kaufman
- Re: [rtcweb] Please require user consent for data… Timothy B. Terriberry
- Re: [rtcweb] Please require user consent for data… Victor Pascual Avila
- Re: [rtcweb] Please require user consent for data… Daniel Roesler
- Re: [rtcweb] Please require user consent for data… Eric Rescorla
- Re: [rtcweb] Please require user consent for data… Justin Uberti
- Re: [rtcweb] Please require user consent for data… Daniel Roesler
- Re: [rtcweb] Please require user consent for data… Justin Uberti
- Re: [rtcweb] Please require user consent for data… Sergio Garcia Murillo
- Re: [rtcweb] Please require user consent for data… Daniel Roesler
- Re: [rtcweb] Please require user consent for data… Justin Uberti
- Re: [rtcweb] Please require user consent for data… Stephen Farrell
- Re: [rtcweb] Please require user consent for data… Sergio Garcia Murillo
- Re: [rtcweb] Please require user consent for data… Justin Uberti
- Re: [rtcweb] Please require user consent for data… Sergio Garcia Murillo
- Re: [rtcweb] Please require user consent for data… Justin Uberti
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Sergio Garcia Murillo
- Re: [rtcweb] Please require user consent for data… Martin Thomson
- Re: [rtcweb] Please require user consent for data… Martin Thomson
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Justin Uberti
- Re: [rtcweb] Please require user consent for data… Martin Thomson
- Re: [rtcweb] Please require user consent for data… Harald Alvestrand
- Re: [rtcweb] Please require user consent for data… Sergio Garcia Murillo
- Re: [rtcweb] Please require user consent for data… Sergio Garcia Murillo
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Roman Shpount
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Simon Perreault
- Re: [rtcweb] Please require user consent for data… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Please require user consent for data… Harald Alvestrand
- Re: [rtcweb] Please require user consent for data… Sergio Garcia Murillo
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Tim Panton
- Re: [rtcweb] Please require user consent for data… Simon Perreault
- Re: [rtcweb] Please require user consent for data… Tim Panton
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Simon Perreault
- Re: [rtcweb] Please require user consent for data… Simon Perreault
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Tim Panton
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Simon Perreault
- Re: [rtcweb] Please require user consent for data… Daniel Roesler
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Simon Perreault
- Re: [rtcweb] Please require user consent for data… Roman Shpount
- Re: [rtcweb] Please require user consent for data… Jonathan Lennox
- Re: [rtcweb] Please require user consent for data… Roman Shpount
- Re: [rtcweb] Please require user consent for data… Roman Shpount
- Re: [rtcweb] Please require user consent for data… Iñaki Baz Castillo
- Re: [rtcweb] Please require user consent for data… Tim Panton
- Re: [rtcweb] Please require user consent for data… Ted Hardie
- Re: [rtcweb] Please require user consent for data… Roman Shpount
- Re: [rtcweb] Please require user consent for data… Ted Hardie
- Re: [rtcweb] Please require user consent for data… Randell Jesup
- Re: [rtcweb] Please require user consent for data… Roman Shpount