Open Bug 959893 Opened 10 years ago Updated 10 months ago

[meta] WebRTC Internal IP Address Leakage

Categories

(Core :: WebRTC: Signaling, defect)

defect

Tracking

()

Tracking Status
firefox36 --- wontfix
firefox37 --- wontfix
firefox38 --- wontfix
firefox39 --- affected
firefox-esr31 --- wontfix

People

(Reporter: cghwong, Unassigned)

References

(Depends on 1 open bug, )

Details

(5 keywords, Whiteboard: [fingerprinting][fp-triaged])

Attachments

(3 files, 1 obsolete file)

Attached file fftest.html —
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131205075310

Steps to reproduce:

Reported By: 
Jaap Karan Singh and Colin Wong, BAE Systems Detica

Firefox attempts to prevent internal IP address leakage via the SDP offer description by requiring streams to be added to a RTC peer connection before createOffer() can be called. This is usually done through calling getUserMedia(), which requires user authorisation. Firefox also prevents MediaStream constructors from being called directly. However, a RTC data channel bypasses this requirement by creating a stream without any user prompts, as no access to camera or microphone is requested.

Please see the attached fftest.html file for an example. It will write out the SDP description into the page, which contains all identified IP addresses for the endpoint so that a P2P connection can be established. The peer.localDescription object can also be inspected in the console.


Actual results:

Internal IP addresses can be leaked to the web page without any user notification.


Expected results:

The root question here is whether the browser should be able to initiate and establish P2P connections without notifying the user. Based on other WebRTC behaviour implemented in Firefox, it appears that this was to be prevented so that internal IP addresses cannot be leaked to a web page without calling getUserMedia() and causing a user prompt. In any case, the WebRTC implementation should be made consistent with whatever is decided.
Component: Untriaged → WebRTC
Product: Firefox → Core
I've see this discussed publicly on twitter and elsewhere, and there are public demos so I don't think we need to keep this hidden. (e.g. http://net.ipcalf.com/) 

I wonder if the peerconnection spec says anything about this?
Group: core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
ekr: how are we meeting any of the MUST requirements in that section?

*  MUST provide a mechanism to allow the JS to suppress ICE negotiation
   ... until the user has decided to answer the call

*  MUST provide a mechanism for the calling application JS to indicate
   that only TURN candidates are to be used.

There isn't even any user-visible way to disable WebRTC entirely for people who are concerned, none of the buried prefs are surfaced to the UI. If people are using a VPN/proxy for privacy reasons they have no reason to suspect we've added a feature that blows a hole in that. We've violated the "No Surprises" rule (and probably the same-origin policy in some people's mind: the peer connection is not same-origin with the page running the script).

The following example was mailed to security@ this morning and making the rounds on twitter

http://bric.lepus.uberspace.de/ff28Fail.html

Note that the LAN address (e.g. 192.168.*) is not the biggest concern, but that when trying to preserve some anonymity by using a VPN the user's real IP address is exposed in addition to the LAN IP and the VPN's IPs.
(In reply to Daniel Veditz [:dveditz] from comment #3)
> ekr: how are we meeting any of the MUST requirements in that section?
> 
> *  MUST provide a mechanism to allow the JS to suppress ICE negotiation
>    ... until the user has decided to answer the call

This is straightforward. The JS simply doesn't do SetRemote() until its
ready. It's not awesome, but it will work. We could certainly do better.


> *  MUST provide a mechanism for the calling application JS to indicate
>    that only TURN candidates are to be used.

We do not do this. However, note that both of these are about allowing
the site to build an anonymous calling service, not about concealing the
user's IP address from the site. So, these requirements are important
but the site isn't required to use this facility.


> There isn't even any user-visible way to disable WebRTC entirely for people
> who are concerned, none of the buried prefs are surfaced to the UI. If
> people are using a VPN/proxy for privacy reasons they have no reason to
> suspect we've added a feature that blows a hole in that. We've violated the
> "No Surprises" rule (and probably the same-origin policy in some people's
> mind: the peer connection is not same-origin with the page running the
> script).
> 
> The following example was mailed to security@ this morning and making the
> rounds on twitter
> 
> http://bric.lepus.uberspace.de/ff28Fail.html
> 
> Note that the LAN address (e.g. 192.168.*) is not the biggest concern, but
> that when trying to preserve some anonymity by using a VPN the user's real
> IP address is exposed in addition to the LAN IP and the VPN's IPs.

For context, the way that ICE works is that you gather all the addresses
that you know about and communicate them to the other side. These addresses
are gathered in roughly three ways:

- Looking at the addresses of your local interfaces (which includes VPN tunnels)
- Determining what addresses sites on the public internet see you coming in from.
- Explicitly setting up relay channels to public relays on the Internet.

The reason for doing this is that you don't know in advance what the path between
us and the counterparty is. So, consider the case where you and I are on the
same network and yet behind a NAT. We obviously don't want to send the data out
to the public internet and then back (this may not even work) we just want to send
it directly. In order for that to work, we need to provide our local IP address
to the other side, and that means it's available to the site. We could certainly
add browser controls to refuse to provide the local IP address as one of the ICE
candidates, but actually frobbing those controls would have a seriously negative
impact on performance.

WRT the specific question of VPNs, it might be possible for us to determine when
VPNs are in use and suppress all local addresses that aren't tied to the VPN.
This would presumably require some system-specific code and might even depend
on exactly how the VPN was installed. If, for instance, the VPN just overrides
the default route, then that may be hard to distinguish from the ordinary routing
situation.

Certainly we could also provide a clearer UI gizmo to disable WebRTC entirely.
Flags: needinfo?(ekr)
Only to set this into the right perspective:

There are two issues:
1. reveil of internal LAN IPs
2. deanonymizing VPN/Proxy access

i guess from a network admin security perspective no 1 is of certain importance. 
But taking into account that people that use Firefox with VPN/Proxy have a high interest in not becoming chased by somebody/authorities/regimes no 2 is the real threat here. The actual situation is, that they feel secure (Firefox plus VPN/Proxy) but can be tracked instantly on any site they visit resp. by javascript injection on the wire.

Therefore - to keep the security image of firefox fighting for pricacy up - a hard wired user consent (with notifying them of the demascing risk) before starting the peerconnection to perform the STUN server request is needed.

This solution would even be better than going with about:config webRTC Y/N, because users might forget about their actual settings.
Revealing internal LAN IPs (of almost all devices on your local net) can be done without use of WebRTC.  WebRTC may expose the local LAN address of the browser more easily, but often this can be guessed from the scan of other LAN addresses.

As a feature, requiring user consent for every PeerConnection would make the feature largely unusable for the intended usecases.  Having Firefox (and WebRTC) be cognizant of running in VPN/privacy mode would go a long way to making this work without walling off functionality for the normal case.  Other things might well be gated off such a setting as well to improve privacy.

Use of a VPN for anonymity is an important usecase for Firefox, but one that's used by a tiny fraction of users.  If we can't detect it directly/automatically, a "UsingVPN" setting and an extension(s) to provide a UI element to enable/disable (and/or which knows how to probe for a specific VPN(s) in use) would be useful.  It's slightly less clear that the intent of an general HTTP proxy is and what impact that should have on WebRTC.

It should also be easy to build an extension to Firefox that adds a permission prompt to all PeerConnection requests (perhaps with the option to filter certain candidates, or limit all candidates to TURN).
(In reply to Randell Jesup [:jesup] from comment #6)
> Revealing internal LAN IPs (of almost all devices on your local net) can be
> done without use of WebRTC.  WebRTC may expose the local LAN address of the
> browser more easily, but often this can be guessed from the scan of other
> LAN addresses.
> 
> As a feature, requiring user consent for every PeerConnection would make the
> feature largely unusable for the intended usecases.  Having Firefox (and
> WebRTC) be cognizant of running in VPN/privacy mode would go a long way to
> making this work without walling off functionality for the normal case. 
> Other things might well be gated off such a setting as well to improve
> privacy.
> 
> Use of a VPN for anonymity is an important usecase for Firefox, but one
> that's used by a tiny fraction of users.  If we can't detect it
> directly/automatically, a "UsingVPN" setting and an extension(s) to provide
> a UI element to enable/disable (and/or which knows how to probe for a
> specific VPN(s) in use) would be useful.  It's slightly less clear that the
> intent of an general HTTP proxy is and what impact that should have on
> WebRTC.
> 
> It should also be easy to build an extension to Firefox that adds a
> permission prompt to all PeerConnection requests (perhaps with the option to
> filter certain candidates, or limit all candidates to TURN).

This is about right.  Since we can't distinguish VPN interfaces from non-VPN interfaces, the only thing we can do is disable local candidates entirely.  Seems like a reasonable thing to be controlled with an about:config pref, which could be set either manually or by something like TOR Browser.
I think that if you are using a VPN for anonymity, it makes a lot of sense for that to be as explicit as possible and surfaced to the browser.  I wouldn't be surprised if there are other things one wishes to tie to this.
indeed, this seems like a hard to satisfy corner case of https://bugzilla.mozilla.org/show_bug.cgi?id=354493 (which is already hard to satisfy).. sworkman is going to take a crack at least improving the situation.
Incidentally, based on conversations with Justin Uberti, I believe Chrome behaves much the same way we do.

Incidentally, RFC 5245 explicitly considers the case of VPNs and says you should downprioritize them:

https://tools.ietf.org/html/rfc5245#section-4.1.2.2

   One criterion for selection of the type and local preference values
   is the use of a media intermediary, such as a TURN server, VPN
   server, or NAT.  With a media intermediary, if media is sent to that
   candidate, it will first transit the media intermediary before being
   received.  Relayed candidates are one type of candidate that involves
   a media intermediary.  Another are host candidates obtained from a
   VPN interface.  When media is transited through a media intermediary,
   it can increase the latency between transmission and reception.  It
   can increase the packet losses, because of the additional router hops
   that may be taken.  It may increase the cost of providing service,
   since media will be routed in and right back out of a media
   intermediary run by a provider.  If these concerns are important, the
   type preference for relayed candidates SHOULD be lower than host
   candidates.  The RECOMMENDED values are 126 for host candidates, 100
   for server reflexive candidates, 110 for peer reflexive candidates,
   and 0 for relayed candidates.  Furthermore, if an agent is multihomed
   and has multiple IP addresses, the local preference for host
   candidates from a VPN interface SHOULD have a priority of 0.
(In reply to Eric Rescorla (:ekr) from comment #10)
> Incidentally, based on conversations with Justin Uberti, I believe Chrome
> behaves much the same way we do.
> 
> Incidentally, RFC 5245 explicitly considers the case of VPNs and says you
> should downprioritize them:

Right, but I don't think that's covering the case driving this bug (anonymizing VPNs, as opposed to VPN-for-access-to-restricted-networks).  For this case, we want to force either TURN or VPN access (and TURN may not be safe either) - so this is largely a "anonymizing proxy use needs to directly control what interfaces are exposed in ICE" likely via an extension, per above.  For the case considered in the RFC, you want to keep the traffic off the VPN if the normal external interface is up, if possible - virtually the opposite.

(In reply to Patrick McManus [:mcmanus] from comment #9)
> indeed, this seems like a hard to satisfy corner case of
> https://bugzilla.mozilla.org/show_bug.cgi?id=354493 (which is already hard
> to satisfy).. sworkman is going to take a crack at least improving the
> situation.

The example I saw that showed you all the internal addresses on 192.168.* that were in use didn't actually need to use WebRTC at all to gather those (i.e. a variation of the above bug).
(In reply to Randell Jesup [:jesup] from comment #11)
> (In reply to Eric Rescorla (:ekr) from comment #10)
> > Incidentally, based on conversations with Justin Uberti, I believe Chrome
> > behaves much the same way we do.
> > 
> > Incidentally, RFC 5245 explicitly considers the case of VPNs and says you
> > should downprioritize them:
> 
> Right, but I don't think that's covering the case driving this bug
> (anonymizing VPNs, as opposed to VPN-for-access-to-restricted-networks). 
> For this case, we want to force either TURN or VPN access (and TURN may not
> be safe either) - so this is largely a "anonymizing proxy use needs to
> directly control what interfaces are exposed in ICE" likely via an
> extension, per above.  For the case considered in the RFC, you want to keep
> the traffic off the VPN if the normal external interface is up, if possible
> - virtually the opposite.

Correct. What I was trying to say is that these two cases are hard to
distinguish from the browser.
 

> (In reply to Patrick McManus [:mcmanus] from comment #9)
> > indeed, this seems like a hard to satisfy corner case of
> > https://bugzilla.mozilla.org/show_bug.cgi?id=354493 (which is already hard
> > to satisfy).. sworkman is going to take a crack at least improving the
> > situation.
> 
> The example I saw that showed you all the internal addresses on 192.168.*
> that were in use didn't actually need to use WebRTC at all to gather those
> (i.e. a variation of the above bug).
No longer tracking for 29. I don't think we are going to block the 29 release because of this bug.
OS: Windows 7 → All
We're not blocking any releases on this bug, it's a sec-want and can be nominated for uplift to whichever branches are appropriate depending on when a patch is ready.
As far as I know, we don't intend to change anything here.
Whiteboard: [fingerprinting]
Is this bug why https://github.com/diafygi/webrtc-ips works on Nightly?

A tad scary I must say...
(In reply to alex_mayorga from comment #18)
> Is this bug why https://github.com/diafygi/webrtc-ips works on Nightly?
> 
> A tad scary I must say...

Actually, it has been able to work on Release since long ago...
I think it is a critical problem, because it can provide websites a very large fingerprint without acknowlegment from users.

I remember we rejected bug 1008453 to be implemented mostly because it exposes the number of computing cores of a machine, which is usually not that private. But here we expose much more information to the web without a corresponding concern.
Severity: normal → critical
Hardware: x86_64 → All
Version: 26 Branch → Trunk
> The root question here is whether the browser should be able to initiate and
> establish P2P connections without notifying the user. Based on other WebRTC
> behaviour implemented in Firefox, it appears that this was to be prevented
> so that internal IP addresses cannot be leaked to a web page without calling
> getUserMedia() and causing a user prompt. In any case, the WebRTC
> implementation should be made consistent with whatever is decided.

I agree with the original poster. The best solution to this is for the user to be prompted for confirmation when createDataChannel() is called, just like when getUserMedia() is called.
(In reply to Lukas Blakk [:lsblakk] use ?needinfo from comment #14)
> We're not blocking any releases on this bug, it's a sec-want and can be
> nominated for uplift to whichever branches are appropriate depending on when
> a patch is ready.

No, this is not a sec-want, this is a bug. If you find a need to implement this facepalm of an RFC, just show ask the user, like you do before letting websites access the user's webcam, microphone or location. You added a feature that breaks my privacy, to I have to ask *you* to fix this *before* shipping release versions of Firefox with this feature enabled by default.

If a user is using a VPN or an anonymizing proxy, he cannot reasonably exepect that his browser is actively helping websites to circumvent that layer of anonymization by happily enumarating his network devices. What the heck were you thinking when implementing this ****? Are you also going to incorporate my CPUID or a list of the PCI IDs present on my machine into the useragent header if some idiot manages to get such a requirement in some broken RFC?!

Please stop implementing unneeded **** "features" without thinking them through and make Firefox a browser again. You have failed to deliver a proper UI for the user to control DOM storage for years, you have failed to think about the consequences of enabling link prefetching and DNS prefetching by default (which actually enables spammers to tell wether I have opened/read an email or not), you have failed to offer a way to enable or disable NPAPI plugins on a site-per-site basis, you have failed to offer. You have failed for years to provide users with a possibility to prevent HTTP referers from compromising their privacy. You have failed to provide users with means to mitigate the threats that cookies pose to their privacy. You have failed to implement DNSSEC and TLSA in a way that would actually help the user. You have failed to implement TLS certificate pinning. You have even failed to implement HTML5 form input types. Why the heck do you waste your time fiddling around with WebRTC?

Please stop failing at protecting your users privacy. Stop using "but Google Chrome is broken in the same way" as an excuse for implementing broken standards. If I wanted my browser to be broken the same way as Google Chrome is, I'd probably use Google Chrome instead of Firefox.

I'm really begging you, Firefox is the last browser where I have at least a minor hope the it can be brought to a state where it enables privacy concerned users to browser the web with at least *some* peace of mind. I don't want to have to install half a dozen extensions anymore everytime I install Firefox just to be able to browser the web without having my browser compromise my privacy.

There reason why Firefox has lost such a huge market share to Chrome is not because Chrome is so good, it is because the Mozilla devs have mad Firefox so bad over the years.

I can understand why you don't ship with features like "RequestPolicy". But where is the problem in asking the user *before* compromising his VPN? Where is the problem in asking the user whether he actually wants links or DNS names in his spam mails to be prefetched the moment he opens them? Where is the problem with offering users to actually edit the lists of the sites that are allowed to use Java or Flash while enabling the user to keep those plugins disabled by default? Where is the problem with keeping a list of sites that should not get to know the user's real referer when clicking a link? Where is the problem with enabling a user to prevent the browser from loading external content from tracking networks?

Why don't you care about your user's privacy anymore?
This does not only affect VPNs. My WMC TV tuner (Hauppauge DCR-2650 CableCARD) is leaking IP information as well.
(In reply to Dan Q (RedBlade7) from comment #27)
> This does not only affect VPNs. My WMC TV tuner (Hauppauge DCR-2650
> CableCARD) is leaking IP information as well.

VirtualBox too
Blocks: 1128236
(In reply to Dan Q (RedBlade7) from comment #28)
> (In reply to Dan Q (RedBlade7) from comment #27)
> > This does not only affect VPNs. My WMC TV tuner (Hauppauge DCR-2650
> > CableCARD) is leaking IP information as well.
> 
> VirtualBox too

If you mean you see ICE/etc candidates for your connection to virtualbox or other VPN-ish links, that's totally to be expected - the browser doesn't know (so far as I know) that the "connection" is a virtual one to a VM - nor if that's really a gateway to the network or not (example: using a VM as a "dedicated" firewall).  Per rbarnes above and some previous bugs, I don't think that we can reliably even tell if a connection is a VPN connection on all platforms.

I imagine the same happens on Chrome.  

We're open to suggestions that don't break primary usecases.
As an end-user, I would at least like to have an option to turn this off/on more easily than in about:config. Here are some ideas:
Enable it on a per-site basis. I see no reason why github would want to video-chat with me. Pre-configure some sites which are well known webRTC sites, make the list editable. 
Chose to disable, enable or ask:
Pop up an ask dialog if the network config seems to contain multiple IPs, which indicates then probably a user who is running VPNs or VMs, and so among the "power users". Something like: "this website uses WebRTC, which will make all your IPs known. If you run a VPN and you don't plan to do videochat on example.com. it is advisable to disable WebRTC for this site by clicking here:"
Most of the code is there, we got cookie editing, certificate lists and so on. So a list for WEBrtc would be the most appropriate solution.
(In reply to Gunstick from comment #30)
> As an end-user, I would at least like to have an option to turn this off/on
> more easily than in about:config. Here are some ideas:
> Enable it on a per-site basis. I see no reason why github would want to
> video-chat with me. Pre-configure some sites which are well known webRTC
> sites, make the list editable. 

We don't need a secret whitelist. This is not just about VPNs for privacy conscious people, TV tuners, or virtual machines - corporate VPNs can leak sensitive information about trade secrets. 

I know one person who works for a Fortune 500 company and has to use a corporate-run VPN on a nonrechargeable laptop to prevent information from being leaked. You might want to think about dangerous situations like these.

A better idea would having WebRTC off by default and giving an "Ask To Activate" with optional "Remember for this site", just like with Flash and other plugins.
(In reply to Dan Q (RedBlade7) from comment #31)
> (In reply to Gunstick from comment #30)
> > As an end-user, I would at least like to have an option to turn this off/on
> > more easily than in about:config. Here are some ideas:
> > Enable it on a per-site basis. I see no reason why github would want to
> > video-chat with me. Pre-configure some sites which are well known webRTC
> > sites, make the list editable. 
> 
> We don't need a secret whitelist.

He probably didn't mean to whitelist sites, but rather something similar to the certificate store - just for WebRTC websites instead of certificate authorities.
(In reply to Randell Jesup [:jesup] from comment #6)
> Revealing internal LAN IPs (of almost all devices on your local net) can be
> done without use of WebRTC.

How can?

> WebRTC may expose the local LAN address of the
> browser more easily, but often this can be guessed from the scan of other
> LAN addresses.

Content scripts from random web sites can not scan LAN addresses because of the same origin policy. WebRTC even subverts the SOP.
(In reply to Masatoshi Kimura [:emk] from comment #33)
> (In reply to Randell Jesup [:jesup] from comment #6)
> > Revealing internal LAN IPs (of almost all devices on your local net) can be
> > done without use of WebRTC.
> 
> How can?
> 
> > WebRTC may expose the local LAN address of the
> > browser more easily, but often this can be guessed from the scan of other
> > LAN addresses.
> 
> Content scripts from random web sites can not scan LAN addresses because of
> the same origin policy. WebRTC even subverts the SOP.

Hmm.... Please describe the attack you have in mind. Note that content scripts
actually can talk to arbitrary local LAN addresses, they just can't read the
response. And WebRTC incorporates a consent check before it lets you send
application-controlled data somewhere. So, what is it specifically you think that
WebRTC lets you do?
(In reply to Eric Rescorla (:ekr) from comment #34)
> (In reply to Masatoshi Kimura [:emk] from comment #33)
> > (In reply to Randell Jesup [:jesup] from comment #6)
> > > Revealing internal LAN IPs (of almost all devices on your local net) can be
> > > done without use of WebRTC.
> > 
> > How can?
> > 
> > > WebRTC may expose the local LAN address of the
> > > browser more easily, but often this can be guessed from the scan of other
> > > LAN addresses.
> > 
> > Content scripts from random web sites can not scan LAN addresses because of
> > the same origin policy. WebRTC even subverts the SOP.
> 
> Hmm.... Please describe the attack you have in mind. Note that content scripts
> actually can talk to arbitrary local LAN addresses, they just can't read the
> response.

They can talk to arbitrary local LAN addresses via XHR, but they can only collect information via checking the interval between callbacks being invoked. AFAICS, the detailed error information is not provided to the content script. However, time is a very unreliable information. In LAN, the deviation of delay of local response may even be larger than the network delay. Hence it is almost, if not completely, infeasible to detect local address via things like XHR.

In addition, it is infeasible to detect *all* IP addresses of a machine, because of the large address space.

> And WebRTC incorporates a consent check before it lets you send
> application-controlled data somewhere. So, what is it specifically you think
> that WebRTC lets you do?

No, it doesn't ask anything before it provides the IP addresses to the content script.
(In reply to Xidorn Quan [:xidorn] (UTC+11) from comment #35)
> (In reply to Eric Rescorla (:ekr) from comment #34)
> > (In reply to Masatoshi Kimura [:emk] from comment #33)
> > > (In reply to Randell Jesup [:jesup] from comment #6)
> > > > Revealing internal LAN IPs (of almost all devices on your local net) can be
> > > > done without use of WebRTC.
> > > 
> > > How can?
> > > 
> > > > WebRTC may expose the local LAN address of the
> > > > browser more easily, but often this can be guessed from the scan of other
> > > > LAN addresses.
> > > 
> > > Content scripts from random web sites can not scan LAN addresses because of
> > > the same origin policy. WebRTC even subverts the SOP.
> > 
> > Hmm.... Please describe the attack you have in mind. Note that content scripts
> > actually can talk to arbitrary local LAN addresses, they just can't read the
> > response.
> 
> They can talk to arbitrary local LAN addresses via XHR, but they can only
> collect information via checking the interval between callbacks being
> invoked. AFAICS, the detailed error information is not provided to the
> content script. 

Yes, that's correct.

> However, time is a very unreliable information. In LAN, the
> deviation of delay of local response may even be larger than the network
> delay. Hence it is almost, if not completely, infeasible to detect local
> address via things like XHR.
> 
> In addition, it is infeasible to detect *all* IP addresses of a machine,
> because of the large address space.
> 
> > And WebRTC incorporates a consent check before it lets you send
> > application-controlled data somewhere. So, what is it specifically you think
> > that WebRTC lets you do?
> 
> No, it doesn't ask anything before it provides the IP addresses to the
> content script.

It provides the machine's local address, but not any addresses of other
machines on the LAN.

Again, I'd encourage you to describe the attack you are concerned about.
Is it merely disclosure of the local IP addresses of the machine, or something
else?
(In reply to Eric Rescorla (:ekr) from comment #36)
> Again, I'd encourage you to describe the attack you are concerned about.
> Is it merely disclosure of the local IP addresses of the machine, or
> something else?

To me, yes. I'm not sure whether :emk has any other attacks in mind. But I think disclosure of local addresses has been terrible enough.
You are right in that the attack lets you discover local IP addresses of the affected user. However, making it trivial to discover local IP addresses makes it much easier to start exploiting weaknesses in the local network from arbitrary websites with malicious intent.

It may also be used as another vector in trying to persistently identify a user's identity bypassing any anonymising controls such as Tor, VPN etc. This is a very serious privacy issue for Firefox users.
As I said in comment #2, Firefox is conformant to the RTCWEB specification,
so you should raise this issue on the IETF RTCWEB mailing list:

https://www.ietf.org/mailman/listinfo/rtcweb'


I (and others) do appreciate that this has negative impacts if you are
trying to hide your IP address and if you have a proposal for how Firefox
can determine that people want that and suppress WebRTC, that's something
we could look at.
I propose that we have an individual permission bit for sites to control whether one is allowed to use webrtc, just like what we do for things in about:permissions.

I guess we can do this when the content script invokes createOffer, which can be responsed async. Does it sound like a feasible solution?
I don't really understand what you're proposing. I would not be in favor of changing Firefox to by default prompt users before sites are allowed to use WebRTC.
(In reply to Eric Rescorla (:ekr) from comment #41)
> I don't really understand what you're proposing. I would not be in favor of
> changing Firefox to by default prompt users before sites are allowed to use
> WebRTC.

We do it for gUM(). Why not for the other apis?
Yes, I propose that we prompt users before sites are allowed to use WebRTC. If they also uses media capture, then we may grant WebRTC permission as soon as user allow the site to use microphone or camera, so that we don't add one more prompt to annoy users. But if a site uses data channel only, I think it is reasonble to promot user for permission before we leak any privacy info to the site.
(In reply to Fabrice Desré [:fabrice] from comment #42)
> (In reply to Eric Rescorla (:ekr) from comment #41)
> > I don't really understand what you're proposing. I would not be in favor of
> > changing Firefox to by default prompt users before sites are allowed to use
> > WebRTC.
> 
> We do it for gUM(). Why not for the other apis?

Because the other APIs hae significantly different privacy implications
as explained in detail in the RTCWEB Specification
(In reply to Xidorn Quan [:xidorn] (UTC+11) from comment #43)
> Yes, I propose that we prompt users before sites are allowed to use WebRTC.
> If they also uses media capture, then we may grant WebRTC permission as soon
> as user allow the site to use microphone or camera, so that we don't add one
> more prompt to annoy users. But if a site uses data channel only, I think it
> is reasonble to promot user for permission before we leak any privacy info
> to the site.

Yes, this was extensively discussed and the decision was made not
to prompt in this case. I realize that some people are not happy
about that, but I haven't seen any points made here that were not
made the last time we discussed it.

Jesup, I propose we close this with WONTFIX.
Flags: needinfo?(rjesup)
Can you give pointers to these previous discussions?
(In reply to jksdua from comment #38)
> 
> It may also be used as another vector in trying to persistently identify a
> user's identity bypassing any anonymising controls such as Tor, VPN etc.
> This is a very serious privacy issue for Firefox users.

And corporate VPNs that deal with trade secrets.
(In reply to Dan Q (RedBlade7) from comment #47)
> (In reply to jksdua from comment #38)
> > 
> > It may also be used as another vector in trying to persistently identify a
> > user's identity bypassing any anonymising controls such as Tor, VPN etc.
> > This is a very serious privacy issue for Firefox users.
> 
> And corporate VPNs that deal with trade secrets.

And VirtualBox. And CableCARD. And corporate Intranets that deal with trade secrets.
(In reply to Dan Q (RedBlade7) from comment #48)
> (In reply to Dan Q (RedBlade7) from comment #47)
> > (In reply to jksdua from comment #38)
> > > 
> > > It may also be used as another vector in trying to persistently identify a
> > > user's identity bypassing any anonymising controls such as Tor, VPN etc.
> > > This is a very serious privacy issue for Firefox users.
> > 
> > And corporate VPNs that deal with trade secrets.
> 
> And VirtualBox. And CableCARD. And corporate Intranets that deal with trade
> secrets.

Do you think there could be serious legal consequences if one was to use Firefox in a corporate setting?
No longer blocks: 1128236
(In reply to Eric Rescorla (:ekr) from comment #39)
> As I said in comment #2, Firefox is conformant to the RTCWEB specification

I've done a lot of reading, and it seems that there's some wiggle room in the specifications.

First, when calling createOffer() to generate the SDP, it says, "To Do: Discuss privacy aspects of this from a fingerprinting point of view - it's probably around as bad as access to a canvas :-)"[1]. This seems exactly what we are discussing here!

Additionally, the SDP blob that is being generated is specified in RFC 3264[2], who's abstract states, "This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them." I interpret this as assuming that the two "entities" have given consent to the communication.

So, from the SDP spec and the WebRTC note, it would be very easy to conclude that in order to generate the SDP blob, you need user consent. Therefore, if Firefox has not already obtained user consent via the getUserMedia() requirement[3], calling createOffer() MUST include a prompt asking the user for consent to create the offer.

Second, even if a stun server is unreachable, IP addresses other than your local IP address will still sometimes appear as ICE candidates because of the computer's network setup[4]. On Windows using many common VPN setups, this results in the both the public IP and VPN internal IP being made available as ICE candidates, even without the STUN request.

From as far as I can tell, this is because in the ICE spec, it says, "If an agent is multihomed, it obtains a candidate from each IP address."[5] However, I'm confused on how the browsers knows if the computer is multihomed. When sending a normal HTTP request to https://www.mozilla.org/ which network interface is used? Does the browser get to choose network interfaces or is it given one by the operating system?

The browser must know which network interface is being used for its other internet connections, even if it knows all the network interfaces available (which is still weird to me). Given that, and the fact that the ICE specification for multihoming is optional, Firefox should consider itself never multihomed and only the local IP address that is used for internet connectivity (i.e. what it is using to make the STUN request) and the STUN request result be made avaiable as an ICE candidate.

So to recap, here's what I propose:

1. If not already obtained via getUserMedia(), get user consent when createOffer() is called.

2. Only offer the local IP address that is used to make the STUN request as a local ICE candidate.


[1]: https://w3c.github.io/webrtc-pc/#widl-RTCPeerConnection-createOffer-Promise-RTCSessionDescription--RTCOfferOptions-options
[2]: http://tools.ietf.org/html/rfc3264
[3]: http://www.w3.org/TR/mediacapture-streams/#dom-navigator-getusermedia
[4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1128236#c7
[5]: https://tools.ietf.org/html/rfc5245#section-2.1
(In reply to Daniel Roesler from comment #51)
> (In reply to Eric Rescorla (:ekr) from comment #39)
> > As I said in comment #2, Firefox is conformant to the RTCWEB specification
> 
> I've done a lot of reading, and it seems that there's some wiggle room in
> the specifications.
> 
> First, when calling createOffer() to generate the SDP, it says, "To Do:
> Discuss privacy aspects of this from a fingerprinting point of view - it's
> probably around as bad as access to a canvas :-)"[1]. This seems exactly
> what we are discussing here!

This note is primarily about codec capabilities, etc. not IP addresses.
The IETF WG discussed the behavior around IP addresses and had consensus
that merely setting up the communications channel using ICE should not
require consent. Again, I encourage you to raise this on the WG lists.
Is there an addon allowing to filter out e.g. 192.168.0.0/16 and 10.0.0.0/8 addresses? Such addon with configurable masks list should probably satisfy most of the people complaining about this issue.
(In reply to Sergey from comment #53)
> Is there an addon allowing to filter out e.g. 192.168.0.0/16 and 10.0.0.0/8
> addresses? Such addon with configurable masks list should probably satisfy
> most of the people complaining about this issue.

That's not the biggest issue. The biggest issue is that WebRTC exposes your real IP for VPN users (PPTP or IPSEC/L2TP, dunno about OpenVPN). See #1128236, which for some reason is marked as a duplicate of this bug.

Why that doesn't qualify as a big security issue, I don't know.
> The biggest issue is that WebRTC exposes your real IP for VPN users
> (PPTP or IPSEC/L2TP, dunno about OpenVPN). See #1128236, which for
> some reason is marked as a duplicate of this bug.

That issue could also be solved by such addon by adding your real ip/mask to the exclusion filter list of that addon.
(In reply to Daniel Roesler from comment #54)
> (In reply to Sergey from comment #53)
> > Is there an addon allowing to filter out e.g. 192.168.0.0/16 and 10.0.0.0/8
> > addresses? Such addon with configurable masks list should probably satisfy
> > most of the people complaining about this issue.
> 
> That's not the biggest issue. The biggest issue is that WebRTC exposes your
> real IP for VPN users (PPTP or IPSEC/L2TP, dunno about OpenVPN). See
> #1128236, which for some reason is marked as a duplicate of this bug.
> 
> Why that doesn't qualify as a big security issue, I don't know.

Yes it does affect OpenVPN too.

The biggest issue here is the leak of confidential corporate information, whether it a remote VPN or just their in-office Intranet. You shouldn't need a browser addon to prevent that, especially since it would require the IT department to place the company's office Intranet in the hands of random addon developers.
(In reply to Dan Q (RedBlade7) from comment #56)
> You shouldn't need a browser addon to prevent that, especially since
> it would require the IT department to place the company's office
> Intranet in the hands of random addon developers.

Sure it would be nice to have such feature in firefox. But having it as addon is still better than nothing. IT department could at least drop a preconfigured addon if such addon exists.
I created an add-on to help relieve some of the pressure with the mixed feelings, it's submitted to AMO for Review as of 5 minutes ago: https://addons.mozilla.org/en-US/firefox/addon/statutory/   

I also created a light weight version only 11kb which i attached until an official solution can be found.  

Once again this is unofficial it can be verified. 

This overwrites the RTC constructors with my own functions then displays notification popups for the user to click to enable access. I set a preference to disable notifications in the event the user would only like to prevent WebRTC all together.
Attachment #8570681 - Attachment description: Blank → statutory add-on to notify users of (new mozPeerConnection)
Attachment #8570681 - Attachment is obsolete: true
Attachment #8570682 - Attachment description: statutory add-on take 2 → statutory add-on to notify users of (new mozPeerConnection), take 2
(In reply to Sergey from comment #57)
> (In reply to Dan Q (RedBlade7) from comment #56)
> > You shouldn't need a browser addon to prevent that, especially since
> > it would require the IT department to place the company's office
> > Intranet in the hands of random addon developers.
> 
> Sure it would be nice to have such feature in firefox. But having it as
> addon is still better than nothing. IT department could at least drop a
> preconfigured addon if such addon exists.

Here is a good example of what I'm talking about. 

1. Say for instance you knew RedBlade7 came from Bladetown, and that RedBlade7 had a CableCARD tuner.
2. You look up Bladetown and find out Bladetown Cablecorp is the only cable TV provider. 
3. A malicious user takes advantage of the WebRTC leakage, and can find out RedBlade7's tuner's IP, subnet, etc. 
4. Bladetown Cablecorp's network configuration is now public knowledge.
(In reply to Dan Q (RedBlade7) from comment #61)
> (In reply to Sergey from comment #57)
> > (In reply to Dan Q (RedBlade7) from comment #56)
> > > You shouldn't need a browser addon to prevent that, especially since
> > > it would require the IT department to place the company's office
> > > Intranet in the hands of random addon developers.
> > 
> > Sure it would be nice to have such feature in firefox. But having it as
> > addon is still better than nothing. IT department could at least drop a
> > preconfigured addon if such addon exists.
> 
> Here is a good example of what I'm talking about. 
> 
> 1. Say for instance you knew RedBlade7 came from Bladetown, and that
> RedBlade7 had a CableCARD tuner.
> 2. You look up Bladetown and find out Bladetown Cablecorp is the only cable
> TV provider. 
> 3. A malicious user takes advantage of the WebRTC leakage, and can find out
> RedBlade7's tuner's IP, subnet, etc. 
> 4. Bladetown Cablecorp's network configuration is now public knowledge.

edit: subnet->DNS server (and the device does have its own DNS server)
Attachment #8570681 - Attachment filename: Blank → statutory.xpi
Attachment #8570681 - Attachment is obsolete: false
Attachment #8570681 - Attachment mime type: application/vnd.mozilla.xul+xml → application/x-xpinstall
Attachment #8570682 - Attachment is obsolete: true
(In reply to Jared Null from comment #58)
> Created attachment 8570681 [details]
> statutory add-on to notify users of (new mozPeerConnection)
> 
> I created an add-on to help relieve some of the pressure with the mixed
> feelings, it's submitted to AMO for Review as of 5 minutes ago:
> https://addons.mozilla.org/en-US/firefox/addon/statutory/   
> 
> I also created a light weight version only 11kb which i attached until an
> official solution can be found.  
> 
> Once again this is unofficial it can be verified. 
> 
> This overwrites the RTC constructors with my own functions then displays
> notification popups for the user to click to enable access. I set a
> preference to disable notifications in the event the user would only like to
> prevent WebRTC all together.

Your add-on does not install on Firefox Android.  Can you make it available there as well?
Stopped the leak on Firefox on Windows.  Should be the default condition.  
Chrome does the same? OF COURSE it does. collecting info like that is how google makes their money.
You can do better!  Remember, you work for the Users, not the Standard committee or the Web infotainment industry.  Fix this ASAP, then issue a press release on how Chrome is revealing private info without permission.  (My internal LAN configuration IS private - no one's business but mine!!)

VPN's are not the problem.  Most access is through a NAT router.   The combination of public ISP address and LAN address allows the identification of a particular device, and once you ever log in to some site, a particular user.   Instead of one of 100 devices at XYZ corp, you are using a Particular device.  Once you log in to a site that traffics in such info, you are tied to that device on any web site you visit which also traffics in such info, without a login.  This bug makes device fingerprinting trivial.

As to VPN's: When I access the VPN at the University of Michigan, net.ipcalf.com sees my lan address and a U-M address.  It does not see my ISP address. So, if my lan address is in the usual recommended ranges, there could be MANY devices with that address, and the next time I log in to the VPN, that address will change as well.  In my case however, I do not use the usual address ranges, I use addresses assigned to an internal Sun Microsystems network which Sun, back in the day, suggested people use for their internal networks, so my lan address is probably much closer to unique.  
And, "Complies with the Standard" is a lame excuse for **** software.
> Stopped the leak on Firefox on Windows.  Should be the default condition.  
> Chrome does the same? OF COURSE it does. collecting info like that is how
> google makes their money.

While Google does make their money from user info, they don't need this to do it.  An addon like this is a reasonable option for those who want to control access to these features.

> You can do better!  Remember, you work for the Users, not the Standard
> committee or the Web infotainment industry.  Fix this ASAP, then issue a
> press release on how Chrome is revealing private info without permission. 
> (My internal LAN configuration IS private - no one's business but mine!!)

Fixing this the way you suggest would seriously hurt most users of the API.  There are plenty of security/privacy advocates/paranoids in the IETF, and the spec is the result of such discussions.

> VPN's are not the problem.  Most access is through a NAT router.   The
> combination of public ISP address and LAN address allows the identification
> of a particular device, and once you ever log in to some site, a particular
> user.   Instead of one of 100 devices at XYZ corp, you are using a
> Particular device.  Once you log in to a site that traffics in such info,
> you are tied to that device on any web site you visit which also traffics in
> such info, without a login.  This bug makes device fingerprinting trivial.

Device fingerprinting is (unfortunately) far more trivial than you realize, without this.  Your addons and fontlist alone (unless you run a set of virtually-untouched clones) does wonders for fingerprinting.  Panopticlick tells me that my plugin list alone makes me unique.  Once you're unique, (or even anywhere close to), adding more bits has very small impact.  There was much discussion of this...

> As to VPN's: When I access the VPN at the University of Michigan,
> net.ipcalf.com sees my lan address and a U-M address.  It does not see my
> ISP address. So, if my lan address is in the usual recommended ranges, there
> could be MANY devices with that address, and the next time I log in to the
> VPN, that address will change as well.  In my case however, I do not use the
> usual address ranges, I use addresses assigned to an internal Sun
> Microsystems network which Sun, back in the day, suggested people use for
> their internal networks, so my lan address is probably much closer to
> unique.  

Ok... not something normal users do (not something almost any other user does).  LAN addresses can be indirectly probed without webrtc, in fact a site can fingerprint you simply by the set of LAN addresses in use.  (a: assume one of the "standard" LAN subnet ranges and probe to find which one (typically looking at X.X.X.1), b: probe each address in the subnet to see how fast an <img> request times out there.  Result: LAN network map.  Doesn't work for all users, but works for probably 99% of home users, which is total success from a tracker's point of view.  This might even work on you without WebRTC.)  And there are other ways.  I wonder if tor hard-blocks all LAN-like addresses from network requests... hope so

If you're serious about using a VPN to hide your local network - run it in the router and/or disable all non-VPN routes.  That makes this largely irrelevant.  Software VPNs that don't disable non-VPN routes are not anonymity-preserving.  Sorry; I realize most people think they are (and for some uses, they're good enough)

A patch to add blocking all non-relay candidates as an option/about:config is something we'd likely accept.  Note is does *not* stop  determined attackers from finding these, but it makes it harder, and blocks casual or end-user attempts to locate you.

> And, "Complies with the Standard" is a lame excuse for **** software.

Yes - but if so, go to the standards committee.  These aren't being handed down from on-high.  Propose a workable solution that balances user privacy with user utility, and people will listen.  I guarantee forcing/encouraging people to use Skype instead of WebRTC greatly increases the ability of certain people to intercept it (and don't forget Skype and things like it are desktop installs - typically they can do *anything* to your system, adn they're totally closed-source.)

My apologies, but I probably won't reply again here as I'm way too busy already, and I realize discussions like this can go on forever - and bugzilla isn't a forum.
Flags: needinfo?(rjesup)
(In reply to Randell Jesup [:jesup] from comment #64)
> Fixing this the way you suggest would seriously hurt most users of the API. 
> There are plenty of security/privacy advocates/paranoids in the IETF, and
> the spec is the result of such discussions.

This is obviously untrue, otherwiese the spec for WebRTC was not as broken as it is.


> Device fingerprinting is (unfortunately) far more trivial than you realize,

If you really consider this "unfortunate", then do something about it and help us fix it instead of trying to find lame excuses to defend broken standards.

> without this.  Your addons and fontlist alone (unless you run a set of
> virtually-untouched clones) does wonders for fingerprinting.  Panopticlick
> tells me that my plugin list alone makes me unique.  Once you're unique, (or
> even anywhere close to), adding more bits has very small impact.  There was
> much discussion of this...

Correct. However, the only thing this shows is that JavaScript is a broken standard, too - and one broken standard is not a valid excuse for releasing or implementing more broken standards.

There is no legitimate reason whatsoever why JavaScript code loaded from a random Website should be able to enumerate the fonts or the addons installed in the browser. Webfonts have been standardized and broadly supported in all relevant browser for years, as is HTTP caching. There is no reason to allow a website enumerate my locally installed fonts.

As far as addons are concerned: It is neither necessary nor legitimate for a website to be able to fingerprint the extensions installed in my browser. And as for plugins (like Flash or Java), there are ecactly TWO legitimate ways for a website to interact with plugins installed in the browser: By using the <object> tag or the <embed> tag with the correct mime type set. Any other way should be considered a bug and be eradicated from the face of the earth for the good of humanity.

> Ok... not something normal users do (not something almost any other user
> does).  LAN addresses can be indirectly probed without webrtc, in fact a
> site can fingerprint you simply by the set of LAN addresses in use.  (a:
> assume one of the "standard" LAN subnet ranges and probe to find which one
> (typically looking at X.X.X.1), b: probe each address in the subnet to see
> how fast an <img> request times out there.  Result: LAN network map. 
> Doesn't work for all users, but works for probably 99% of home users, which
> is total success from a tracker's point of view.  This might even work on
> you without WebRTC.)  And there are other ways.  I wonder if tor hard-blocks
> all LAN-like addresses from network requests... hope so

Yes, and this bug has been known for years, too. There is no legitimate reason for 99,999% of websites to include content from RFC1918 IP adresses (or from DNS records that resolve to such IP adresses). For the file:// URL scheme, this bug was fixed a long time ago, and there is no reason not to fix it for RFC1918 IP adresses as well.

It may be legitimate for a website from an RFC1918 IP range (or even for an HTML file on your local hard disk) to include content from the internet, but not the other way around.

> If you're serious about using a VPN to hide your local network - run it in
> the router and/or disable all non-VPN routes.  That makes this largely
> irrelevant.  Software VPNs that don't disable non-VPN routes are not
> anonymity-preserving.  Sorry; I realize most people think they are (and for
> some uses, they're good enough)

The problem are not VPNs, the problem are browsers carelessly implementing any bullcrap that calls itself a standard without questioning the impact on the user's privacy. For christ's sake, we are talking about a *browser*. As you are obviously not aware, a browser is a piece of software that is meant to render HTML files, not to reimplement nmap.

> A patch to add blocking all non-relay candidates as an option/about:config
> is something we'd likely accept.  Note is does *not* stop  determined
> attackers from finding these, but it makes it harder, and blocks casual or
> end-user attempts to locate you.

about:config is not a solution, it is a dirty hack for substituting missing UI components until they are properly implemented. And even if there was such an about:config option or even a proper UI element to configure this setting, this still wouldn't fix the problem that you are shipping with insanely broken default settings that no normal user could expect.

> > And, "Complies with the Standard" is a lame excuse for **** software.
> 
> Yes - but if so, go to the standards committee.  These aren't being handed
> down from on-high.  Propose a workable solution that balances user privacy
> with user utility, and people will listen.  I guarantee forcing/encouraging
> people to use Skype instead of WebRTC greatly increases the ability of
> certain people to intercept it (and don't forget Skype and things like it
> are desktop installs - typically they can do *anything* to your system, adn
> they're totally closed-source.)

Firefox is not developed by the IETF or the W3C but by Mozilla. And Skype is, as opposed to Firefox, an ad financed instant messaging client and NOT a browser.
This comment (#65) violates Bugzilla etiquette. See:
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
It may be against the strict etiquette guidelines, but people are trying to convey their frustration at the way Mozilla is responding to concerns about this issue. It included many valid technical points that Mozilla cannot continue to respond to solely by referring to the IETF as the only valid guideline for this, no matter how much Mozilla wants to be seen as "standards-compliant".

I happen to think that although comment #65 may have been borderline according to those guidelines, it is also exactly what I have been thinking.
(In reply to Peter Ansell from comment #67)
> It may be against the strict etiquette guidelines, but people are trying to
> convey their frustration at the way Mozilla is responding to concerns about
> this issue. It included many valid technical points

These points that have already been raised and considered
(and indeed discussed in this bug) above.

To restate:
1. We are not going to put WebRTC behind a permissions dialog
by default. I, at least, would look favorably on a patch which
provided a top-level pref to disable WebRTC, but you'd need
to clear that with desktop.

2. Suppressing RFC 1918 addresses would have an extremely
negative impact on ICE, so we're not going to do that.

3. If you have an approach to filtering out non-VPN addresses
when a VPN is in use that doesn't have a materially negative
impact on ICE, please submit a patch and we'll consider it on
its merits.


Unless there is some new point to raise, please take discussion
to dev-media: https://lists.mozilla.org/listinfo/dev-media
(In reply to Eric Rescorla (:ekr) from comment #68)

> To restate:
> 1. We are not going to put WebRTC behind a permissions dialog
> by default. I, at least, would look favorably on a patch which
> provided a top-level pref to disable WebRTC, but you'd need
> to clear that with desktop.

Why not have a pref (webrtc.prompt_me_for_everything - false by default) that would control prompting for people that want it?
(In reply to Fabrice Desré [:fabrice] from comment #69)
> (In reply to Eric Rescorla (:ekr) from comment #68)
> 
> > To restate:
> > 1. We are not going to put WebRTC behind a permissions dialog
> > by default. I, at least, would look favorably on a patch which
> > provided a top-level pref to disable WebRTC, but you'd need
> > to clear that with desktop.
> 
> Why not have a pref (webrtc.prompt_me_for_everything - false by default)
> that would control prompting for people that want it?

This would be satisfactory to me as well, but ultimately I figure
desktop is going to have a bunch of opinions about the prompts.
From the looks of it, Chrome has already given this option in Chrome 42: 

Justin Uberti: (2/26/2015, 12:44:47 PM) -  http://blog.golgi.io/excuse-me-sir-your-webrtc-is-leaking

("Quote")
A less-drastic way to address this issue is to set the following preference (added in Chrome 42). 

webrtc": { 
"multiple_routes_enabled": false 
}, 

For the location of the prefs file, see http://www.chromium.org/administrators/configuring-other-preferences/ 

This forces all WebRTC connections to only use server-reflexive and relay ICE candidates, and only on the default IP route. While this may cause a QoS hit (two users behind NAT can no longer keep their traffic internal to the NAT), it does allow the issue mentioned here to be fully addressed without disabling WebRTC altogether.
("End Quote")
(In reply to brock from comment #63)
> Your add-on does not install on Firefox Android.  Can you make it available
> there as well?

The latest Firefox for android installed the add-on okay for me (Verizon Wireless PANTECH ADR8995). I recommend using the Play Store as mobile browsers would not download Firefox to my device. WebRTC will be blocked but my tablet wasn't displaying accept/deny notifications.
I agree that Chrome added is what we need the most for now: adding an option to switch off non-relay candidates for people who really care about this leakage.
(In reply to Xidorn Quan [:xidorn] (UTC+11) from comment #73)
> I agree that Chrome added is what we need the most for now: adding an option
> to switch off non-relay candidates for people who really care about this
> leakage.

I second, this MUST be an option in Firefox to solve the internal ip address leak problem. Note however, the leak of the VPN Interface will still be another problem. 

I recommend we separate both into two bugs: 
1#Bug 959893 - WebRTC Internal IP Address Leakage (current bug)
2#Bug 95xxxx - WebRTC External IP Address Leakage - VPN Tunnel Split (create new bug)

For anyone interested the Google bug filed for reference - https://code.google.com/p/chromium/issues/detail?id=333752
Switching off non-relay candidates should solve both internal ip address leak and VPN interface leak, because it makes the browser only get candidates via the remote relay server, which will only provide the address the remote site can always get.
Attached patch patch — — Splinter Review
This patch adds a pref to block all non-relay candidates.

I'm not sure whether we should add this to Options, but this pref should be useful enough.
Attachment #8572994 - Flags: review?(rjesup)
Comment on attachment 8572994 [details] [diff] [review]
patch

Review of attachment 8572994 [details] [diff] [review]:
-----------------------------------------------------------------

::: modules/libpref/init/all.js
@@ +383,5 @@
>  // Do not enable identity before fixing domain comparison: see Bug 958741
>  // Do not enable identity before fixing origin spoofing: see Bug 968335
>  pref("media.peerconnection.identity.enabled", false);
>  pref("media.peerconnection.identity.timeout", 10000);
>  pref("media.peerconnection.ice.loopback", false); // Set only for testing in offline environments.

BTW, there are two identical pref here. I guess it was because of some auto conflict resolving.
Comment on attachment 8572994 [details] [diff] [review]
patch

Review of attachment 8572994 [details] [diff] [review]:
-----------------------------------------------------------------

I don't believe that this patch does what you claim it does. For instance,
checking for candidate->stun_servers allows both srflx and relay candidates,
not just relay candidates. You should use candidate->type.

More generally, this doesn't seem like the right approach to me. If your
model is that unsuspecting users will be subject to privacy threats, then this
patch doesn't help because people won't know to set the pref. And people who
are suspecting enough to set the pref can just turn off WebRTC. I'd like to
see a lot more security analysis before we offer a feature which nominally
allows WebRTC usage without leaking private IP addresses to make sure that
it really does that.
Attachment #8572994 - Flags: review?(rjesup)
There is a decisive difference between turning off WebRTC and blocking non-relayed candidates: the latter enables user to use WebRTC without the fear of leaking the IP addresses the server shouldn't have known.

I don't have the statistics data, but I suspect that non-relayed candidates are not used in most of normal cases, because in those cases, the communication happens through the Internet, which always requests a public address. It means that, blocking non-relayed candidates will still allow users to use WebRTC normally in most cases, but remove the potential leakage.
In addition, jesup has agreed in comment 64 that, it is acceptable to have such switch.
Comment on attachment 8572994 [details] [diff] [review]
patch

Review of attachment 8572994 [details] [diff] [review]:
-----------------------------------------------------------------

See comment below - I think this patch is simply wrong.

The name chosen is misleading - probably something like ....relay_candidates_only.

Note: this patch would primarily provide privacy from certain attempts to locate a user by starting a call with them and wiresharking the data or examining about:webrtc.  I.e. the "person in safe house hiding from abuser" usecase discussed in the WG.  It doesn't fully provide privacy against a service or a user with enough knowledge to set up a private TURN server.  To do one step better (not all the way there), you need to also implement forced-local-TURN-servers (which is something businesses and other organizations want).  VPN anonymity might require something more; I haven't thought through all the cases if the VPN interface is allowed to be used with the options described above.

::: media/mtransport/nricectx.cpp
@@ +364,5 @@
>                            nr_ice_candidate *candidate) {
>    // Get the ICE ctx
>    NrIceCtx *ctx = static_cast<NrIceCtx *>(arg);
> +  if (ctx->stun_candidate_only_ && !candidate->stun_server)
> +    return;

I think this is simply wrong, but I'm not entirely up on the nicer/etc internals.  I'll note the idea is to suppress non-relay candidates, and SERVER_REFLEXIVE candidates from STUN or TURN servers have non-null candidate->stun_server entries (see ice_component.c).
(In reply to Xidorn Quan [:xidorn] (UTC+11) from comment #79)
> There is a decisive difference between turning off WebRTC and blocking
> non-relayed candidates: the latter enables user to use WebRTC without the
> fear of leaking the IP addresses the server shouldn't have known.

It's not clear that that's in fact correct. As I said, please provide an
actual security analysis here (which is far more than you have done below.)



> I don't have the statistics data, but I suspect that non-relayed candidates
> are not used in most of normal cases, because in those cases, the
> communication happens through the Internet, which always requests a public
> address.

You seem to be a little unclear on the types of candidates in play here;
most ICE connections in fact *do* use non-relayed candidates: they connect
with the server reflexive candidates.



> It means that, blocking non-relayed candidates will still allow
> users to use WebRTC normally in most cases, but remove the potential leakage.

Blocking non-relayed candidates will have a very negative impact on
WebRTC performance. And I note that this is not what the Chrome patch
pointed to in c71 does.


>In addition, jesup has agreed in comment 64 that, it is acceptable to have such switch.

No, he said that "we'd likely accept" such a patch. However, he wasn't speaking for
everyone working on this code, and I don't agree that this is a good idea.
(In reply to Randell Jesup [:jesup] from comment #81)
> Comment on attachment 8572994 [details] [diff] [review]
> patch
> 
> Review of attachment 8572994 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> See comment below - I think this patch is simply wrong.
> 
> The name chosen is misleading - probably something like
> ....relay_candidates_only.
> 
> Note: this patch would primarily provide privacy from certain attempts to
> locate a user by starting a call with them and wiresharking the data or
> examining about:webrtc.  I.e. the "person in safe house hiding from abuser"
> usecase discussed in the WG.  It doesn't fully provide privacy against a
> service or a user with enough knowledge to set up a private TURN server.  To
> do one step better (not all the way there), you need to also implement
> forced-local-TURN-servers (which is something businesses and other
> organizations want).  VPN anonymity might require something more; I haven't
> thought through all the cases if the VPN interface is allowed to be used
> with the options described above.
> 
> ::: media/mtransport/nricectx.cpp
> @@ +364,5 @@
> >                            nr_ice_candidate *candidate) {
> >    // Get the ICE ctx
> >    NrIceCtx *ctx = static_cast<NrIceCtx *>(arg);
> > +  if (ctx->stun_candidate_only_ && !candidate->stun_server)
> > +    return;
> 
> I think this is simply wrong, but I'm not entirely up on the nicer/etc
> internals.  I'll note the idea is to suppress non-relay candidates, and
> SERVER_REFLEXIVE candidates from STUN or TURN servers have non-null
> candidate->stun_server entries (see ice_component.c).

As you say, this patch is wrong.
(In reply to Eric Rescorla (:ekr) from comment #82)
> (In reply to Xidorn Quan [:xidorn] (UTC+11) from comment #79)
> > I don't have the statistics data, but I suspect that non-relayed candidates
> > are not used in most of normal cases, because in those cases, the
> > communication happens through the Internet, which always requests a public
> > address.
> 
> You seem to be a little unclear on the types of candidates in play here;
> most ICE connections in fact *do* use non-relayed candidates: they connect
> with the server reflexive candidates.

Right.

Xidorn: Something like 80-90% of calls use LAN (HOST) or server-reflexive addresses (and preferably even higher).  The reason is that TURN is a) expensive (the service has to pay for a high-bandwidth relay, preferably geographically distributed), and b) it lowers the quality of the call (typically the two-leg network has more delay)
 
> > It means that, blocking non-relayed candidates will still allow
> > users to use WebRTC normally in most cases, but remove the potential leakage.
> 
> Blocking non-relayed candidates will have a very negative impact on
> WebRTC performance. And I note that this is not what the Chrome patch
> pointed to in c71 does.

Right.  There are certain use-cases where blocking non-relayed candidates may be useful (see above), basically the hide-from-abuser case and the enterprise-with-TURN-server-at-border (especially if they generally block UDP).  Note that a VPN service *could* also provide a TURN server at the VPN exit-point.

> 
> 
> >In addition, jesup has agreed in comment 64 that, it is acceptable to have such switch.
> 
> No, he said that "we'd likely accept" such a patch. However, he wasn't
> speaking for
> everyone working on this code, and I don't agree that this is a good idea.

ekr is right I didn't agree in general, just that the partial solution that addresses the cases I mention above may be accepted.
Saying: 

"I think this patch is simply wrong"  Comment# 81

VS. 
"A patch to add blocking all non-relay candidates as an option/about:config is something we'd likely accept." 

This is completely contradictory to what you just said.  I mean what the freak man??? lol 

Eric You and Randell must be stuck in Analysis Paralysis and as i recall you have given up on this ticket fifteen comments ago, your interest has been lost, and for some reason intent to show-stop this entire bug from ever evolving into any type of solution.

My guess it has something to do with Mozilla's ulterior motive to promote the continued rolling of "Firefox Hello"" to the production released build of Firefox. 

Xidorn is the person that has contributed the most towards solving this and is at least doing something as opposing to just talking about it, and giving up, he should be commended for this and not nit-picked or criticized for it.  

For vetting this from a security perspective,  I did link to Google's bug where Justin Uberti is active and in their discussion of how Google is handling.  Please read it there may still be idea's that haven't been mentioned here: https://code.google.com/p/chromium/issues/detail?id=333752 

If WebRTC is still in experimental mode why is it being rolled into a production service "Hello Firefox" if users privacy is at risk?

I'm not quite sure what a Man in the Middle attack as anything to do with any of this, as that is a completely different topic, anyone can be Mitm'd, but if you using the correct SSL security setting WebRTC is secure.  So maybe you can elaborate on where you are coming from on that? 

WebRTC is not "Mozilla's" problem and is not "Google's" problem its every browsers responsibility to work together for the Standard, ever 10 years we go through another browser war.  We need to re-sync with Google and other browser teams to mitigate these issues together.
(In reply to Randell Jesup [:jesup] from comment #81)
> Note: this patch would primarily provide privacy from certain attempts to
> locate a user by starting a call with them and wiresharking the data or
> examining about:webrtc.  I.e. the "person in safe house hiding from abuser"
> usecase discussed in the WG.  It doesn't fully provide privacy against a
> service or a user with enough knowledge to set up a private TURN server.  To
> do one step better (not all the way there), you need to also implement
> forced-local-TURN-servers (which is something businesses and other
> organizations want).  VPN anonymity might require something more; I haven't
> thought through all the cases if the VPN interface is allowed to be used
> with the options described above.

Your scenario "When communicating with another client/user through WebRTC, that client/user may get to know your public IP address" is yet another threat model (which I'd also consider worth adressing).

The threat model I was talking about is "The webserver can enumerate the IP adresses of all network interfaces on the client without asking the client user". This may be more of a problem if you are using, say TOR, and either the webserver owner could find out your "real" IP address through some javascript code using WebRTC on his website, or somebody like the NSA/GCHQ might automatically inject such JS code on unencrypted HTTP connections on a broader scale. If this was done in a clever way (for example "only sporadically inject into JS files loaded from popular tracking networks", nobody would even notice. It is often undesirable to use TOR as the *only* route for your traffic, because you may for instance want to access your local corporate intranet directly instead of routing that traffic through TOR, and that intranet may actually run on public IP adresses.
Hi,

I described a possible exploit in previous posts, but they were marked as "spam" or "advocacy". My only guess as to why is the fact that you can't edit posts on Bugzilla and I made a typo in describing the exploit.

Does anyone want me to explain the exploit in a better way?

Thank you, Dan
Randell, Xidorn: Do we have plan to work on this? It is not really clear to me what we are planning to do. Thanks
It seems the easiest and least WebRTC-breaking fix would be to simply require user consent for createOffer() and createAnswer(). If the user already gave consent for getUserMedia(), that would count as user consent for createOffer() and createAnswer().

This basically means you wouldn't be able silently create a Data Channel (and thus leak IP Addresses) without user consent. We already require user consent on Audio and Video, why not data, too?
sylvestre, I don't have time currently. And it doesn't seem that Eric and Randell want to see any change on this. I think my existing patch should be fine given that fixes the leakage of non-public IP address with a pref (so with that pref, I think the website can only know what it could have known already). However, they required me to provide a security analysis to prove it works, which I have no idea how to do.
(In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #91)
> sylvestre, I don't have time currently. And it doesn't seem that Eric and
> Randell want to see any change on this. I think my existing patch should be
> fine given that fixes the leakage of non-public IP address with a pref (so
> with that pref,

Your patch is broken, for the reason that Jesup indicated in c81.
SERVER_REFLEXIVE candidates are the addresses that the server have already known, I don't think we have any reason to exclude them. So I think my patch is only broken in the description where I shouldn't say it suppresses non-relay candidates. I should say it suppresses any candidates that the server wouldn't have known if we do not expose it by this channel.
(In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #93)
> SERVER_REFLEXIVE candidates are the addresses that the server have already
> known, I don't think we have any reason to exclude them. So I think my patch
> is only broken in the description where I shouldn't say it suppresses
> non-relay candidates. I should say it suppresses any candidates that the
> server wouldn't have known if we do not expose it by this channel.

Please see the very extensive discussion of VPN and proxies both here and on the rtcweb list for why the problem is significantly more complicated than this.

Even looking at just the problem of suppressing local addresses in the candidate list, suppressing the local candidates isn't enough because srflx and relay candidates contain the local address that corresponds to the remote address. See the raddr production at: https://tools.ietf.org/html/rfc5245#section-15.1

To see that your patch doesn't suppress these, go to:
http://mozilla.github.io/webrtc-landing/stun_test.html

Finally, as I said you should use the type field, not the stun_servers field.
(In reply to Eric Rescorla (:ekr) from comment #94)
> (In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #93)
> > SERVER_REFLEXIVE candidates are the addresses that the server have already
> > known, I don't think we have any reason to exclude them. So I think my patch
> > is only broken in the description where I shouldn't say it suppresses
> > non-relay candidates. I should say it suppresses any candidates that the
> > server wouldn't have known if we do not expose it by this channel.
> 
> Please see the very extensive discussion of VPN and proxies both here and on
> the rtcweb list for why the problem is significantly more complicated than
> this.
> 
> Even looking at just the problem of suppressing local addresses in the
> candidate list, suppressing the local candidates isn't enough because srflx
> and relay candidates contain the local address that corresponds to the
> remote address. See the raddr production at:
> https://tools.ietf.org/html/rfc5245#section-15.1
> 
> To see that your patch doesn't suppress these, go to:
> http://mozilla.github.io/webrtc-landing/stun_test.html
> 
> Finally, as I said you should use the type field, not the stun_servers field.

To be clear, this is not an invitation to just fix the defects I called out. If you want to do something here, go catch up with the discussion on the mailing list and Chrome and propose something that addresses the  concerns people raised.
I think that I want to go further: a pref is not a solution.  If the users who are affected by this are required to tool around in about:config, then we're not doing them much good.

I have no objection to landing code that does the relay-only restriction, and as a consequence having a pref to provide this secondary benefit.  But it should not be buried.  There's a public API to this that we might consider implementing so that more than a tiny handful of users can see some benefit: http://w3c.github.io/webrtc-pc/#idl-def-RTCIceTransportPolicy
(In reply to Eric Rescorla (:ekr) from comment #94)
> Please see the very extensive discussion of VPN and proxies both here and on
> the rtcweb list for why the problem is significantly more complicated than
> this.

I have been on the WebRTC mailing list for close to three months now and have-not seen any mention of this ticket or issue. Eric do you have a link to the resource or should we Google something?  I'd also appreciate not being marked as spam, thank you!
(In reply to Jared Null from comment #97)
> (In reply to Eric Rescorla (:ekr) from comment #94)
> > Please see the very extensive discussion of VPN and proxies both here and on
> > the rtcweb list for why the problem is significantly more complicated than
> > this.
> 
> I have been on the WebRTC mailing list for close to three months now and
> have-not seen any mention of this ticket or issue. Eric do you have a link
> to the resource or should we Google something? 

http://www.ietf.org/mail-archive/web/rtcweb/current/msg14494.html


> I'd also appreciate not
> being marked as spam, thank you!

I didn't mark you as spam initially, so your argument there is with someone else.
(In reply to Eric Rescorla (:ekr) from comment #98)
> > I'd also appreciate not
> > being marked as spam, thank you!
> 
> I didn't mark you as spam initially, so your argument there is with someone
> else.

i removed the spam tag
(In reply to Sylvestre Ledru [:sylvestre] from comment #99)
> (In reply to Eric Rescorla (:ekr) from comment #98)
> > > I'd also appreciate not
> > > being marked as spam, thank you!
> > 
> > I didn't mark you as spam initially, so your argument there is with someone
> > else.
> 
> i removed the spam tag

Why was my description of a possible vulnerability marked as "advocacy" and how was I advocating anything?
1. Public IP addresses are also sensitive, if a proxy is configured. I route all my traffic through a proxy, for anonymization. This completely unveils me.

2. From what I understand, this (DetectRTC) may currently be used as a vector to find the router in an exploit kit for to attack routers from inside network, where they are more exposed. It attacks more than 50 router models: Netgear, Belkin, Dlink, TPlink, Asus, Zyxel. Reportedly, the router attack works from a browser by just visiting a website.
http://malware.dontneedcoffee.com/2015/05/an-exploit-kit-dedicated-to-csrf.html
(Attention TLDRers: the pastebin code at the top is an early version of the exploit, not the current code)
https://github.com/muaz-khan/DetectRTC/blob/master/DetectRTC.js

This one should be easy enough to fix with a prompt. Leaving such bugs dangling leads to in situations where routers are attacked from inside, from a normal webpage, on a big scale.

Dear WebRTC team, it's your responsibility.
Component: WebRTC → WebRTC: Signaling
Reading that, it's using DetectRTC only as a fingerprint generator to encrypt/decrypt attack code; one other part of the code shows them using a table of common LAN router IPs to use to identify the router.  The site you link to shows nothing that says to me the IP detection is being used in any way to attack the routers.
(In reply to Randell Jesup [:jesup] from comment #103)
> Reading that, it's using DetectRTC only as a fingerprint generator to
> encrypt/decrypt attack code; one other part of the code shows them using a
> table of common LAN router IPs to use to identify the router.  The site you
> link to shows nothing that says to me the IP detection is being used in any
> way to attack the routers.

Its hard to speculate on incomplete code/exploits anyways, we don't know all of its working (not that we need to). It would be nice to stick to the facts as oppose to basing off of only opinion.  

Not using WebRTC in this attack is like putting candy in front of a kid and then telling him not to eat it.

by the way, my add-on does request user interaction before enabling webrtc: https://addons.mozilla.org/en-US/firefox/addon/statutory/    -If anyone could help i would really like to convert/piggyback the toaster popup to one of the other permanent popups like getUserMedia or cam/mic access. I haven't a clue to proceed, i just know a hint of it is in the awesome bar xul area of browser.xul
Apparently being used in the wild:

https://twitter.com/incloud/status/619624021123010560

("WebRTC being used now by embedded 3rd party on http://nytimes.com  to report visitors' local IP addresses.")
(In reply to Justin Dolske [:Dolske] from comment #105)
> Apparently being used in the wild:
> 
> https://twitter.com/incloud/status/619624021123010560
> 
> ("WebRTC being used now by embedded 3rd party on http://nytimes.com  to
> report visitors' local IP addresses.")

I've said this before and I'll say it again. Data channels should require user consent just the same as video and audio (getUserMedia). I haven't yet heard a good reason on why a silent P2P data channel connection is required.
The tweet content is true from what I could reconstruct. This script (http://s.tagsrvcs.com/2/4.10.0/loaded.js) is the reason for it, you can easily identify the WebRTC connection. I think Firefox should do something about it top priority as it’s an exposed open bug that reveals user identity to third parties.
I think a user consent would indeed help a lot.
I'm going to leave this link here so I can find it later when I need it.

https://github.com/w3ctag/spec-reviews/blob/master/2015/05/fingerprint.md

I'll quote the opening sentence: "The [W3C Technical Advisory Group] believes there is a reasonably strong consensus in the industry that, against a determined attacker, combating fingerprinting *is* a lost cause."

The rest of the write-up is a bit more nuanced than that, but it doesn't stray from that thesis.

Relevant to this issue, I think this change in advice is probably worth pondering: "When increasing fingerprinting surface is unavoidable, prefer designs that make it detectable."
There is a big difference between "fingerprinting" (identifying/tracking a unique instance) and an IP address which is considered "personally identifiable information" in some countries. Nor are ad networks determined attackers like a gov't agency, they are opportunistic data hoarders.
Totally agree with you, there is a big difference between personal metadata (like: I like the color black, play golf, and where zebra stripped pants on Sunday's) and personal identifiers such as: IP, phone#, DL#, SSN, CC etc..  Your personal metadata is stored with no value until it can be concatenated with more personal metadata and/or key identifiers. 

What I want to know is: -What is the purpose of the Do Not Track Button?? - http://postimg.org/image/ig5cratoz/  - It’s a joke right? 

https://www.mozilla.org/en-US/firefox/dnt/  (Mozilla Quote):

```
Mozilla is a global, nonprofit organization dedicated to making the Web better. We emphasize principle over profit, and believe that the Web is a shared public resource to be cared for, not a commodity to be sold. We answer to no one but you and believe it is crucial to put you in control of your online experience. We are aiming to give you better insight and control into the ways your personal information is collected, used, stored and shared online.

Mozilla Firefox offers a Do Not Track feature that lets you express a preference not to be tracked by websites. When the feature is enabled, Firefox will tell advertising networks and other websites and applications that you want to opt-out of tracking for purposes like behavioral advertising.
```
(In reply to Daniel Veditz [:dveditz] from comment #109)
> There is a big difference between "fingerprinting" (identifying/tracking a
> unique instance) and an IP address which is considered "personally
> identifiable information" in some countries. Nor are ad networks determined
> attackers like a gov't agency, they are opportunistic data hoarders.

This is why it's important to distinguish between VPN addresses and
local IP addresses, since the latter are generally less identifying than
the public IP address. It would indeed be nice to do something about the
VPN addresses.
"...the New York times uses WebRTC to gather your local ip addresses..." [0]

[0] https://webrtchacks.com/dear-ny-times/
(In reply to Jared Null from comment #110)
> principle over profit

I can't help but think Mozilla is covering up a shark on the Fourth of July.
(In reply to Nick Desaulniers [:\n] from comment #112)
> "...the New York times uses WebRTC to gather your local ip addresses..." [0]
> 
> [0] https://webrtchacks.com/dear-ny-times/

There's discussion on that here:

https://www.reddit.com/r/netsec/comments/3dgwee/how_the_new_york_times_uses_webrtc_to_gather/
https://news.ycombinator.com/item?id=9893561

There's a response from one of the WebRTC developers involved with Chrome: https://news.ycombinator.com/item?id=9895796
Hi.

ecr: I see that FF is not willing to violate the IETF spec, which is a very good thing. But surely FF can allow extensions to be made which let this thing roll, like Chrome did with the commit linked above (https://chromium.googlesource.com/chromium/src/+/7c98bab02128ae9fdc4fcc9a9df38588af86290e%5E%21/chrome/common/pref_names.cc).

Thanks,
<3
We are considering adding an extension to restrict the use of WebRTC but are still studying what would be most effective.
(In reply to Daniel Roesler from comment #106)
> I've said this before and I'll say it again. Data channels should require
> user consent just the same as video and audio (getUserMedia). I haven't yet
> heard a good reason on why a silent P2P data channel connection is required.

I would like to second this observation.  I have not attempted to dig into the details of the spec, but it *sounds* like the entire problem goes away if creating any sort of channel requires explicit user authorization.
I don't see why Firefox would be initiating these hidden background connections when I am not trying to use the Video-chat.

Surely the solution is to disallow WebRTC except in relation to user initiated web-chats.
Here's a way to add user consent that is backwards compatible and doesn't break existing webapps:

1. Add a requirement to ask for user consent on RTCPeerConnection.createOffer() and RTCPeerConnection.createAnswer().

2. If there is currently a video or audio stream added to the RTCPeerConnection, check the stream for a assume that the consent requirement has been satisfied.

RTCPeerConnection.createOffer/Answer() is where the ICE candidate collection gets kicked off, so this would effectively implement an asynchronous user consent for data channels. Are there other RTCPeerConnection methods that also kick off ICE candidate collection?
(In reply to Daniel Roesler from comment #119)
> Here's a way to add user consent that is backwards compatible and doesn't
> break existing webapps:
> 
> 1. Add a requirement to ask for user consent on
> RTCPeerConnection.createOffer() and RTCPeerConnection.createAnswer().
> 
> 2. If there is currently a video or audio stream added to the
> RTCPeerConnection, check the stream for a assume that the consent
> requirement has been satisfied.
> 
> RTCPeerConnection.createOffer/Answer() is where the ICE candidate collection
> gets kicked off, so this would effectively implement an asynchronous user
> consent for data channels. Are there other RTCPeerConnection methods that
> also kick off ICE candidate collection?

This is exactly what had been asked to Mozilla since spring of 2014 repeatedly - i guess it is time to do the math of mozilla refusing to do this step with such a furor. And to consider that FF isn't focussing on user privacy for some time now and to ask who benefits most from leaking IP and LAN information through VPN.
Item 4 of The Mozilla Manifesto states:
"Individuals' security and privacy on the Internet are fundamental and must not be treated as optional." - https://www.mozilla.org/en-US/about/manifesto/

This bug report clearly demonstrates that Firefox's WebRTC implementation, by default, treats the privacy implications of leaking internal network and gateway IP addresses to other parties as an optional consideration.

I agree with Zack Weinberg and ABri from comment #117 & #120, what's it going to take/require to get this issue the internal resources at Mozilla it needs?
> I don't see why Firefox would be initiating these hidden background connections when I am not trying to use the Video-chat.

> Surely the solution is to disallow WebRTC except in relation to user initiated web-chats.

The data channel can be used for things besides chat (whether text, audio or video) e.g. real-time P2P games.
(In reply to Morel Xavier from comment #122)
> > I don't see why Firefox would be initiating these hidden background connections when I am not trying to use the Video-chat.
> 
> > Surely the solution is to disallow WebRTC except in relation to user initiated web-chats.
> 
> The data channel can be used for things besides chat (whether text, audio or
> video) e.g. real-time P2P games.

Indeed.
There are many use cases for webRTC through the data channel : multiplayer games, file transferts, p2p content delivery, control of IoT devices and so on.
> There are many use cases for webRTC through the data channel 

That does not preclude prompting the user for granting the necessary permissions.

While many might tick "yes" even if the browser asked them if it's ok to burn down their house, those who care about privacy at least should have the option to say "no".

Smartphone or chrome's app store enumerate the permissions that an app/extension requests. Users can handle that. The same can and should apply for websites that "need" advanced features to work.
to The 8472 from comment #124)
> > There are many use cases for webRTC through the data channel 
> 
> That does not preclude prompting the user for granting the necessary
> permissions.

Of course not, this was a response to a comment stating that there was no cause for data connections outside of "chat". The comment you quote doesn't state that data WebRTC must be invisible/unprompted, only that there are plenty of non-chat data WebRTC use cases.
uBlobk Origin purports to block WebRTC IP leaking:
http://www.ghacks.net/2015/07/02/you-can-block-webrtc-from-leaking-your-ip-now-in-ublock-origin/

I tested it and it appears to work.
Keywords: meta
I have concerns with limiting what ICE candidates are provided.  As we (HumbleBundle) are trying to build out a multiplayer system on top of WebRTC Data Channel. And limiting ice candidates to not include LAN addresses will punish players are actually ARE behind the same firewall on the same LAN.  And WebRTC provides these addresses by design for that purpose.

We need to find a way to prevent the advertising from abusing a (yet another) piece of useful technology without destroying it's functionality.
Nice to know Mozilla is running on at least three cylinders of communication, just received this email through the mozilla-dev-media@lists.mozilla.org channel: 

Mozilla will soon be landing a series of capabilities to allow users to
control many aspects of how ICE candidates are gathered and used.

These include, but aren't limited to, methods to restrict the use of
interfaces to either the default route or a whitelisted interface; ability
to force use of relay candidates only; to override application
specification of ICE servers with a user-specified value (i.e. force use of
a border TURN server); and methods to allow extensions to validate if a
user has intended to allow use of a PeerConnection.  We also are looking
into methods to expose 'background' PeerConnections short of blocking all
of them or requiring explicit opt-in ahead of time, and how to record what
uses PeerConnections, and for what.

The meta/tracking bug is *Bug 1189167*
<https://bugzilla.mozilla.org/show_bug.cgi?id=1189167>.

We expect many of these new tools to be available soon in Firefox Beta 41
(shortly after 40 goes to release in a few weeks).

Most of these capabilities will be available initially as interfaces that
extensions can enable or users can flip on via about:config.

--
Maire Reavy
Blocks: 1189167
(In reply to Edward Rudd from comment #127)
> I have concerns with limiting what ICE candidates are provided.  As we
> (HumbleBundle) are trying to build out a multiplayer system on top of WebRTC
> Data Channel. And limiting ice candidates to not include LAN addresses will
> punish players are actually ARE behind the same firewall on the same LAN. 
> And WebRTC provides these addresses by design for that purpose.
> 
> We need to find a way to prevent the advertising from abusing a (yet
> another) piece of useful technology without destroying it's functionality.

Would explicit user authorization to create data channels (as suggested several times above) be acceptable for your use case?
No longer blocks: 1189167
Depends on: 1189167
(In reply to Zack Weinberg (:zwol) from comment #129)
> (In reply to Edward Rudd from comment #127)
> > I have concerns with limiting what ICE candidates are provided.  As we
> > (HumbleBundle) are trying to build out a multiplayer system on top of WebRTC
> > Data Channel. And limiting ice candidates to not include LAN addresses will
> > punish players are actually ARE behind the same firewall on the same LAN. 
> > And WebRTC provides these addresses by design for that purpose.
> > 
> > We need to find a way to prevent the advertising from abusing a (yet
> > another) piece of useful technology without destroying it's functionality.
> 
> Would explicit user authorization to create data channels (as suggested
> several times above) be acceptable for your use case?

It largely depends on how it's built.  both in how it's exposed to the user (so they can easily accept/reject) as well as to the developer (so they know how to handle the scenario when the user hasn't responded YET, vs rejecting them outright)

Would we simply hold the response to the initiation callback until the user definitely accepts or rejects the Data request?  And would the user be able to say "always allow on this domain"?

Another question is how is this going to be handle with respect to iframes? As we are providing an 'iframe' widget that a game developer can embed in their own website to allow them to sell their game as well as allow users play the asm.js port (which may include networking). (see Bug #1147821).
Hey ekr, could you please give this bug some love?

Threat:

1. This is being used actively my third parties on nytimes.com to find local IP addresses of visitors (comment 105) 
2. Probably also used as an attack vector to discover router IPs, which are then easy victims for (other, indepedent) router exploits (comment 102)
3. This reveals local IPs and identifies surfers. The local network topology has always been considered secret, esp. if browsers are behind a proxy. I use a proxy *specifically* to anonymize, and this effort is being dwarfed by this bug (my local IP is unusual). The same would be true for anonymizing VPN users. (So, you unfortunately can't rely on proxy config as indication.)

Given that this is actively and widely used to unmask users who specifically try to stay anonymous, I think it's urgent to fix this.

Possible fixes:
* Data channels MUST require user consent, just like cam/mic. (comment 106 and others)
* Even with consent to communication, local IP addresses MUST NOT be sent in the request unless explicitly approved.
Assignee: nobody → ekr
Maire has already announced our plan of record:
https://groups.google.com/forum/#!topic/mozilla.dev.media/L6Rx9ubSjMc

And I'm presently working on the technical underpinnings to restrict
use of non-default addresses:
https://bugzilla.mozilla.org/show_bug.cgi?id=1189041

As Maire indicated, that setting will be opt-in for now (as in Chrome).
Assignee: ekr → nobody
> that setting will be opt-in for now

As I said, that's not good enough.
a) you can't expect users to know about this. Protection needs to be the default.
b) an opt-in will do nothing to stop security attacks.
It may be more appropriate to refer to it as "opt-out", based on similar terminology for other privacy related issues, as the user making a configuration change will reduce the amount of personal information being leaked. Hence, the user would be "opting-out" of the default which exposes personal information.

Using either terminology though, it isn't good enough that the user needs to know about this option and manually make a change to stop NYTimes knowing what their internal network addresses are, for whatever reason they decided to start using it.
This is a *very* serious privacy issue (basically it is almost like having a JS API like "getLocalIPAddress()"...), especially because it mainly concerns people who might care about privacy (individuals using VPNs or proxy servers to conceal their location and/or identity, companies having the structure of their internal networks exposed...). I can't believe that such a serious issue is still affecting Firefox 18 months after it was discovered! Especially when thinking about what the Mozilla Manifesto says (see comment #121).

I think that ANY function that might expose private information (such as an internal IP address) MUST be authorized by the user BY DEFAULT. Users have to be informed about what is happening. I never worked on Firefox source code, but I can't believe it takes 18 months to find a way to implement a user authorization system for that without breaking existing applications.

Is there any clear roadmap about solving this bug?
I totally agree with you Ale, very long time for something like this to get attention, i haven't seen any cables come through the tickets besides just technical whys and why nots, so hard to know what Mozilla's agenda is or how far they go here, but progress is being made, so its worth just sitting back and waiting IMHO. 

between comment 126 & 127 
parent bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1189167

children bugs 
https://bugzilla.mozilla.org/show_bug.cgi?id=1189036
https://bugzilla.mozilla.org/show_bug.cgi?id=1189040
https://bugzilla.mozilla.org/show_bug.cgi?id=1189055
https://bugzilla.mozilla.org/show_bug.cgi?id=1189030
https://bugzilla.mozilla.org/show_bug.cgi?id=1189044
https://bugzilla.mozilla.org/show_bug.cgi?id=1189044
https://bugzilla.mozilla.org/show_bug.cgi?id=1189060
https://bugzilla.mozilla.org/show_bug.cgi?id=1189097
https://bugzilla.mozilla.org/show_bug.cgi?id=959893
Ali Express abuses this on their login page (together with some other shady techniques).
Can we turn this on by default to fix this for all users, now that ICE is implemented?

 media.peerconnection.ice.default_address_only = true

From what I understand, on Windows/Linux this tells firefox to only advertise via the default routes to the stun server.

My understanding is that with this, private ips no longer leak, and private-to-private ip connections within the same subnet are limited to things like WAN Redirect or public relays -- which seems to make sense because it decides what to trust based on the host and network setup.

On top of the, default_address_only seems to play nice with VPNs - and doesn't disclose addresses of things like VPNs.

Is there any reason this is undesirable for a default?
Firefox will almost certainly address this problem using the approach described in https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01 (or the final form of that document, once it is approved to be published as an RFC).

(In reply to Dave Andrews from comment #139)
> Can we turn this on by default to fix this for all users, now that ICE is
> implemented?
> 
>  media.peerconnection.ice.default_address_only = true

That does not work in e10s. Also, it ruins the ability to have low-latency, high bandwidth communications that would be otherwise possible under many network configurations.
(In reply to Adam Roach [:abr] from comment #141)
> That does not work in e10s.

FYI as bug 1194259 has been fixed it actually should work with e10s - looks like the wiki page should be updated.

But another dis-advantage of this solution is that is not mentioned on the wiki page is that it breaks all calling services which provide intra-LAN calls only (as this option suppresses local candidates).
Thanks Adam.  Reading the draft, it sounds like this option corresponds with "Mode 3".

 media.peerconnection.ice.default_address_only = true

Draft says "
   We recommend Mode 1 as the default behavior only if cam/mic
   permission has been granted, or Mode 2 if this is not the case.
"

Both modes 1 and 2 leak the private IP according to their descriptions

The document goes on to say this:

"If the client is behind a NAT, the client's private IP addresses, typically [RFC1918] addresses, can be learned."

and then blatantly disregards the issue presented in the description of that RFC and this very bug here:

"   #1 is considered to be the least significant concern, given that the
   local address values often contain minimal information (e.g.
   192.168.0.2), or have built-in privacy protection (e.g.  [RFC4941]
   IPv6 addresses).
"

Frankly it doesn't sound like they made any case for the tradeoffs between privacy vs media performance at all.  It looks like they blatantly traded everything for performance by summarily stating that private ips contain "minimal information" -- when the reality is that someone's subnet/allocation (or worse MANY subnet/allocations in the case of multiple interfaces + VMs) can tell a public Html/JavaScript context quite a lot about the identity of who they're serving amidst a set of other users within a subnet, or behind any given public ip -- on any given day, even long after any particular local media performance needs have met their objectives.

This is not a tradeoff!  This was completely disregarded.

Another aspect of this that seriously concerns me is that this is the first time in the history of the HTML/JavaScript spec that we've completely disregarded the concept of public/private zoning.  In any other resource or protocol that's accessed by any HTML/JavaScript context today, it is considered insecure to access private resources or any information about them from sites loaded from public zones.

Now suddenly because someone invents a new protocol that needs to move information whos' nature is completely untrusted between private resources, it is considered practically permissible to run in the face of all that past zoning work -- and to start revealing privately zoned information.

... Information that does not even necessarily belong to the browser, nor is it necessarily authorized by the user (or their network) to be permissibly public information!

This has not been vetted, and while we're on the subject of private vs public resources, I'm curious:  Are there even any dialogs to ask users whether there's a potential to expose private information about their network, its resources, or its structure when a web page is loaded?  Or is all this private information just being loaded for the public zone because we're anticipating that we're about to disregard the privacy implications that follow once private connections are established there as well?
Put simply: You can't have a public boat in international waters, without acknowledging who's water you're in! =P
This is the wrong place to have this discussion. Please take it to the IETF rtcweb WG.
(In reply to Eric Rescorla (:ekr) from comment #146)
> This is the wrong place to have this discussion. Please take it to the IETF
> rtcweb WG.

Would you mind posting a link?
(In reply to Eric Rescorla (:ekr) from comment #146)
> This is the wrong place to have this discussion. Please take it to the IETF
> rtcweb WG.

WG: http://tools.ietf.org/wg/rtcweb/
List archive at: https://mailarchive.ietf.org/arch/search/?email_list=rtcweb
The WG draft that contains the current WG recommendations: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01

As Adam says in c141, the current plan of record for Firefox (and I believe other browsers as well) is to implement the recommendations in this specification, namely mode 2 if no permissions prompt is shown and mode 1 if permission has been granted (though this may just be cam/mic permission. text tbd). If people would like that to happen faster, the best way to accomplish that is to do one of the following

1. Review the specification and provide comments so that it is finalized sooner.
2. Provide a patch that updates Firefox to follow the current draft.

If you think that the recommendations in the draft are wrong, then you should also provide comments to the WG.
@Eric Rescorla
(In reply to Eric Rescorla (:ekr) from comment #149)
> (In reply to Eric Rescorla (:ekr) from comment #146)
> > This is the wrong place to have this discussion. Please take it to the IETF
> > rtcweb WG.
> 
> As Adam says in c141, the current plan of record for Firefox (and I believe
> other browsers as well) is to implement the recommendations in this
> specification, namely mode 2 if no permissions prompt is shown and mode 1 if
> permission has been granted (though this may just be cam/mic permission.
> text tbd). If people would like that to happen faster, the best way to
> accomplish that is to do one of the following
> 
> 1. Review the specification and provide comments so that it is finalized
> sooner.
> 2. Provide a patch that updates Firefox to follow the current draft.
> 
> If you think that the recommendations in the draft are wrong, then you
> should also provide comments to the WG.

So, I understand this.  I also understand that the IETF is asking Mozilla and other browsers to violate their own zoning restrictions by leveraging private resources from public contexts in both modes 1 and 2 -- regardless if the user approves of sharing a webcam or microphone.  You've made this very observation yourself in the above comment.

So what is Mozilla's plan to address the zoning issue in order to adhere to their existing security requirements for public and private zoning?  Should we just let websites start generating radio interference and traffic with our VMs as well?

At what point are we going to acknowledge that the user's LAN (and its routing facilities) are private resources?
(In reply to Dave Andrews from comment #151)
> @Eric Rescorla
> (In reply to Eric Rescorla (:ekr) from comment #149)
> > (In reply to Eric Rescorla (:ekr) from comment #146)
> > > This is the wrong place to have this discussion. Please take it to the IETF
> > > rtcweb WG.
> > 
> > As Adam says in c141, the current plan of record for Firefox (and I believe
> > other browsers as well) is to implement the recommendations in this
> > specification, namely mode 2 if no permissions prompt is shown and mode 1 if
> > permission has been granted (though this may just be cam/mic permission.
> > text tbd). If people would like that to happen faster, the best way to
> > accomplish that is to do one of the following
> > 
> > 1. Review the specification and provide comments so that it is finalized
> > sooner.
> > 2. Provide a patch that updates Firefox to follow the current draft.
> > 
> > If you think that the recommendations in the draft are wrong, then you
> > should also provide comments to the WG.
> 
> So, I understand this.  I also understand that the IETF is asking Mozilla
> and other browsers to violate their own zoning restrictions by leveraging
> private resources from public contexts in both modes 1 and 2 -- regardless
> if the user approves of sharing a webcam or microphone.  You've made this
> very observation yourself in the above comment.
> 
> So what is Mozilla's plan to address the zoning issue in order to adhere to
> their existing security requirements for public and private zoning?  Should
> we just let websites start generating radio interference and traffic with
> our VMs as well?
> 
> At what point are we going to acknowledge that the user's LAN (and its
> routing facilities) are private resources?

Adam already explained what we intend to do in c141 and then I explained it again in c149: mode 2 without user consent and mode 1 with user consent. 

I realize that you think that this violates some principle, but that's not an opinion that I share or that as far as I know is shared by the Mozilla security/privacy teams.
> Adam already explained what we intend to do in c141 and then I explained it
> again in c149: mode 2 without user consent and mode 1 with user consent. 
> 
> I realize that you think that this violates some principle, but that's not
> an opinion that I share or that as far as I know is shared by the Mozilla
> security/privacy teams.

It DOES violate some principle, it violates a principle pointed out in the OFFICIAL WebRTC 1.0 W3C Spec

There's a section in WebRTC 1.0 that gets at this EXACT security concern:

https://www.w3.org/TR/webrtc/#impact-on-local-network

"Since the browser is an active platform executing in a trusted network environment (inside the firewall), it is important to limit the damage that the browser can do to other elements on the local network, and it is important to protect data from interception, manipulation and modification by untrusted participants."

"Mitigations include:

    An UA will always request permission from the correspondent UA to communicate using ICE. This ensures that the UA can only send to partners who you have shared credentials with."

Though, because it looks like the spec they picked does THIS:

"dictionary RTCConfiguration {
             sequence<RTCIceServer>   iceServers;
             RTCIceTransportPolicy    iceTransportPolicy = "all";
             RTCBundlePolicy          bundlePolicy = "balanced";
             RTCRtcpMuxPolicy         rtcpMuxPolicy = "require";
             DOMString                peerIdentity;
             sequence<RTCCertificate> certificates;
             unsigned short           iceCandidatePoolSize = 0;
};

iceTransportPolicy of type RTCIceTransportPolicy, defaulting to "all"

    Indicates which candidates the ICE agent is allowed to use."

enum RTCIceTransportPolicy {
    "public",
    "relay",
    "all"
};

public	The ICE agent MUST filter out candidates with private IP addresses [RFC1918].
relay	The ICE agent MUST only use media relay candidates such as candidates passing through a TURN server. This can be used to reduce leakage of IP addresses in certain use cases.
all	The ICE agent may use any type of candidates when this value is specified.


^^ Then it is therefore IMPOSSIBLE to limit the damage to the local network without prompting the UA whether to permit all ICE connections every time they are needed.  This protocol is digging its own grave by defaulting everything here to a mode called "abuse my network".

If Mozilla is not going to prompt the UA whether to allow ICE connections, then by the W3C and Mozilla's own admission:  Mozilla has chosen to NOT limit its damage to other elements on the user's own network in its implementation of WebRTC.
There's a trivial way to fix this without breaking the UI horribly...

Change the default in that enum to "public" via "media.peerconnection.ice.default_address_only" (or some equivalent), and then prompt the user if the website manually specifies anything more invasive.

It will break spec, but it's not impractical given these serious security and privacy implications that that W3C points out about WebRTC.

This is the best workaround/middleground I can think of without implementing popups asking whether to permit the use of these insecure APIs every time they're needed.
(In reply to Dave Andrews from comment #153)
> This protocol is digging its own grave by defaulting everything here to a mode called "abuse my network".

As EKR pointed out, this conversation should be taken to the IETF RTCWEB mailing list. He provided pointers in comment 149.

Two bits of advice when engaging on that list: (1) histrionics will generally not get you much headway; and (2) if you're raising a security issue, you really need to do it in the form of a threat model. Identify and describe potential attacks, the ease of mounting them, and the consequences of successfully mounting them.
As people have repeatedly pointed out, discussion should happen on relevant mailing lists. Spamming this bug with repeated comments isn't helpful. I'm restricting comments on this bug to avoid this and ensure people contact the relevant mailing lists / groups instead of commenting here.
Restrict Comments: true
Restrict Comments: false
Restrict Comments: true
No longer blocks: uplift_tor_fingerprinting
Whiteboard: [fingerprinting] → [fingerprinting][fp-triaged]
See Also: → 1466148
Whiteboard: [fingerprinting][fp-triaged] → [fingerprinting]
Whiteboard: [fingerprinting] → [fingerprinting][fp-triaged]
Summary: WebRTC Internal IP Address Leakage → [meta] WebRTC Internal IP Address Leakage

I believe with mDNS used in host candidates this no longer warrants such high severity.

Severity: critical → S3

Can you please explain? Are you saying that there's no way that IP addresses leak to the site anymore? If so, why do you believe that?

Flags: needinfo?(drno)

(In reply to Ben Bucksch (:BenB) from comment #161)

Can you please explain? Are you saying that there's no way that IP addresses leak to the site anymore? If so, why do you believe that?

With mDNS ICE candidate are still being given to the website. But the ICE candidate no longer contain private IP addresses.

Flags: needinfo?(drno)
You need to log in before you can comment on or make changes to this bug.