1304600 - WebRTC exposes local IP address despite media.peerconnection.ice.default_address_only = true

Status: RESOLVED INVALID

(Core :: WebRTC: Networking, defect, P1)

Description

[François Marier [:francois]]

As per https://wiki.mozilla.org/Media/WebRTC/Privacy, I have set media.peerconnection.ice.default_address_only = true to avoid exposing my local IP address via WebRTC.

The following test pages confirm that this feature does what it's supposed to:

https://www.browserleaks.com/webrtc
http://net.ipcalf.com/

However while that works fine on Aurora 50.0a2 (2016-09-19), it doesn't on Nightly 52.0a1 (2016-09-21) and now leaks out my internal (192.168.1.x in my case) IP address.

I have not tested on 51, but I assume that it's broken there too since we just branched 52.

Comment 1

[Nils Ohlmeier [:drno]]

I suspect bug 1297416 might cause the regression. Recompiling right now to test that theory.

Comment 2

[Nils Ohlmeier [:drno]]

Confirmed (by compiling 57647be72e76 and ac7f8d395735 locally) bug 1297416 is causing this regression.

Byron: is the documentation for 'media.peerconnection.ice.default_address_only' outdated since bug 1297416 landed or is really a bug in 1297416?

Comment 3

[Byron Campen [:bwc]]

Yes, the documentation is outdated. default_address_only does what it says on the tin; it prevents anything but the default route from being used. In order to prevent the use of any host candidates, you could use either media.peerconnection.ice.no_host, or the more extreme media.peerconnection.ice.relay_only.

Comment 4

[François Marier [:francois]]

Thanks for the clarification Byron.

I just read the spec (https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01) and I have a few questions:

1. Is Mode 2 (the new default unless mic/camera permission) supposed to hide local addresses from sites?
2. Is media.peerconnection.ice.relay_only the way to force Mode 4?
3. Is media.peerconnection.ice.no_host the way to force Mode 3?

I guess I'm not clear on terminology. Does "host candidates" refer only to local network addresses or can it also map to external addresses for a computer that's directly connected to the Internet without NAT? If you disable these via media.peerconnection.ice.no_host, do you only lose the ability to connect directly to computers on the same local network (behind a NAT)?

I'm wondering whether media.peerconnection.ice.no_host is the pref that we should evangelize to people concerned about leaking their internal IP address (instead of having them disable WebRTC entirely).

Comment 5

[Byron Campen [:bwc]]

(In reply to François Marier [:francois] from comment #4)
> Thanks for the clarification Byron.
> 
> I just read the spec
> (https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01) and I have a
> few questions:
> 
> 1. Is Mode 2 (the new default unless mic/camera permission) supposed to hide
> local addresses from sites?

   No. It only prevents the use of non-default routes. The default_address_only pref can be used to force mode 2 even when there's a permission grant.

> 2. Is media.peerconnection.ice.relay_only the way to force Mode 4?

   Yes.

> 3. Is media.peerconnection.ice.no_host the way to force Mode 3?

   Setting both no_host and default_address_only would get you mode 3.

> I guess I'm not clear on terminology. Does "host candidates" refer only to
> local network addresses or can it also map to external addresses for a
> computer that's directly connected to the Internet without NAT? If you
> disable these via media.peerconnection.ice.no_host, do you only lose the
> ability to connect directly to computers on the same local network (behind a
> NAT)?

   Host candidates are local IP addresses only. Disabling host candidates _might_ prevent connections on the local network entirely unless a relay is used, depending on whether the NAT allows hairpinning, and whether both ends have disabled host candidates.

> I'm wondering whether media.peerconnection.ice.no_host is the pref that we
> should evangelize to people concerned about leaking their internal IP
> address (instead of having them disable WebRTC entirely).

It depends. If they are concerned with leaking _any_ internal address, then this is the pref they want. If they're ok with advertising the default route, but do not want to expose anything more regardless of capture permissions, then default_address_only is what they want.

Comment 6

[François Marier [:francois]]

(In reply to Byron Campen [:bwc] from comment #5)
> > 3. Is media.peerconnection.ice.no_host the way to force Mode 3?
> 
>    Setting both no_host and default_address_only would get you mode 3.

Ok, let me check if I understand this properly before I update the wiki.

Given the recent changes, in the absence of a permission grant:

- you get Mode 2 if you leave no_host set to false, and
- you get Mode 3 if you set no_host to true?

In the presence of a permission grant:

- you end up in Mode 1 if you leave no_host to false, and
- you end up in an undefined mode if you set no_host to true?


Looking at https://wiki.mozilla.org/Media/WebRTC/Privacy, it sounds like the fix is to change the "default_address_only" line from:

    Local=No    External=Yes    Relay=Yes    No candidates=N/A    Interfaces=Only interface with default route

to:

    Local=Yes    External=Yes    Relay=Yes    No candidates=N/A    Interfaces=Only interface with default route

and then adding a new line for no_host:

    Local=No    External=Yes    Relay=Yes    No candidates=N/A    Interfaces=All interfaces will be used to try to connect to the relay

Is my "patch" correct?

Comment 7

[Byron Campen [:bwc]]

(In reply to François Marier [:francois] from comment #6)
> (In reply to Byron Campen [:bwc] from comment #5)
> > > 3. Is media.peerconnection.ice.no_host the way to force Mode 3?
> > 
> >    Setting both no_host and default_address_only would get you mode 3.
> 
> Ok, let me check if I understand this properly before I update the wiki.
> 
> Given the recent changes, in the absence of a permission grant:
> 
> - you get Mode 2 if you leave no_host set to false, and
> - you get Mode 3 if you set no_host to true?
> 
> In the presence of a permission grant:
> 
> - you end up in Mode 1 if you leave no_host to false, and
> - you end up in an undefined mode if you set no_host to true?

   You end up in a mode not described by the draft, one where the browser will use all available routes, but will not provide any host candidates.

> 
> 
> Looking at https://wiki.mozilla.org/Media/WebRTC/Privacy, it sounds like the
> fix is to change the "default_address_only" line from:
> 
>     Local=No    External=Yes    Relay=Yes    No candidates=N/A   
> Interfaces=Only interface with default route
> 
> to:
> 
>     Local=Yes    External=Yes    Relay=Yes    No candidates=N/A   
> Interfaces=Only interface with default route
> 
> and then adding a new line for no_host:
> 
>     Local=No    External=Yes    Relay=Yes    No candidates=N/A   
> Interfaces=All interfaces will be used to try to connect to the relay

I would say "All local interfaces will be used", since they will be used not only for connecting to the relay, but also gathering server reflexive candidates, and sending checks to all remote candidates.

Comment 8

[François Marier [:francois]]

I updated the wiki: https://wiki.mozilla.org/index.php?title=Media%2FWebRTC%2FPrivacy&diff=1148768&oldid=1128017