[rtcweb] Fwd: [discuss-webrtc] PSA: Private IP addresses exposed by WebRTC changing to mDNS hostnames
Justin Uberti <juberti@google.com> Tue, 13 August 2019 22:53 UTC
Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E501208FE for <rtcweb@ietfa.amsl.com>; Tue, 13 Aug 2019 15:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.79
X-Spam-Level:
X-Spam-Status: No, score=-14.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZspURdUQA6YE for <rtcweb@ietfa.amsl.com>; Tue, 13 Aug 2019 15:53:40 -0700 (PDT)
Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414861208FD for <rtcweb@ietf.org>; Tue, 13 Aug 2019 15:53:40 -0700 (PDT)
Received: by mail-vk1-xa35.google.com with SMTP id b64so21807987vke.13 for <rtcweb@ietf.org>; Tue, 13 Aug 2019 15:53:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8wX7bSTxWQ474CMS3UNSzFqsobZ5AF08feINB0UJgyU=; b=IVxOrhJetQYNsqLM8bcUUHpB1qeZHsLiRZkoRptJZX4bl5lOpAuK89vk5iKgIBYC1g uC2wjhUdGCGTrDNFBnyZg72zBrxZo8tVCoX7PNUT+VmdrtKS3AAOU3x8kTTrjIRWRdZK UyJG573xEWq/bUB329y7wr3uETYdWFAHBAC8Nsz4+h2xVH+pjTE+YBVaUtj6MLRyNI1j MMqMip/TPCtDdkSnSY4I/tPT9mntYRn0xAOtyHWVVM5+jfumRP6opXFA4+hO8ukQGwY1 iSZolGnc1TFcb+hELu8kxBLoVbYYqE6OKsgf1zeRr9amjbWy2ErzU3iHZ/Oo8ZrSfVJk ABDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8wX7bSTxWQ474CMS3UNSzFqsobZ5AF08feINB0UJgyU=; b=OyVSovkiCzSd9yzL6rjYNcT6hw+Mf5pom7TixH3ei+XvnOzmb3kxN/Cn2XYcqpheSD FYcESS1Ic14EliVAM1WMr4dYHdlKAgXQvf8AFiyiTb0+RygD2sF5sY+6DK3hb6uSyxeJ PQEsHf0VsxjknyI2jQYX9HWGV1QGZ+5wWN/EXfsIM61wQw51Pn8HFWb7hhCayVCqpVeu E+WU//BJs6gRmes/hLChlTh1oPqubNfd23Fe+0gMAdhvZdgNMhwjbSWtG/OwV8sF9tuZ ySCQjzJxsXrD8SH4vr9jeUErl3qYCgy7FhzMMOPniiRW7P5xU4szWqNoLXVUWHMAjCij HOWA==
X-Gm-Message-State: APjAAAVKgO8GPplKTpbVtrFc0C49XZl1MRiYl3hCFezpQb1iRv9x1sIm wAFvdPm0GGF5XkzA+4MuNhNSnhlJTg+cbBD7ry5jg2jUnfY=
X-Google-Smtp-Source: APXvYqzIe8NotxfviiCQG45OKUstAykSDtNQRhfimel5Bx5USCZVCu56v3At23IQgC1g482VbJlJraxTpl9uwDFpNWc=
X-Received: by 2002:a1f:a44c:: with SMTP id n73mr6447248vke.76.1565736818464; Tue, 13 Aug 2019 15:53:38 -0700 (PDT)
MIME-Version: 1.0
References: <1d124cbb-f9d3-4ba4-9bb0-0099cf3e7797@googlegroups.com>
In-Reply-To: <1d124cbb-f9d3-4ba4-9bb0-0099cf3e7797@googlegroups.com>
From: Justin Uberti <juberti@google.com>
Date: Tue, 13 Aug 2019 15:53:25 -0700
Message-ID: <CAOJ7v-0s6HC2YiKWXj1K_nXmx=gvrutPPYR4fOm7Gy0VJFJaSQ@mail.gmail.com>
To: RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e0cb710590078251"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/vpx90dpIzyaEzYZ1PYxMLSYwT5c>
Subject: [rtcweb] Fwd: [discuss-webrtc] PSA: Private IP addresses exposed by WebRTC changing to mDNS hostnames
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Aug 2019 22:53:45 -0000
FYI, empirical results of deploying mDNS at scale. TL;DR: downside is low, ~2% impact to data channel connection rate between Chrome instances, somewhat higher when connecting to non-Chrome, likely due to issues handling mDNS candidates, which should be temporary. In the absence of any showstopper feedback, planning to roll this out fully later this month. ---------- Forwarded message --------- From: 'Qingsi Wang' via discuss-webrtc <discuss-webrtc@googlegroups.com> Date: Tue, Aug 13, 2019 at 2:33 PM Subject: [discuss-webrtc] PSA: Private IP addresses exposed by WebRTC changing to mDNS hostnames To: discuss-webrtc <discuss-webrtc@googlegroups.com> 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 <https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-03>. We have also experimentally verified the efficacy of the mDNS technique, following the initial announcement of this feature in January <https://groups.google.com/forum/#!msg/discuss-webrtc/4Yggl6ZzqZk/nV24XkXXAQAJ> . 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 <https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev> and discuss-webrtc <https://groups.google.com/forum/#!forum/discuss-webrtc> to follow PSAs and other important announcements - Systematically test in Chrome Canary <https://www.google.com/chrome/canary/> to see how your application behaves with upcoming Chrome changes - Provide feedback on the relevant bugs/forum threads -- --- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/1d124cbb-f9d3-4ba4-9bb0-0099cf3e7797%40googlegroups.com <https://groups.google.com/d/msgid/discuss-webrtc/1d124cbb-f9d3-4ba4-9bb0-0099cf3e7797%40googlegroups.com?utm_medium=email&utm_source=footer> .
- [rtcweb] Fwd: [discuss-webrtc] PSA: Private IP ad… Justin Uberti
- Re: [rtcweb] Fwd: [discuss-webrtc] PSA: Private I… Roman Shpount
- Re: [rtcweb] Fwd: [discuss-webrtc] PSA: Private I… Justin Uberti