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

[Anne van Kesteren]

On Tue, Aug 13, 2019 at 11:04 PM Qingsi Wang <qin...@chromium.org> wrote:
> 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.

I scanned through
https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates and
it does not really seem to stress that the mDNS hostname has to be
different for a.example and b.example. And section 3.1.1 does state
there is some kind of registry for these names. It seems that registry
needs to be adequately scoped as otherwise you create a
user-identifying token that can be used across origins. It also seems
that token should be unique for subsequent visits or at least whenever
cookies are cleared.

[Harald Alvestrand]

3.1.1 describes local operation only. There is no central registry.

The names are generated for each peerconnection; peerconnection are not persistable objects.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78gPjXan4XfG53dbWCukF3XFZkD--dEcZOLV3Nyjb%3DX5OA%40mail.gmail.com.

[Ashley Gullen]

Will this mean there is better interoperability with Safari clients? AFAIK Safari already supports mDNS for local connections in the latest version. Previously we've had to run a TURN server to ensure local Chrome/Safari connections can work because they couldn't work out a way to connect directly. It would be nice if this change now meant Chrome/Safari connections could be established directly locally.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/824025ae-c32f-4b11-9582-60ad2df5f7f3%40chromium.org.

[Justin Uberti]

Not sure this will improve things, since Safari should have been able to connect to the IP addresses previously provided by Chrome, but would be interested to hear if you see any improvement when this feature is enabled in Chrome (chrome://flags/#enable-webrtc-hide-local-ips-with-mdns)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73jGo96F6pZwOxEb0GWkLQKqdDuMqR_kZvoOTJg84CoTpw%40mail.gmail.com.

[PhistucK]

Was Chrome able to handle incoming signals with mDNS before this change?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOJ7v-3qCJY_S18J%2Baie75kduH92k8ajm5%2B7cnbgLY5GxQaoXw%40mail.gmail.com.

[Qingsi Wang]

Chrome M73 and above should be able to parse incoming mDNS candidates (as RTCIceCandidate) and send mDNS queries on the wire also when the feature is off. The switch only controls if we will generate local mDNS candidates and be able to respond to resolution queries. Below M73, we don't have the above capabilities.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/824025ae-c32f-4b11-9582-60ad2df5f7f3%40chromium.org.

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73jGo96F6pZwOxEb0GWkLQKqdDuMqR_kZvoOTJg84CoTpw%40mail.gmail.com.

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[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.

[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.