Subject: [rtcweb] ICE exposes 'real' local IP to javascript

From: Tim Panton <[email-masked]>
Date: Mon, 2 Feb 2015 14:16:30 +0000

Firstly- sorry for cross posting - I’m not sure which side of the line this falls.
Secondly - if this is covered, please let me know, I don’t recall it cropping up...

I’ve been reading worried blogs that WEBRTC in browsers ‘leaks’ the local ‘real’ ip addresses to the javascript.
The principle worriers are VPN users e.g https://cryptostorm.org/viewtopic.php?f=50&t=2867&p=13096#p13096 <https://cryptostorm.org/viewtopic.php?f=50&t=2867&p=13096#p13096>
The concern is that this can be done without user notification (DataChannel request) and might be used to 
identify or finger-print users. Clearly the most vulnerable are Tor users who are on a real routeable IP address
or directly on a carrier grade nat (eg android phones etc) where the IP may reveal the identity or location of the user.

It seems to me that this concern will be increased in the case of ipv6 deployments (MNOs).

Do we need to specify a config option on the browser ‘I’m using a VPN don’t expose my local IP’ 

Again, sorry if I missed this being hashed to death already. 

T

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk <http://www.westhawk.co.uk/>

---

From: Benjamin Schwartz <[email-masked]>
Date: Mon, 2 Feb 2015 09:58:11 -0500

Standards-wise: You might want to have a look at
http://tools.ietf.org/html/draft-schwartz-rtcweb-return-04#section-5.3 (a
draft which I'm hoping will be adopted by the rtcweb group).

Reality-wise:
Tor is not a VPN.  It acts as a SOCKS5 proxy.  Tor doesn't support UDP, and
none of the major browsers support SOCKS5-UDP anyway, so it's not much use
for WebRTC.  Tor Browser Bundle, IMHO the only responsible way to use Tor,
has disabled WebRTC from the beginning, precisely to avoid revealing the
user's IP address.

VPN users who want to be safe should set permissions such that the browser
can only access the VPN, not the physical network.  (I don't personally
know how to do this, especially on all different operating systems!)

On Mon, Feb 2, 2015 at 9:16 AM, Tim Panton <[email-masked]> wrote:

> The principle worriers are VPN users e.g
> https://cryptostorm.org/viewtopic.php?f=50&t=2867&p=13096#p13096
> The concern is that this can be done without user notification
> (DataChannel request) and might be used to
> or directly on a carrier grade nat (eg android phones etc) where the IP
> may reveal the identity or location of the user.
>
> www.westhawk.co.uk

---

From: <[email-masked]>
Date: Mon, 2 Feb 2015 19:58:09 +0000

Isn't that done by whitelisting. You as a user use a application wich uses webrtc.

M.vr.gr<http://M.vr.gr>.,

Richard van Det
06 2054 7291

Op 2 feb. 2015 om 18:05 heeft Benjamin Schwartz <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

Standards-wise: You might want to have a look at http://tools.ietf.org/html/draft-schwartz-rtcweb-return-04#section-5.3 (a draft which I'm hoping will be adopted by the rtcweb group).

Reality-wise:
Tor is not a VPN.  It acts as a SOCKS5 proxy.  Tor doesn't support UDP, and none of the major browsers support SOCKS5-UDP anyway, so it's not much use for WebRTC.  Tor Browser Bundle, IMHO the only responsible way to use Tor, has disabled WebRTC from the beginning, precisely to avoid revealing the user's IP address.

VPN users who want to be safe should set permissions such that the browser can only access the VPN, not the physical network.  (I don't personally know how to do this, especially on all different operating systems!)

On Mon, Feb 2, 2015 at 9:16 AM, Tim Panton <[email-masked]<mailto:[email-masked]>> wrote:
Firstly- sorry for cross posting - I’m not sure which side of the line this falls.
Secondly - if this is covered, please let me know, I don’t recall it cropping up...

The principle worriers are VPN users e.g https://cryptostorm.org/viewtopic.php?f=50&t=2867&p=13096#p13096

T

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk<http://www.westhawk.co.uk>

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Göran Eriksson AP <[email-masked]>
Date: Mon, 2 Feb 2015 21:13:20 +0000

From: Tim Panton [mailto:[email-masked]]
Sent: den 2 februari 2015 15:17
To: public-webrtc
Cc: [email-masked] >> [email-masked]
Subject: ICE exposes 'real' local IP to javascript

Again, sorry if I missed this being hashed to death already.
[GAPE:] There are different “challenges” as I see it; a) one to ‘hide’ the information from the involved web sites and peers and b) another from a web site owner perspective, how to safeguard users privacy and security. ‘a’ has been discussed and partly addressed, e.g.  in [1] and [2] .
For ‘b’, we have Web platform mechanisms CSP [3,4] (and CORS) that the web site admin can use to get help from the UA to do defense-in-depth. Now, I may have missed it but has there been any in-depth discussion about CSP (existing or new directives for the O/A procedure, etc. for as Web site using the WebRTC API nor is there anything mentioned in the latest W3C  working draft. Perhaps I’ve missed it- what is the status? Postponed to future work?

Göran

[1] https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/
[2] http://tools.ietf.org/html/draft-schwartz-rtcweb-return-04#section-5.3
[3] CSP Level 1.1, http://www.w3.org/TR/CSP/
[4]CSP Level 1.2 (Draft), http://www.w3.org/TR/CSP2/

T

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 03 Feb 2015 15:03:43 +0100

>or directly on a carrier grade nat (eg android phones etc) where the IP may reveal the identity or location of the user.

If this actually allows random web sites to know that I am using the
addresses 192.168.12.96, 192.168.3.222, and 192.168.200.7 (Ethernet,
Wifi, virtual machine) on this computer then that is pretty much like
broadcasting a device GUID and should concern everybody. I note that
some of the recent news coverage of this indicated that some major web
sites and services already use this to identify and track users.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Feb 2015 17:42:01 +0100

Some thoughts....

1) Datachannel is a red herring. There are many ways to do a valid 
CreateOffer with m-lines, which is all that is required:

- Datachannel
- OfferToReceiveVideo  / Audio
- Generate a MediaStreamTrack from WebAudio

and so on.

2) Speaking with my WebRTC hat on: IP addresses have to be surfaced at 
the API as long as the other side needs to try to send packets to these 
interfaces. We can't obfuscate them or encrypt them because they have to 
be communicated to the other party, through channels that aren't in the 
WebRTC spec.

3) Speaking with my (imaginary) implementors hat: One can imagine a 
(browser-wide) configuration setting for which addresses to allow access 
to, possibly with a whitelist of apps / pages / sites allowed more 
access than others. Normal people will never configure this (and if they 
tried, they would get it wrong), so the defaults need to be "safe enough 
for most", but sysadmins and the people with special reasons to care 
about security might.

4) Again wearing my WebRTC spec shepherding hat: It seems that the spec 
should make it clear:
a) that IP addresses will be exposed (in SDP and in oncandidate callbacks)
b) why IP addresses are being exposed
but not really anything more than that.

5) Wearing my forum-shuffling hat, it seems that the "why" part belongs 
more in the IETF than in the WebRTC side of things - so I'd favour 
continuing this thread on rtcweb@ietf only....

Harald

---

From: Roman Shpount <[email-masked]>
Date: Tue, 3 Feb 2015 12:15:46 -0500

The thing I was wondering about was, should there be a confirmation dialog
when browser tries to setup any type of peer-to-peer connection? We get a
confirmation dialog when microphone or camera access is requested. I think
setting up a peer-to-peer connection is something that should be controlled
by the user on the per web site basis in the similar manner.

_____________
Roman Shpount

On Tue, Feb 3, 2015 at 11:42 AM, Harald Alvestrand <[email-masked]>
wrote:

> 2) Speaking with my WebRTC hat on: IP addresses have to be surfaced at the
> API as long as the other side needs to try to send packets to these
> interfaces. We can't obfuscate them or encrypt them because they have to be
> communicated to the other party, through channels that aren't in the WebRTC
> spec.
>
> to, possibly with a whitelist of apps / pages / sites allowed more access
> than others. Normal people will never configure this (and if they tried,
> they would get it wrong), so the defaults need to be "safe enough for
> most", but sysadmins and the people with special reasons to care about
> security might.
>
> [email-masked]

---

From: Göran Eriksson AP <[email-masked]>
Date: Tue, 3 Feb 2015 20:41:14 +0000

Inline

> -----Original Message-----
> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: den 3 februari 2015 17:42
> To: Tim Panton new; Göran Eriksson AP
> Cc: public-webrtc; [email-masked] >> [email-masked]
> Subject: Re: ICE exposes 'real' local IP to javascript
> 
> Some thoughts....
> 
> API as long as the other side needs to try to send packets to these interfaces.
> We can't obfuscate them or encrypt them because they have to be
> communicated to the other party, through channels that aren't in the
> WebRTC spec.
[GAPE:] OK, sure, that would fit in IETF. But CSP/CORS are within the W3C scope, right? For instance, consider using Web platform mechanisms such as CSP; that should be in the scope of the W3C draft, right? Something along the lines Web site admin using CSP/CORS to have the UA 'check' the 'find&connect' proxy origin (especially when it is not in the same 'origin' as that of the parent document)? 
    
> (browser-wide) configuration setting for which addresses to allow access to,
> possibly with a whitelist of apps / pages / sites allowed more access than
> others. Normal people will never configure this (and if they tried, they would
> get it wrong), so the defaults need to be "safe enough for most", but
> sysadmins and the people with special reasons to care about security might.
[GAPE:] Hmm, there are such lists around I imagine, :-). But I would prefer leveraging W3C mechanisms for many reasons- these things are subject to regulation in some parts of the world and it often a + to be able to point to an "open standard" not to mention the fragmentation challenges. But yes, it is especially the 'sys admins'  of the Web site owners I am thinking about now.
> but not really anything more than that.
[GAPE:] +1
> more in the IETF than in the WebRTC side of things - so I'd favour continuing
> this thread on rtcweb@ietf only....
[GAPE:] It is not one or the other I would say- this concerns the Web platform users security and privacy, hardly a matter only of IETF concern, :-, and again, we should have a second look at Web platform security mechanisms (such as CSP). But apart from that, we should discuss and possible update relevant IETF drafts with at least that info in Your '4'. 

I am not certain that such a discussion will result in any [significant] impact on the UA, perhaps more "BCP'ish" information, but given the importance of considering user privacy and security, I believe it is worthwhile doing- at the very least spend some time on it here, :-).

---

From: Tim Panton new <[email-masked]>
Date: Mon, 2 Feb 2015 22:16:22 +0000

> On 2 Feb 2015, at 21:13, Göran Eriksson AP <[email-masked]> wrote:
> 
>  
>  
> From: Tim Panton [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: [email-masked] <mailto:[email-masked]> >> [email-masked] <mailto:[email-masked]>

I think these VPN users have hit the ‘partly’ aspect. 5.4 in [1] says: 
"Note that these requirements are NOT intended to protect the user’s
 IP address from a malicious site. In general, the site will learn at
least a user's server reflexive address from any HTTP transaction.” 
The VPN folks are worried that their privacy may be compromised by webRTC exposing their local IP without their permission.
An advert might call a dataChannel createOffer() for the purposes of gaining the local IPV6 address and using it to fingerprint the user in
ways that the reflexive address couldn’t. - So they don’t want to trust ‘evil_banners.com’ with their local addresses and before webRTC they
didn’t have to. I’m not clear that this is a big enough issue to warrant a spec change, but it is an issue they seem to care about.

T.

---

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 4 Feb 2015 11:45:44 -0800

On Feb 2, 2015, at 02:16 PM, Tim Panton new <[email-masked]> wrote: 
> 
>> On 2 Feb 2015, at 21:13, Göran Eriksson AP <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>  
>>  

Witholding the local IP address means traffic always has to go through a TURN server, which harms the user experience.  Consider for example two users in the same office with their traffic tromboning up their little DSL access link to a TURN server on the Internet.  We don't want that.  But, likewise, those users may value their IPv6 privacy addresses and their IPv4 NAPT to obscure "Alice" from "Bob" at that same company, and disclosing their local IP address does leak information.  This worry has long been a problem on enterprise networks implementing ICE, to such a degree that stripping a=candidate lines containing the internal addresses is desirable for privacy (as well as to force ICE to complete faster, as a firewall or NAT would prevent ICE from working with those addresses in many cases, anyway).

-d