1449732 - Do not expose Local IP Address in Resist Fingerprinting Mode

Status: REOPENED

(Core :: WebRTC: Networking, enhancement, P5)

Description

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

AIUI we need to set media.peerconnection.ice.no_host  (although in actually we'll add a check for RFP to those locations.

Comment 1

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: Bug 1449732 Do not expose the local IP address via WebRTC when Resist fingerprinting is enabled

Review commit: https://reviewboard.mozilla.org/r/232876/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/232876/

Comment 2

[Simon Mainey]

Question: shouldn't `media.peerconnection.ice.default_address_only` also be set to true?

[1] https://bugzilla.mozilla.org/buglist.cgi?bug_id=1189041,1297416
[2] https://wiki.mozilla.org/Media/WebRTC/Privacy

Comment 3

[Nils Ohlmeier [:drno]]

Why do you try to block host addresses, which in case of NAT's are most likely going to be 1918 addresses with ton's of over lap in the 192.168.x.x address space, but not the publicly routable address?

I would argue that in lot's of networks the publicly routable address (where that address is almost constant because it rarely changes) is way more useful for tracking (=fingerprinting ?) then the private IPs.

Comment 4

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

(In reply to Nils Ohlmeier [:drno] from comment #3)
> Why do you try to block host addresses, which in case of NAT's are most
> likely going to be 1918 addresses with ton's of over lap in the 192.168.x.x
> address space, but not the publicly routable address?
> 
> I would argue that in lot's of networks the publicly routable address (where
> that address is almost constant because it rarely changes) is way more
> useful for tracking (=fingerprinting ?) then the private IPs.

When we can obscure the public IP address (via Tor) - we will. But the private IP address is still a fingerprinting mechanism. Even moreso for the portion of users who aren't in 192.168.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Tom Ritter [:tjr] from comment #4)
> (In reply to Nils Ohlmeier [:drno] from comment #3)
> > I would argue that in lot's of networks the publicly routable address (where
> > that address is almost constant because it rarely changes) is way more
> > useful for tracking (=fingerprinting ?) then the private IPs.
> 
> When we can obscure the public IP address (via Tor) - we will. But the
> private IP address is still a fingerprinting mechanism. Even moreso for the
> portion of users who aren't in 192.168.

Right - LAN IP's in home lans are typically very sticky by default; in corporations IPs are often hard-assigned to hosts even if they're using DHCP on a 10.* network (for ease in tracking down a screaming machine, for example, or identifying which port of a switch something is plugged into).   External IP for a corporate network doesn't help a ton, but that plus LAN ip is likely very stable.

Comment 6

[Nils Ohlmeier [:drno]]

(In reply to Tom Ritter [:tjr] from comment #4)
> (In reply to Nils Ohlmeier [:drno] from comment #3)
> When we can obscure the public IP address (via Tor) - we will. But the
> private IP address is still a fingerprinting mechanism. Even moreso for the
> portion of users who aren't in 192.168.

So here is the scenario:
- browser running with Tor enabled
- browser is configured (e.g. with this patch or the user pref) to not disclose ICE host candidates to JS
- user loads a page via Tor
- JS instantiates a RTCPeerConnection and a STUN or TURN server gets provisioned
- the ICE stack will learn the public, external, routable IP address and emit it as an ICE candidates

I fail to see how Tor should prevent this. I think what you want for a browser in the Tor network to only give out relay candidates, because these are not easily linkable to the users location (although the above mentioned web page can provision individual credentials for it's TURN server for each visitor of the web page and then link the usage of the credentials in the TURN server with the information from where the TURN server saw the requests coming).

Besides the fact that I don't see how a audio or video over the Tor network should ever work. If at all a data channel might make sense.

Comment 7

[Nils Ohlmeier [:drno]]

Just to clarify: I don't argue that the private IP addresses should not be considered a risk for/against fingerprinting. I think this doesn't go far enough to properly prevent fingerprinting.

Comment 8

[Byron Campen [:bwc]]

I don't think I agree that host candidates are useful enough for fingerprinting to merit disabling them entirely. I think it would be much more justifiable to force mode 2 (ie; default route only) in this case.

Comment 9

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

(In reply to Nils Ohlmeier [:drno] from comment #6)
> (In reply to Tom Ritter [:tjr] from comment #4)
> > (In reply to Nils Ohlmeier [:drno] from comment #3)
> > When we can obscure the public IP address (via Tor) - we will. But the
> > private IP address is still a fingerprinting mechanism. Even moreso for the
> > portion of users who aren't in 192.168.
> 
> So here is the scenario:
> - browser running with Tor enabled
> - browser is configured (e.g. with this patch or the user pref) to not
> disclose ICE host candidates to JS
> - user loads a page via Tor
> - JS instantiates a RTCPeerConnection and a STUN or TURN server gets
> provisioned
> - the ICE stack will learn the public, external, routable IP address and
> emit it as an ICE candidates
> 
> I fail to see how Tor should prevent this. I think what you want for a
> browser in the Tor network to only give out relay candidates, because these
> are not easily linkable to the users location (although the above mentioned
> web page can provision individual credentials for it's TURN server for each
> visitor of the web page and then link the usage of the credentials in the
> TURN server with the information from where the TURN server saw the requests
> coming).

So, I don't know WebRTC (or its terminology) as well as you - but when we have Tor built into Firefox - we'll disable all UDP mechanisms of WebRTC in that mode (because Tor can't transport UDP). All the TCP mechanisms will be routed through Tor; and one's 'real' external IP will never be revealed.

Prior to that (since we aren't getting Tor into Firefox for a bit because we have to build all of that) - we want to improve the Resist Fingerprinting mode by not revealing the user's local IP - since that's just more entropy for attackers to take advantage of when trying to fingerprint users.

And without a full Tor solution, there's no way to hide a user's real external IP.

> Besides the fact that I don't see how a audio or video over the Tor network
> should ever work. If at all a data channel might make sense.

You'd be surprised. People were making audio calls through Tor 6 years ago. There was latency; but it was usable. https://guardianproject.info/2012/12/10/voice-over-tor/  There isn't a lot of data on this, because the most versatile WebRTC tool - Firefox - doesn't build for Tor with WebRTC enabled (Bug 1393901), and you need a tool that will support TCP-only connections. But people have used Skype (in the past, they may block Tor now) and mumble successfully.

Comment 10

[Eric Rescorla (:ekr)]

Unless I'm missing something, I don't think this is worth working on. I'm not aware of any plan to generically turn on resist fingerprinting outside of Tor mode, implementing something that that makes that work is also not high priority.

Comment 11

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

(In reply to Eric Rescorla (:ekr) from comment #10)
> Unless I'm missing something, I don't think this is worth working on.

I don't really agree with that.

We have a vibrant community of people who enable Resist Fingerprinting Mode and report issues to us - this feedback is invaluable in determining that parts of the web break and why. It's going to make it a lot easier to move towards any sort of broader deployment of RFP - and a lot of Mozillians are interested in portions or all of RFP Mode for mobile, tracking protection, and of course Tor Mode.  We want to make RFP mode as robust as possible both for feedback purposes and to provide as strong as protection as possible to users who choose to enable it (knowing it's beta).

Plus, shoring up Resist Fingerprinting is art of the Tor Uplift, where our work is being fed downstream to Tor who use the work. (And Tor is pursuing WebRTC experiments.)

Comment 12

[Eric Rescorla (:ekr)]

"We have a vibrant community of people who enable Resist Fingerprinting Mode and report issues to us - this feedback is invaluable in determining that parts of the web break and why. "

It's fine for them to do so, but this is not a feature we are offering, it's an about:config pref, so there's no reasonable expectation it actually provides any enhanced privacy. That's why it's behind a hidden pref. If people actually are doing this to get protection, then a stronger disclaimer is needed.

As I said, while I know there are people who are interested in shipping a non-Tor RFP mode, I'm not aware of any plan to do so, and a *Tor* mode would have totally different WebRTC settings, if any.

Comment 13

[Nils Ohlmeier [:drno]]

I think we had a good conversation about TOR and WebRTC at the SF All Hands. But since there isn't much progress on this ticket here I'll close it for now (feel free to re-open if you disagree).

Comment 14

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

I'd like to keep it around for tracking. In the future, if Tor enables TCP-based WebRTC or Firefox builds Tor in, we will need to address this.