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

Den 06. feb. 2015 11:55, skrev Bjoern Hoehrmann:
> * Harald Alvestrand wrote:
>> I would see much more benefit in someone trying for a writeup that
>> describes precisely the threat they see, what mitigations they see
>> against the possible threat, and - importantly - what functionality we
>> would lose by implementing those mitigations.
>>
>> So far, we've been tossing around the term "private IP address" without
>> a precise definition, stating that it is a privacy concern without
>> specifying what attacks are possible based on that information, tossing
>> around words about possible mitigations (user prompts, browser
>> configurations), and not tying those possible mitigations to possible
>> loss of functionality (user prompt blindness, lessened usability,
>> failures in setting up intra-LAN peer connections). This is not engineering.
> 
> Like I said, "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 a fairly persistent one. That
> seems reasonably specific to me, and the problems a covertly-obtainable
> GUID poses should be clear. It is quite possible many systems offer
> fewer bits of identifying information than my configuration, do we have
> any scientific research on that?

So your concern is not the actual IP addresses exposed, but the use of
those IP addresses as persistent machine identifiers. Is that correct?

My laptop, at the moment, exposes the (DHCP-assigned, may change) IP
address 192.168.1.86 and an ephemeral IPv6 address.
When my VPN tunnel is up, I have an additional address 172.28.90.221; I
think this also changes when I reconnect.

Neither of these is a *stable* identifier, but they do live for a while.

WRT scientific research: We should make some.


> There are any number of ways to discourage use of this information for
> purposes other than those intended, starting with saying that it is not
> to be used for other purposes in the specification. User interaction can
> be required before sending such information (think file uploads and pop-
> up blockers), browsers could indicate when they send the addresses using
> some sort of notification so obtaining the information covertly would be
> difficult, the API could give sites the option to omit private addresses
> to avoid such notifications; sending private addresses could be disabled
> if the code is running in some iframe and not the main page. And so on
> and so forth. None of this would come with an actual loss of features.

Who would obey these instructions?
Remember that we're assuming that the browsers run Javascript written by
the attacker, so we can't depend on the Javascript specification.

> It would also help if we actually had a working draft of the API speci-
> fication, the latest one is from 2013 and if it had Security and Privacy
> considerations, even the editor's draft for the API has only a "TBD"
> Security section.

We're pushing out a new WD as we speak, but this will always lag behind
the editors' draft.

WRT the security considerations section, there's a proposal in
https://github.com/w3c/webrtc-pc/pull/15 that has been waiting for 3
months - comments are certainly welcome.

Received on Friday, 6 February 2015 11:18:38 UTC