PSA: Private IP addresses exposed by WebRTC changing to mDNS hostnames

[Qingsi Wang]

Summary

WebRTC currently lets web applications discover private IP addresses to enable direct connectivity between hosts on a local network. While private IP addresses do not uniquely identify browser users, they may still be used for tracking purposes. To prevent this misuse, private IP addresses returned by RTCPeerConnection will now be masked with mDNS hostnames in certain situations. While this change should be transparent to most WebRTC applications, some developers may need to update their client and backend services. 

This change is currently enabled for 50% of Chrome users, and is expected to fully roll out in August 2019 as part of the Chrome 76 release. WebRTC services can verify whether their services are affected by setting the following flag in Chrome 73 or later: chrome://flags/#enable-webrtc-hide-local-ips-with-mdns

Why are we doing this?

We have observed a trend of web sites using WebRTC specifically to obtain private IP addresses, presumably for tracking purposes. Accordingly, we have collaborated with other browser vendors to address this problem by using mDNS hostnames instead of private IP addresses in WebRTC, as described in this pending IETF spec. We have also experimentally verified the efficacy of the mDNS technique, following the initial announcement of this feature in January.

Impact on applications

When the feature is active, private IP addresses in ICE host candidates will be replaced by an mDNS hostname, e.g., 1f4712db-ea17-4bcf-a596-105139dfd8bf.local. Currently, this feature is active for all sites except those that have getUserMedia permissions, which are presumed to have a higher degree of user trust.

WebRTC services that do not support addresses in the above format may be impacted, causing sessions to fail or use a less direct connection path. WebRTC services may be especially affected if they parse out addresses from RTCSessionDescription or RTCIceCandidate objects and assume those addresses are IP addresses, or have server components that do the same. In particular, older versions of the libnice library, used by some applications, do not parse such addresses properly.

Impact on connectivity

mDNS does not work in all situations; on some networks, mDNS may be disabled, or an endpoint may be too many hops away to resolve an mDNS hostname. In these cases, fallback to STUN will be required, and this may sometimes fail; as such, some amount of impact on connection success rate is to be expected.

 

From a broad analysis of peer-to-peer connections in the experimental deployment, the overall impact of mDNS on connectivity is modest, a 2% (relative) reduction in connection rate when mDNS was used by Chrome on both sides. In this population, the percentage of successful connections that used STUN on one side or the other increased from 94% to 97%, with a corresponding decrease in host-to-host connections. We believe the connectivity impact stems primarily from connections that previously worked host-to-host, but do not work with mDNS, and cannot fall back to STUN due to lack of hairpin support in the NAT.

 

Somewhat surprisingly, for connections between Chrome and non-mDNS endpoints, we observed a larger impact, roughly 3% (relative) reduction in connection rate when the remote side supplied private IPs and 7% (relative) when the remote side supplied only public IPs. While mDNS should have zero impact in these cases, we believe this is explained by problems triggered by mDNS in third-party ICE stacks, including the aforementioned issues regarding parsing mDNS candidates as well as issues discovering peer-reflexive candidates from ICE connectivity checks.

 

Given the success of the mDNS technique in combating tracking via private IP addresses, we believe this small impact on connection rate is an acceptable tradeoff. We will continue to investigate improvements to this technique to further minimize the downsides.

General recommendations

Improvements in Chrome are frequently rolled out as experiments and deploy first in Chrome Canary and the pre-stable Dev and Beta versions. Important experiments are also announced via email at the start of the rollout. We highly recommend WebRTC developers to:

• Join blink-dev and discuss-webrtc to follow PSAs and other important announcements

• Systematically test in Chrome Canary to see how your application behaves with upcoming Chrome changes

• Provide feedback on the relevant bugs/forum threads

[Qingsi Wang]

[Silvia Pfeiffer]

"except those that have getUserMedia permissions"

Does this mean that if you have getUserMedia permissions, you still get normal IP addresses going forward?

Thanks,

Silvia.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/32c0563f-8329-4491-9494-29d9b5208666%40googlegroups.com.

[Qingsi Wang]

Yes. If the peer connection has either audio or video capture permission, IP addresses are returned in host candidates.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

[eric littley]

We use chrome as a client for receiving video over WebRTC from a server. The chrome client has no need to record video or audio, as a result, most of the machines that our application is serving will not have microphone/camera recording present and enabled. It looks like getUserMedia will fail if no recording devices are present. Also, it is pretty weird for the user to allow video/audio recording for an application that does not use it. Is there any path forward for an application to ask the user's permission to expose their IP without asking for permission to use their microphone/camera?

[Qingsi Wang]

For the permission API, there is an ongoing discussion on direct connections: https://github.com/w3c/webrtc-pc/pull/2175#issue-271288320.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/c854741c-91ee-4554-911d-1f13c5b852f9%40googlegroups.com.

[Justin Uberti]

Eric, your application (and all client-to-server applications) should be unaffected by this change, assuming you don't malfunction when receiving mDNS candidates (you can simply ignore them).

We explicitly recommend against asking for gUM permission to bypass the mDNS feature, as it should not be necessary, and is pretty weird for the user, as you point out.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CA%2Bm752J1%2BF6wq%3DK%3Dfycc6acOM%3D88y4XKL3v9B0GATCGN_%3DdwoQ%40mail.gmail.com.

[Roman Shpount]

Do you know if Chrome on Android supports mDNS candidates?

As far as I know mDNS URLs are not supported by Chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=405925), but I was not sure if mDNS candidates are handled differently.

If mDNS candidates are not resolved by anything on Android this will have significant effect on local P2P connectivity.

If mDNS candidates are resolved by Chrome on Android, can you point out how exactly this is done? Is this done in browser code or is this delegated to the OS?

Thank You,

[Qingsi Wang]

The mDNS stack is currently not built into Chrome on Android. As a result it will also send out candidates with plain IPs, and this should work for most local P2P communications plus the peer-reflexive logic, if the peer ever signals mDNS candidates.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/1e975569-ab29-457e-ad09-5e6a831d8878%40googlegroups.com.

[Sean DuBois]

What will happen if the PeerConnection that supports mDNS candidates
is controlled. If the controlling Agent only gets mDNS candidates (and
does not support them) is there anything it can do?

Is there anything in ICE/libwebrtc where the controlled agent would be
sending traffic if the controlling Agent has sent nothing? Anything
that has authentication and would generate those PRFLX candidates.

thanks!

> To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CA%2Bm752Jq_hUAfx1wXp-5s2O%3DTbREGC_c2ZJ0PzN6cf7SBsaUeA%40mail.gmail.com.

[Qingsi Wang]

The role does not stop the controlled side doing connectivity checks. If the controlling side signals any reachable candidate to the controlled side, the controlled would do its due diligence in connectivity checks, including a check for the pair formed by its mDNS candidate and this reachable one from the controlling. The controlling would 1) learn a prflx candidate from the incoming check, 2) send a response, and 3) form a pair. 2) would help the controlled side establish its ICE connectivity. 3) would let the controlling side either schedule an ordinary check or a triggered check. If this check succeeds, it then establishes the ICE connectivity on the controlling side. The 4-way handshake completes. In addition, the learnt prflx candidate would not prevent the controlling side from nominating a pair formed with it.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CA%2Bb7xQt143Y%3DqFFr08Pm8vyGodXX-%3D87Qg1K9Y9%2Bve2gfG0J_g%40mail.gmail.com.

[Roman Shpount]

Hi Qingsi,

Is mDNS resolution for ICE candidate on desktop is build-in the Chrome browser or is this being passed to the OS?

Thank You,

To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

[Qingsi Wang]

Hi Roman, I think the resolution on desktop uses the stack built into Chrome.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/9b82c4ea-ebc0-4604-8817-bef7b038394c%40googlegroups.com.

[eric littley]

Justin, our software is used in security surveillance camera networks (its a VMS). A common use case for our software is transmitting video across local subnets (for example: a school system in which the video surveillance network is separated from the administration network). It appears that, in many cases, mDNS resolution does not work across subnets without extra network configuration. The permission API Qingsi has linked looks like it might be the right path forward for us (I need to review it more). It looks like a pull request has been opened for this but has been marked as "Virtual Interim" (not sure what that means exactly). Does this look like something that would be added in the near future?

On Friday, 16 August 2019 00:01:28 UTC-4, Justin Uberti wrote:

Eric, your application (and all client-to-server applications) should be unaffected by this change, assuming you don't malfunction when receiving mDNS candidates (you can simply ignore them).

We explicitly recommend against asking for gUM permission to bypass the mDNS feature, as it should not be necessary, and is pretty weird for the user, as you point out.

On Thu, Aug 15, 2019 at 10:09 AM 'Qingsi Wang' via discuss-webrtc <discuss...@googlegroups.com> wrote:

For the permission API, there is an ongoing discussion on direct connections: https://github.com/w3c/webrtc-pc/pull/2175#issue-271288320.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/c854741c-91ee-4554-911d-1f13c5b852f9%40googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CA%2Bm752J1%2BF6wq%3DK%3Dfycc6acOM%3D88y4XKL3v9B0GATCGN_%3DdwoQ%40mail.gmail.com.

[Justin Uberti]

I can't say exactly when that permission might come to Chrome, so I wouldn't count on that as a near-term solution.

For your application, are both sides of the connection Chrome instances? If so, are you able to configure them using Chrome enterprise policies?

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/514fd07c-f807-493b-8e17-2da1f2000c68%40googlegroups.com.

[Qingsi Wang]

Update on the rollout

This technique is currently fully enabled by default for Canary/Dev/Beta channels, and for 95% of Chrome users in the Stable channel, including M75 and above. The impact to the connection rate is continuing to improve from our peer-to-peer connection analysis during the rollout, and we will continue to investigate improvements to further minimize the downsides.

[Arun Ganeshan]

After upgrading to version 78 we are seeing issues with automation .

In version 77 we run our automation . When using fake media mdns was disabled we were guessing it was because of the fakeMEdia but looks like in chrome 78 fake media is not assumed as real streams . MDNS is enabled irrespective of getting fake media 

TO fix this we tried to set `'--disable-webrtc-hide-local-ips-with-mdns' via chromedrivers but for some reason still the value in default and the enabled. Any help on how to make it work with the automation  ? And will mdns be enabled irrespective of the getUserMedia in future ?

Regards,

Arun
CISCO

[Qingsi Wang]

Hi Arun,

Could you please try path/to/chrome --disable-field-trial-config --disable-features=WebRtcHideLocalIpsWithMdns? This should turn off the mDNS feature in the launched Chrome session.

> will mdns be enabled irrespective of the getUserMedia in future

We don't see a good reason to always enable the mDNS feature, especially with the user consent via getUserMedia.

Best,

Qingsi

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/59fcf8fa-039e-43b0-8df9-2986f74af986%40googlegroups.com.

[Qingsi Wang]

Only --disable-features=WebRtcHideLocalIpsWithMdns should be sufficient for M78 and above.

[Shahar Mor]

Was there any consideration of using encryption to encode the private IP instead of using mDNS?

For example, peer1 could encrypt its IP using peer2's public key, so only peer2 can decrypt it for using it within WebRTC, without exposing it to the JS level.

The public keys can be transferred as part of the offer/answer.

Wouldn't that solve the issue of hiding the IP and also work around the issues with mDNS not being supported?

Is that something that can still be done? I guess it will probably take time to add to the spec, but is it generally feasible?

[Harald Alvestrand]

Since candidate exchange occurs prior to DTLS setup, the two ends don't have a shared key known to the browser while encoding candidates.

So a solution based on encrypting IP addresses would have to involve key exchange using some other mechanism - and since the address harvesting we're trying to prevent is done by the Javascript, any solution exchanging keys via Javascript is infeasible.

It's possible that it could be made to work using some other key exchange mechanism, but for many scenarios, it seems strictly more complicated than supporting mDNS.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/9460a6bc-caa4-4a6a-987f-bd4ef4cb7695%40googlegroups.com.

[Dubois, Sean]

Hey,

Why would something like DH not be possible?

 

Javascript can be assumed to be hostile. The WebRTC engine just gives you a candidate string and a public key (and waits to get a public key from the other side)

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVHgcL%2BVQQfbN8vGmq-3RXgUXSoG3xwhKkEiQ7XH8G0_Ng%40mail.gmail.com.

[Sean DuBois]

I do get it being more complicated though.

I have just been getting lots of reports from Pion users that mDNS is causing issues, but everyone loves to complain about new things :) 

* Some are hitting issues because Multicast is disabled/different subnets

* Other are frustrated about the increase in traffic they are seeing from the queries, and concerned about information leakage happening from that. Don't know how realistic that is though.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/9460a6bc-caa4-4a6a-987f-bd4ef4cb7695%40googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

[Justin Uberti]

DH isn't possible because the JS can simply MITM the DH to break the encryption. I don't think there's any trust that we can bootstrap from.

Regarding traffic increases, please file a crbug on this and we can look into it.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/9460a6bc-caa4-4a6a-987f-bd4ef4cb7695%40googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVHgcL%2BVQQfbN8vGmq-3RXgUXSoG3xwhKkEiQ7XH8G0_Ng%40mail.gmail.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/829653f3-552f-47ec-8a7c-8ad32094b508%40googlegroups.com.

[Dubois, Sean]

I don’t believe a MITM is the issue though (TLS would have the same problems then) However my idea doesn’t work. This only keeps the signaling safe, but an attacker could just run a WebRTC server and decrypt them there. This only fixes leaking IPs when browsers only.

 

re: crbug no worries! I don’t think there is a solution, the queries need to happen so people just need to deal with it 😊

 

thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOJ7v-1f4UCuaMK8OnykzZUBk9Ww3RVC2b92cQXjekrb0Z_WqA%40mail.gmail.com.

[Justin Uberti]

FWIW, TLS can bootstrap trust from the server certificate.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8C57B074-FFFD-4708-9AB1-88F281587F6A%40pion.ly.

[Qingsi Wang]

> This only keeps the signaling safe, but an attacker could just run a WebRTC server and decrypt them there. This only fixes leaking IPs when browsers only.

Yeah, the server and the remote peer could collude under the application control.

On Mon, Sep 30, 2019 at 5:22 PM Dubois, Sean <se...@pion.ly> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8C57B074-FFFD-4708-9AB1-88F281587F6A%40pion.ly.

[Nikolay Rodionov]

Hello Justin,

Do you know what Chrome Enterprise policy would disable the mDNS feature? I can't find it in the list here, and for us it would be of a great help - we have a P2P E-CDN solution that helps Enterprise users to avoid congesting their internal networks during their internal video broadcasts. Until a permission API comes, having at least the possibility to deactivate it in Chrome Enterprise would be great.

Le vendredi 30 août 2019 20:29:35 UTC+2, Justin Uberti a écrit :

I can't say exactly when that permission might come to Chrome, so I wouldn't count on that as a near-term solution.

For your application, are both sides of the connection Chrome instances? If so, are you able to configure them using Chrome enterprise policies?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/514fd07c-f807-493b-8e17-2da1f2000c68%40googlegroups.com.

[Justin Uberti]

Understood, will be announcing our plan for this shortly.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/b6960bd9-67d0-41f5-a723-eeb9795c53b1%40googlegroups.com.

[Qingsi Wang]

Chrome policy to manage the mDNS feature in enterprise deployments

As part of our continuing effort to minimize disruption from the mDNS obfuscation technique, we are preparing to add a new Chrome enterprise policy (tentatively named “WebRtcLocalIPsAllowedUrls”) to control whether the exposure of local IP addresses is allowed in ICE candidates for specific origins in managed networks. The mDNS obfuscation will be effective for an origin only if this new policy does not whitelist the origin for IP exposure and the feature flag (chrome://flags/#enable-webrtc-hide-local-ips-with-mdns) is enabled.

When available, this new policy can be deployed by enterprises the same way as existing Chrome policies. Please refer to Chrome Browser Deployment Guide on Policies and Templates for the procedure on different platforms.

As an interim solution, we are going to disable the mDNS feature for Chrome Enterprise endpoints until the new policy is available in Chrome stable, which we target to arrive in Chrome 79 in early December.

[Roman Shpount]

Are there any plans to add a permission dialog to allow application to expose the private IP without asking for GetUserMedia?

Thank You,

[Justin Uberti]

It is being discussed, but it is not yet clear that a new permission is the best solution; we hope that the Chrome enterprise policy route will avoid pushing this complexity onto users.

On Tue, Oct 15, 2019 at 11:50 AM Roman Shpount <rshp...@gmail.com> wrote:

Are there any plans to add a permission dialog to allow application to expose the private IP without asking for GetUserMedia?

Thank You,

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6d070b38-40b4-476d-a166-6d6cc61a78b5%40googlegroups.com.