Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 333752 Google Chrome WebRTC IP Address Leakage
Starred by 60 users Reported by jks...@gmail.com, Jan 13 2014 Back to list
Status: Verified
Owner:
Closed: Feb 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: ----
Type: ----



Sign in to add a comment
Vulnerability Details:
Chrome has a vulnerability whereby internal IP addresses of users can be leaked using Javascript alone without notifying the user.

Affected Versions:
Chrome Version: Version 31.0.1650.63 m + Version 32.0.1700.72 beta-m Stable + Version 34.0.1781.0 Canary
Operating System: Windows 7 Service Pack 1

Reproduction Case:
The following can be executed in the Chrome console to reproduce the test case. A self-contained HTML file has also been attached.

// create a new peer connection - dont need any stun servers for this attack to work
// adding a stun server provides the external ip address of the user as well (see HTML example)
var peer = new webkitRTCPeerConnection(null);

// create an offer object before any streams are added
// this is important because getUserMedia() requires explicit user permission
peer.createOffer(function(sdp) {
   peer.setLocalDescription(sdp, function() {
      // there seems to be a bug in the async call where the callback is called before the localDescription property has been set
      // setTimeout provides some time for the async call to finish
      setTimeout(function() {
         var sdp = peer.localDescription.sdp;
         console.log(sdp);
      }, 100);
   });
}, function(err) {
   console.error(err);
}, {});

Possible Remediation Approach:
One possible approach to resolve this issue is to take the approach used by Mozilla Firefox. Firefox blocks offer creation if no streams have been added to the RTCPeerConnection object. It also does not permit the MediaStream constructors to be called directly and currently it seems that the only way to get a MediaStream is to call getUserMedia(). Currently in the case of Chrome, even if the above fix was used, an empty stream can be added using: peer.addStream(new webkitMediaStream());

Reported By: 
Jaap Karan Singh and Colin Wong, BAE Systems Detica
 
chrome-ip-address-webrtc-leak.html
513 bytes View Download
Project Member Comment 1 by clusterf...@chromium.org, Jan 13 2014
Labels: Cr-Blink-WebRTC
Comment 2 by jln@chromium.org, Jan 13 2014
Labels: OS-All Security_Impact-Beta Security_Impact-Stable Security_Severity-Low
Owner: sergel@chromium.org
Status: Assigned
Serge, could you help finding an owner for this?
Comment 3 by sergel@chromium.org, Jan 13 2014
Cc: niklase@chromium.org tommi@chromium.org juberti@chromium.org
Comment 4 by sergel@chromium.org, Jan 13 2014
Owner: juberti@chromium.org
Status: Unconfirmed
This behavior is by design. In order to establish p2p connectivity, the system must enumerate the available IP addresses that can be used for connection; in certain cases, connectivity can only be achieved via the internal IP addresses.

Note that Firefox allows address enumeration even without adding a stream. For example, https://www.sharefest.me can do file sharing without any user prompts.

We considered one possible mitigation, to prevent gathering of internal addresses, but this has the downside of preventing any communication if both endpoints are behind the same NAT and the NAT does not support hairpin behavior, which, in addition to being problematic for users, would also make development and testing much more complicated.
Comment 6 by kenrb@chromium.org, Jan 14 2014
Status: Untriaged
This is not an ideal state. Allowing harvesting of internal network IP addresses and blocking WebRTC on local networks are both undesirable. Are there any other alternatives, such as possibly introducing user action requirements for special cases?
We considered this, but in the end I don't think that introducing user action makes sense. It's not a permission that is well understood ("do you want this application to enumerate your network interfaces?")

With the move to IPv6, the notion of NATed addresses goes away, so any concerns here around exposing internal addresses to applications are only significant in the short term.

If the main concern is the enumeration of all interfaces, one option could be to only return the interface that has the default route. This might complicate wwan/wlan handover scenarios though.
Project Member Comment 8 by clusterf...@chromium.org, Jan 16 2014
Labels: Untriaged-1
Comment 9 by kenrb@chromium.org, Jan 16 2014
Does this also defeat anonymizing proxies?
e.g. Tor?

WebRTC traffic is not anonymized by Tor; the approach recommended in previous discussions on this topic is to disable WebRTC (along with any other non-HTTP services) in builds customized for Tor.
Comment 11 by kenrb@chromium.org, Jan 16 2014
It sounds like this might need follow up discussion. I don't know how to address the technical challenge but many users would be unhappy to find out that Chrome exposes information about internal network topography to external websites.
This has been discussed a fair amount in the webrtc community, albeit with no silver bullets, as mentioned in 
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07, S 5.4 and 
http://tools.ietf.org/id/draft-ietf-rtcweb-security-05.txt, S 4.2.4

Happy to discuss more.
Comment 13 by kenrb@chromium.org, Jan 17 2014
Labels: Cr-Privacy Cr-Enterprise
Nice to see the spec drafts acknowledge the problem, even if they don't have any solution. :/

Adding Privacy and Enterprise flags to this bug, since this really falls more into their domain than Security.
Project Member Comment 14 by clusterf...@chromium.org, Jan 18 2014
Labels: -Untriaged-1 Untriaged-2
Comment 15 by kenrb@chromium.org, Jan 20 2014
Cc: atwilson@chromium.org mnissler@chromium.org
Project Member Comment 16 by clusterf...@chromium.org, Jan 21 2014
Labels: -Untriaged-2 Untriaged-3
Labels: -Untriaged-3
Status: Assigned
If I remember correctly, the IP snooping is gated by the user granting access to the camera. Is this correct?
It's not directly gated by the camera access. There are one-way media and p2p data cases where the user is not required to consent to media access because their camera and/or mic is never needed.
Cc: battre@chromium.org
Owner: battre@chromium.org
Dominic: is the scenario described in c#18 a privacy concern? This bug is not really a security bug.
Labels: -Restrict-View-SecurityTeam -Type-Bug-Security -Security_Impact-Beta -Security_Impact-Stable -Security_Severity-Low
Summary: Google Chrome WebRTC IP Address Leakage (was: Security: Google Chrome WebRTC IP Address Leakage)
Removing from security queue, implemented as per the spec. Privacy/Enterprise people, do you care about this?
Comment 22 by vrk@chromium.org, Sep 24 2014
Labels: -Cr-Blink-WebRTC Cr-Blink-Webrtc-Network
Here is a public demo of this leakage in action:
http://net.ipcalf.com/

I'm not too familiar with the spec, but could the user agent wrap local IP addresses to avoid ever exposing an IP directly to the code running on the web?  It's not clear to me why revealing any IPs directly is necessary.


Relevant source on net.ipcalf.com:

var RTCPeerConnection = /*window.RTCPeerConnection ||*/ window.webkitRTCPeerConnection || window.mozRTCPeerConnection;
    var rtc = new RTCPeerConnection({iceServers:[]});
    if (window.mozRTCPeerConnection) {      // FF needs a channel/stream to proceed
        rtc.createDataChannel('', {reliable:false});
    };
    
    rtc.onicecandidate = function (evt) {
        // convert the candidate to SDP so we can run it through our general parser
        // see https://twitter.com/lancestout/status/525796175425720320 for details
        if (evt.candidate) grepSDP("a="+evt.candidate.candidate);
    };
    rtc.createOffer(function (offerDesc) {
        grepSDP(offerDesc.sdp);
        rtc.setLocalDescription(offerDesc);
    }, function (e) { console.warn("offer failed", e); });
    
    
    var addrs = Object.create(null);
    addrs["0.0.0.0"] = false;
    function updateDisplay(newAddr) {
        if (newAddr in addrs) return;
        else addrs[newAddr] = true;
        var displayAddrs = Object.keys(addrs).filter(function (k) { return addrs[k]; });
        document.getElementById('list').textContent = displayAddrs.join(" or perhaps ") || "n/a";
    }
    
    function grepSDP(sdp) {
        var hosts = [];
        sdp.split('\r\n').forEach(function (line) { // c.f. http://tools.ietf.org/html/rfc4566#page-39
            if (~line.indexOf("a=candidate")) {     // http://tools.ietf.org/html/rfc4566#section-5.13
                var parts = line.split(' '),        // http://tools.ietf.org/html/rfc5245#section-15.1
                    addr = parts[4],
                    type = parts[7];
                if (type === 'host') updateDisplay(addr);
            } else if (~line.indexOf("c=")) {       // http://tools.ietf.org/html/rfc4566#section-5.7
                var parts = line.split(' '),
                    addr = parts[2];
                updateDisplay(addr);
            }
        });
    }
Cc: reddaly@chromium.org
Comment 25 by juberti@google.com, Oct 30 2014
Any wrapped IP would need to be able to be unwrapped by the remote side, so that it can try a connection to the source IP. Therefore, I don't think the wrapping would have any strength.

As to why the web page needs to see the IPs, the IPs are handed to JS to be sent out of band to the remote side.
Yes, the only protection this adds is preventing web pages from seeing local IPs.  The IPs would still be visible to other browsers.

Could you expound on why the web page needs to see the IPs?  i.e., why is sending the IP out of band important?
There is no in-band mechanism that can be used.
Sorry, but why is that?  I may not understand your usage in-band vs. out-of-band in this context.

Here are my assumptions:
1) Any local IP address obtained by a web page is only used to establish connections to that IP address.
2) All connections established by a web page are established by the user agent on behalf of the web page.

So if the user agent encodes local IP addresses before handing them to the web page, it could decode them before establishing a connection.

Is one of these assumptions wrong?  Or is my logic flawed?

I take "no in-band mechanism ... can be used" to mean that assumption 2 is incorrect.
The local IP address is communicated to the remote side so that the *remote* side can connect to you. The remote side needs to be able to get a raw IP address (for you) somehow.
I don't think there's immediate action required from an enterprise perspective, but we may want to consider adding a policy setting for admins to adjust behavior of WebRTC as needed and/or restrict WebRTC usage to whitelisted web origins only.
Comment 31 by reddaly@google.com, Oct 31 2014
re #29: I'm unfamiliar with the protocol used to send the local IP over.  Is it app-specific? It seems that the IP could be communicated to the remote server by the browser, still only exposing the web page to an encoded version of the IP.
Cc: bemasc@chromium.org
reddaly: Communicating the IP to the remote peer is left to the app.  WebRTC does not specify a client-server signalling protocol.  On the web, the server and the app typically represent the same entity, so there is little incentive to conceal info from one but reveal it to the other.

However, if you're interested in efforts to change the treatment of local IP addresses, you might like http://www.ietf.org/id/draft-schwartz-rtcweb-return-04.txt, which describes a way to give users more control over WebRTC routing.
We have also suggested a local policy setting that could restrict the use of internal IPs. This could have downsides (i.e. in intra-enterprisde communication if the corp NAT is not set up for hairpinning) so it's not something we would want to turn on by default.
Comment 34 by vrk@chromium.org, Nov 25 2014
Labels: WebrtcTriaged
need a fix
Why not prompting the user for permit when any webrtc functions are used for the first time that reveal local IP addresses? Similiar like the user is prompted already today when accessing local media sources? 
Because in general we don't want to prompt users with questions they are ill-equipped to answer. The number of end-users that understand the difference between their local IP and the global IP visible to the outside world is very small so they have no context by which to make an informed decision.

Whereas people in general understand the difference between "playing a media stream from the internet" vs "playing a stream from a file on their device".

On the enterprise side, we have not heard of any concerns over this, and in general enterprises have ample resources (proxies, firewalls, etc) to restrict which WebRTC endpoints their users can access. I don't see any further action required on the enterprise side.
What is around now known as "hack" is the code already mentioned above, http://net.ipcalf.com/.
There no media sources are used, therefore no user prompt comes up currently.

For real webrtc audio/video application cases, both the use of media sources and the gathering of local IP address is needed, so by making a combined prompt and user grant, like "Are you willing to allow access to your microphone/camera and to reveal your private IP address to the site ..." the user will not get more prompts than now, and nobody can say then that webrtc reveals private data without user consent.  
That will prevent uptake of data channel applications.

Generally, I don't think questions regarding IP addresses are things that we can expect users to answer properly.

The current concerns regarding this issue are mostly focused around sites detecting the ISP public IP address in VPN situations, which I think is a different problem from what is being discussed here (i.e. the private address is not the concern).
This issue means a user prompt is required for all WebRTC apps to be enabled.

You've got users on VPNs out there and this issue automatically exposes both their private and public IPs.

The right thing to do is as Martin said in #38: a combined prompt.
Comment 41 by juberti@webrtc.org, Feb 12 2015
We are investigating various solutions at the moment.
Project Member Comment 42 by bugdroid1@chromium.org, Feb 19 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7c98bab02128ae9fdc4fcc9a9df38588af86290e

commit 7c98bab02128ae9fdc4fcc9a9df38588af86290e
Author: guoweis <guoweis@chromium.org>
Date: Thu Feb 19 14:54:51 2015

Add a Preference to allow WebRTC only bind to "any address" (all 0s). This way, no local IP or private ISP's public IP leaked when VPN is the default route.

Add webrtc.multiple_routes_disabled preference to RendererPreferences. Default is false. When set to true, a new port allocator flag will be passed to P2PPortAllocator which will have WebRTC only bind to all 0s (any address) IP and the default route will be used as how chrome/http is routed.

Each rtc_peer_connection_handler is associated with a WebFrame and it leads to a webview and then the mapping RenderViewImpl which has RendererPreferences that we care.

The corresponding webrtc change is at https://webrtc-codereview.appspot.com/39129004

BUG= 333752 

Review URL: https://codereview.chromium.org/916873004

Cr-Commit-Position: refs/heads/master@{#317047}

[modify] http://crrev.com/7c98bab02128ae9fdc4fcc9a9df38588af86290e/chrome/browser/renderer_preferences_util.cc
[modify] http://crrev.com/7c98bab02128ae9fdc4fcc9a9df38588af86290e/chrome/browser/ui/browser_ui_prefs.cc
[modify] http://crrev.com/7c98bab02128ae9fdc4fcc9a9df38588af86290e/chrome/common/pref_names.cc
[modify] http://crrev.com/7c98bab02128ae9fdc4fcc9a9df38588af86290e/chrome/common/pref_names.h
[modify] http://crrev.com/7c98bab02128ae9fdc4fcc9a9df38588af86290e/content/common/view_messages.h
[modify] http://crrev.com/7c98bab02128ae9fdc4fcc9a9df38588af86290e/content/public/common/renderer_preferences.cc
[modify] http://crrev.com/7c98bab02128ae9fdc4fcc9a9df38588af86290e/content/public/common/renderer_preferences.h
[modify] http://crrev.com/7c98bab02128ae9fdc4fcc9a9df38588af86290e/content/renderer/media/webrtc/peer_connection_dependency_factory.cc
[modify] http://crrev.com/7c98bab02128ae9fdc4fcc9a9df38588af86290e/content/renderer/p2p/port_allocator.cc
[modify] http://crrev.com/7c98bab02128ae9fdc4fcc9a9df38588af86290e/content/renderer/p2p/port_allocator.h

Comment 43 by guoweis@webrtc.org, Feb 19 2015
The way to test this change is to copy the following into preferences file

"webrtc": {
 "multiple_routes_enabled": false
},
The extension change is also landed by
https://codereview.chromium.org/940893003/
Status: Fixed
Note that with this preference change, along with the extension, private IP along with non-default public IP will be hidden.

Private IP will be filtered out. Non-default public IP simply won't be discovered as the binding is done to "any" address (all 0s), routing should just behave like http.
I'm not sure I understand the fix. Can someone dumb this down a bit?

- Why isn't this preference set to true by default?
- What does "non-default" mean in reference to "non-default public IP"?
Comment 47 by juberti@webrtc.org, Feb 19 2015
This change causes WebRTC traffic to be forced through the same path that HTTP traffic would, i.e. the traffic follows the default route to the destination site. As a result, the only IP that can be discovered is the IP that the remote site could already learn from HTTP traffic.

It's not on by default at this time because it has implications for quality-of-service; it may force WebRTC traffic to take a suboptimal routing path, e.g. calls on a company intranet may be forced to go outside the company and then be hairpinned back in.
I see, so my understanding now is that instead of being P2P, this setting makes traffic go through a middleman (the middleman being the host providing the WebRTC service?).

That seems like a sub optimal fix, or at least incomplete.

Users have to know to turn on this setting. This fix doesn't address that issue. Most users who are behind VPNs will therefore still be affected by the problem.

A simpler fix would be to simply prevent WebRTC from being enabled without prompting from the user.
Comment 49 by juberti@webrtc.org, Feb 19 2015
Sorry for being unclear. The WebRTC traffic will go through the same local IP used for HTTP traffic, e.g. the VPN if one exists and is the default route. It will not go to the web server.

Many users on VPNs (e.g. corp VPNs) will want to use WebRTC even while VPNed. This solution allows these users to force all WebRTC traffic through the VPN, if desired. The 'prompt' solution would not solve that situation.

We will of course continue to evaluate and refine this solution. Getting a workable v1 solution was a top priority for Chrome 42.
> The WebRTC traffic will go through the same local IP used for HTTP traffic, e.g. the VPN if one exists and is the default route. It will not go to the web server.
> Many users on VPNs (e.g. corp VPNs) will want to use WebRTC even while VPNed. This solution allows these users to force all WebRTC traffic through the VPN, if desired.

I see, thank you for that clarification.

> The 'prompt' solution would not solve that situation

Right, but it would address the privacy issue in the default case, which is the primary concern. This fix doesn't (yet) do that. Users have to be aware of this setting, understand what it does (less than 1% probably), and then they will experience degraded QoS.

On the other hand, the prompt preserves QoS, and protects all users by default.
Comment 51 by juberti@webrtc.org, Feb 19 2015
I think the prompt is suboptimal as well, since to non-technical users it's very unclear what "do you want to allow this site to use WebRTC" really means. We don't ask users about whether they should allow XHR, IMG downloads, font enumeration, etc.

However, as mentioned above, we'll keep thinking about this.
> to non-technical users it's very unclear what "do you want to allow this site to use WebRTC" really means.

Agreed, so that's why an easier to understand message would be helpful. I'm sure the Chrome team can come up with a great one.

It's really not anything special to prompt the user to allow features that could impact privacy. Apple does this *constantly* on iOS for things like GPS, Contacts, Calendar, and Photos access, as well as notifications.

And that's a big reason why I and many people choose iOS btw.

At the same time, users feel empowered, not encumbered, by the fact that they can choose what information they share.

So, something like: "This webpage is requesting access to your public and private IPs for its functionality, Allow/Deny?"

> However, as mentioned above, we'll keep thinking about this.

Awesome. Well, in that case I would also consider marking this as still unresolved, since it's not resolved for most of your users.
Comment 53 by juberti@webrtc.org, Feb 19 2015
I understand your point, but my understanding is that on iOS right now, an application can do whatever it wants on the network without asking the user.
> I understand your point, but my understanding is that on iOS right now, an application can do whatever it wants on the network without asking the user.

There is precedent even in the case of Safari, where users get prompted if an HTML5 app wants to know the user's location.
Comment 55 by juberti@webrtc.org, Feb 19 2015
That is the HTML5 Geolocation API; Chrome prompts as well when that API is used.
Cc: guoweis@chromium.org
the preference name in comment #42 is "multiple_routes_disabled", but in comment #43 is reads "multiple_routes_enabled", which is correct or both of them are Ok? Thank.
Comment 58 by guoweis@webrtc.org, Feb 20 2015
apologize for the inconsistency. #43 was right. It's "webrtc.multiple_routes_enabled". I also modified the description in the Issue 916873004 to reflect this.
Labels: M-42
As a non-technical user of chrome ( but knowledgeable in IT in general) I just want to say that my concern about this issue has found me in this forum ( where I have never been before, or needed to be). If I am here, many others are seriously concerned about this, and wondering: why the hell dont you do something about it?

I have not read that much of the forum, but to find out this issue is being discussed in terms of, and I summarise ' Users wont understand, therfore maybe we shouldnt do anything' is disgusting.

Sorry for my annoyance, I just think this should have been blocked immediatley and users informed. BAHH!!!!!
Comment 61 by juberti@webrtc.org, Feb 25 2015
Your suggestion that we didn't do anything is inaccurate. We did do something about it; we gave users a way to force WebRTC traffic through their VPN in Chrome 42. 

See comment #43 for how to set this setting.


Comment 62 by hta@webrtc.org, Feb 25 2015
Note to #60: This is not a forum, this is a bug tracker.
The forum is the mailing list discuss-webrtc - see https://groups.google.com/forum/#!forum/discuss-webrtc for details.

Issue 457492 has been merged into this issue.
Copied here from Issue 457492 to CC folks:

> This is a dup to 333752 which has been fixed in M42.  Please see that bug for details.

The OP's concern has not been addressed in 333752.

My understanding is that 333752 provided a custom option to force traffic through VPN. That doesn't address this issue for multiple reasons:

1. OP asked for a setting in "chrome settings", not an invisible option.
2. OP asked to be able to disable WebRTC. This has not been offered here or in 333752.

Please unmark this as "fixed" or "duplicate".
Can someone make #43 more clear so that all users would know how to change this setting if desired? Like a step-by-step.
This issue is not fixed for a couple reasons (at least):

1. Users are placed in danger by default (see: https://code.google.com/p/chromium/issues/detail?id=457492#c8 )

2. Possibly in all cases (but certainly in ordinary browsing), a user's private IP is still leaked. In a targeted attack, information about the internal local area network topology can be very relevant, which is one of the reasons why it should be treated as private information.
Status: Verified
For #65:
1) Go to chrome://version/, find the directory listed in "Profile Path"
2) Close all instances of Chrome. This is *important* because Chrome regularly updates the Preferences file while Chrome is running, and you need that file to be in a static state in order for changes to stick (and to avoid possible file corruption).
3) Use your OS's file manager to navigate to the Profile Path
4) Copy your existing Preferences file (in case something goes wrong during editing)
5) Open the Preferences file for editing
6) At the bottom of the file, before the final closing bracket, make these two changes:
6a) add a comma to the last existing entry
6b) add
   "webrtc": {
      "multiple_routes_enabled": false
   }

For example, the last few lines of my Preferences now look like:
   "translate_whitelists": {

   },
   "webrtc": {
      "multiple_routes_enabled": false
   }
}

7) Save the changes to Preferences and reopen Chrome
8a) If you immediately see an error about profile corruption, close Chrome, restore your Preferences from backup, and edit that file again. In my experience, the Preferences file seems sensitive to the presence/absence of commas. (Please don't put complaints about Preferences parsing in this bug)
8b) If you don't see an error about profile corruption, then you're good to go. Proceed with any relevant IP address tests.

For #66:
Based on my testing and the fact that bug 457492 has been reopened for to possibly provide a simplified solution, I'm closing this bug.

For anyone else:
a) If you have problems using the multiple_routes_enabled Preference, please file a new bug. Be sure to include the exact text of the "webrtc" section of your Preferences file, along with repro steps.
b) If you're interested in future plans, please star bug 457492.
c) If you have suggestions for other ways to address this issue in future releases of Chrome, please post to the public discuss-webrtc group (https://groups.google.com/forum/#!forum/discuss-webrtc)
This solution does not work.....

The end of my prefernce files reads:

},
   "translate_accepted_count": {
      "de": 1,
      "es": 0,
      "fr": 1,
      "lt": 1,
      "ru": 0
   },
   "translate_blocked_languages": [ "en" ],
   "translate_denied_count": {
      "de": 0,
      "es": 2,
      "fr": 0,
      "lt": 0,
      "ru": 1
   },
   "translate_last_denied_time": 1422920008040.3,
   "translate_site_blacklist": [ "turbovideos.net" ],
   "translate_too_often_denied": true,
   "translate_whitelists": {

   },
   "webrtc": {
      "multiple_routes_enabled": false
   },
   "zerosuggest": {
      "cachedresults": ""
   }
}


VPN enabled, and My public IP address is still revealed.

I am shocked at the attitude taken towards this serious breach in security by a google endorsed product.  

This is an issue even after the latest chrome update, GRRRRRRR
To understand the issue, could you post the result from this url
https://diafygi.github.io/webrtc-ips/ with and without this preference?
This will help to understand what is going on here.
You also need to test it at http://www.ipleak.net . Sometimes the link given in #69 gives nothing while ipleak.net still manages to get the actual IP through webRTC.
I also strongly agree that this issue needs to be taken more seriously. At least there should be an option in advanced settings (such as chrome://flags) to prevent the IP leak like in Firefox.
I just tried ipleak.net and it did not detect my location while connected via vpn.  It just reported the same IPs as the link in #69 does.

tonytan980: what version of Chrome are you using to test this?
https://code.google.com/p/chromium/issues/detail?id=457492 is tracking adding a Chrome flag/option to control this.
#67...I do NOT accept this as a viable solution for anyone but the most technically advanced. There needs to be a flag or some other "switch" available to users or support is going to be a nightmare. 
#74: yes, see bug 457492
both:

 ipleak.net 

and 

https://diafygi.github.io/webrtc-ips/

reveal my Public IP with the 

 "webrtc": {
      "multiple_routes_enabled": false

Flag set.

There is no point in posting the results, they are identical.

Chrome version : 41.0.2272.76 m
Chrome 41 predates these changes. Could you try Chrome Beta or Chrome Canary? (i.e., Chrome 42)
Ok, thanks. I updated to 43.0.2326.2 canary (64-bit)

added the code to the end of my preferences file

And IP does not leak on iptest,net or https://diafygi.github.io/webrtc-ips/

when using a vpn.


However, that may work for me... what about the millions of people who do not look for this sort of solution or do not even know about the problem?  I am still pretty shocked to find this sort of problem only has solutions available to those who keep asking and digging *sigh*

Regardless, many thanks for giving me a solution.

Comment 79 by roy...@gmail.com, Apr 23 2015
The https://diafygi.github.io/webrtc-ips/ test is outdated. Current chrome (42.0.2311.90), even with the WebRTC extension installed, shows the real IP when you visit the up to date test:

http://ipleak.net/
The extension is outdated, too. You need to change your Chrome preferences
file to prevent WebRTC IP leaks. Please see the earlier comments.
El 23/4/2015 12:26, <chromium@googlecode.com> escribió:
Comment 81 by hta@google.com, Apr 24 2015
re #79 - please be precise - does ipleak.net show different addresses for the first and second IP addresses detected?

If the addresses are the same, the site detects no WebRTC problem (the first address is revealed by HTTP, not WebRTC). If they're different, the configuration is of interest.
Comment 82 by roy...@gmail.com, Apr 24 2015
With the WebRTC extension installed (https://chrome.google.com/webstore/detail/webrtc-block/nphkkbaidamjmhfanlpblblcadhfbkdm), the test https://diafygi.github.io/webrtc-ips/ and https://www.browserleaks.com/webrtc do not show the real public IP.

But http://ipleak.net/ shows the real public IP and the VPN IP, even with the extension installed. I read somewhere what this test does differently from the others that enables detection. It has to do with creating a new iframe on the fly or something similar. I can try to hunt it down.

Now that I've applied the mitigation (http://blog.golgi.io/excuse-me-sir-your-webrtc-is-leaking) to standard Chrome 42 (not canary) no tests AFAIK can detect the real IP.

From the last link above: "Long term the ideal solution would be to have a user prompt whenever a WebRTC connection is being requested. This would be similar to the prompt requesting a user to authorise access to the camera and microphone." In other words, ask the user if it is OK to reveal to the website your real IP. (feel free to ignore this part: it might be possible to bypass the question if it can be determined that the user's ISP public IP is being broadcasted or when the WebRTC request is coming from within the LAN.)



Comment 83 Deleted
Comment 84 by erle...@gmail.com, Jun 10 2015
#67 does not solve this bug on Chrome 43.0.2357.124.

I've opened bug 497040 because of this.
Issue 506730 has been merged into this issue.
Cc: infe...@chromium.org
Issue 509430 has been merged into this issue.
Cc: pdr@chromium.org
FYI: uBlock Origin now has an option to prevent webrtc ip leakage: http://www.ghacks.net/2015/07/02/you-can-block-webrtc-from-leaking-your-ip-now-in-ublock-origin/

Seems to be working properly (but it does break certain things for me, like twilio integrations on certain sites).
Comment 89 by ivan@ludios.org, Jul 15 2015
Even with that uBlock Origin option enabled, your non-proxy WAN IP is leaked if you're using a SOCKS proxy.
#88: could you post a link to a broken site? That is one of the things we are trying to avoid.
#89: that issue is being tracked in bug 497040.
#90: The one I'm having trouble with now is ClearSlide conference calling (using twilio). 
Test it out here: http://prestoslides.com/prestodoctor 
Click "dial in" at the top, enter 8242-9078 for the access code.

Before enabling the webrtc blocking option on uBlock Origin, dial in works and says "you will now be added to the conference".

When I enable the option, the dial in doesn't work (it makes the chime noise, but then nothing).

Feel free to test out, but try to not use all my conference calling minutes ;-)
Comment 92 by guoweis@webrtc.org, Jul 17 2015
I can repro #91 scenario now and this seems like a bug. I'll be working on this. The credential you provided helped me repro this. 
Comment 93 by guoweis@webrtc.org, Jul 22 2015
created webrtc bug 4865 https://code.google.com/p/webrtc/issues/detail?id=4865 to track issues in #92
Comment 94 by guoweis@webrtc.org, Jul 27 2015
ok. found the issue. The problem that the stun port in this case (0.0.0.0) never has any candidate such that it is never PortReady hence doesn't start to listen.
I think in this case we would probably want to go immediately to PortReady if we have no STUN server. Or maybe we would always go to ready as soon as the bind succeeds.
Comment 96 by guoweis@webrtc.org, Jul 27 2015
I am thinking we should generate 127.0.0.1 candidate in this case (and filter it out later if we have turn/stun specified). 
Comment 97 by Deleted ...@, Sep 28 2015
Robocop
@83 try the "Official" WebRTC Network Limiter extension created by Google ( https://chrome.google.com/webstore/detail/npeicpdbkakmehahjeeohfdhnlpdklia )
Issue 567453 has been merged into this issue.
Sign in to add a comment