Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities
Iñaki Baz Castillo <ibc@aliax.net> Fri, 26 May 2017 12:53 UTC
Return-Path: <ibc@aliax.net>
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 5D9F61294DC for <rtcweb@ietfa.amsl.com>; Fri, 26 May 2017 05:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 ghZPb-V3a3Dj for <rtcweb@ietfa.amsl.com>; Fri, 26 May 2017 05:53:17 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 DA91812426E for <rtcweb@ietf.org>; Fri, 26 May 2017 05:53:16 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id b84so128017042wmh.0 for <rtcweb@ietf.org>; Fri, 26 May 2017 05:53:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y7PNPkrBS6sra5sjkXVYb6RG2d3/VZfKxQt0EqqvKvg=; b=leF2EEPeAr4C+JTG9tNmnuQDLDmGOthgDVBrkIynPxVM3Ng2IWDO36melP8LlVKQMq nBzZefwzAS6OVxaUOroOoTBz+z60Sc2V4SJ7nQnkrEzpi2WVJAabQ1wgoAtharRmWa9J wQLCejVLaYsIchMESlyqv9avDodwHoiq5bKdFZJMgkDoEVjhvO6m5rhk0I7GdGBomS5C E2y4JXaxw1HgQKVYFvZg5t3VgPuMrNPNj19O9O3v6pLEtJ/+zw47od+vMENjVXIylccF ctMsf0Zp6gqcOXimdJhtMGDwPkqZyTpRHGbyr8fCIgLNn6IFQjgZncEKYirrLcw2L2jP Upwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y7PNPkrBS6sra5sjkXVYb6RG2d3/VZfKxQt0EqqvKvg=; b=no/xLa8eD07rNl284HnxAzx70awZkqjWcduqvbn6nzd/BsV94FHIZ30NEGg5Hac2DB kfDlHRCXHUOT1IXKlRzdEbyvinAXpxKMEa99FI4RVG41Z71B7zL8ZvI7xfNEYHeKMj/C csh1SJMPpqsVIPmh47m09TigzKLBdpmhHTFuvbJSs5xid1tQ9+jswtalrKAWi31PP2BW EqNsXFUHo0EyKq8iZ7cfVhLDNBIBxT1YoQq0tiVmKO1FtyWYf8YWKUGfOZgjOAaohOwJ Q7RH+NizBU4Ne9eDzK6vdlECD1GBNrSuqHsxBvjIOAH5FcqA5xe3iaz+upvMpmtQE5xE od4Q==
X-Gm-Message-State: AODbwcDyGHk4XqZPFeqan0jxVMPTwcCaTzXISx47HRNM+l1aIKg8Ln3A zM9GF8xmlf8KTACxlUvZXJIW94JhEEIP
X-Received: by 10.80.165.23 with SMTP id y23mr2270968edb.64.1495803195385; Fri, 26 May 2017 05:53:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.146.136 with HTTP; Fri, 26 May 2017 05:53:14 -0700 (PDT)
Received: by 10.80.146.136 with HTTP; Fri, 26 May 2017 05:53:14 -0700 (PDT)
In-Reply-To: <CABghAMgz+R=nXVCRKrxsoDQicR-CVaNdWq64HegCLHpOf1kHPQ@mail.gmail.com>
References: <CABghAMiVwwDY0jE72XZRv2WhaEF53WnnFgjQu953eGqtR07vUQ@mail.gmail.com> <CAOJ7v-1Jk7Vqi1j_L7JFp4046AfzwTAwvbWF9hKWQwkZuJWnrA@mail.gmail.com> <CABghAMgz+R=nXVCRKrxsoDQicR-CVaNdWq64HegCLHpOf1kHPQ@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Fri, 26 May 2017 14:53:14 +0200
Message-ID: <CALiegfnTwtMJPnOkc=u9yteJO5pZQstgkUZ9S-zp_Hp3O4hEQQ@mail.gmail.com>
To: Colin Gallagher <colingallagher.rpcv@gmail.com>
Cc: Justin Uberti <juberti@google.com>, rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="f403045c1c801d801105506cd253"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/j8znfhhnLm_wAiDduHZ3VvaZTs4>
Subject: Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 26 May 2017 12:53:20 -0000
It seems to me that you don't want WebRTC. For WebRTC to work IPs must be exposed. So not sure what you are asking for. El 26/5/2017 9:58, "Colin Gallagher" <colingallagher.rpcv@gmail.com> escribió: > Justin, > > It's my understanding that various browsers have made an attempt to > conform to the recommendations in the document that you have provided > <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03>. > Unfortunately, at least in Firefox (the most current version) so far as I > can tell, there is a serious vulnerability. To be more specific, the > problem was observed in my operating system with my current browser, which > is Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit). The browser does not > address the WebRTC problems by default. > > The stackexchange page that I cited originally is actually not outdated in > the sense that its method of measuring whether or not the WebRTC > vulnerability exists on a given system is still intact and works. The > stackexchange page suggests two pages to determine whether or not you have > leakage / WebRTC related vulnerability. These pages are: > > 1) Browser leaks test for WebRTC https://browserleaks.com/webrtc > 2) IP Leaks https://ipleak.net/ > > Currently for Browser leaks test for WebRTC (due to that I have again > changed settings in my system so that I will not have to be exposed to this > vulnerability) the settings show up on the page as: > RTCPeerConnection×False > RTCDataChannel×False > ORTC (Microsoft Edge)×False (for example....) > > And under IP leaks, it currently shows "No leak, RTCPeerConnection not > available." > > *That is because:* > > (A) I have (again) changed my settings in about:config back to the > following > > > 1. I typed *about:config* in the address bar > 2. I found the setting *media.peerconnection.enabled* > 3. I set it to *false (it was previously set at true, so as to allow > WebRTC to work, but this exposed information which I would not have wanted > to be exposed)* > > (B) And I also have changed my settings back to the following > > in the WebRTC 0.1.3 extension for Firefox I have set it to no longer > expose my real IP address as well as no longer allowing the following: > > a. navigator.getUserMedia > b. window.MediaStreamTrack > c. window.RTCPeerConnection > d. window.RTCSessionDescription > > To be clear, *these mitigations that I have employed above would be > unnecessary if WebRTC had not been designed in such a manner that it so > clearly exposes so much user information.* > > In the document you provided > <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03>, titled > "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling-03," > it is stated that: > > *"1. If the client is behind a NAT, the client's private IP addresses, > typically [RFC1918 <https://tools.ietf.org/html/rfc1918>] addresses, can be > learned. * > > > > * 2. If the client tries to hide its physical location through a VPN, > and the VPN and local OS support routing over multiple interfaces > (i.e., a "split-tunnel" VPN), WebRTC will discover the public > address for the VPN as well as the ISP public address that the > VPN runs over. > > 3. If the client is behind a proxy (a client-configured "classical > application proxy", as defined in [RFC1919], Section 3 <https://tools.ietf.org/html/rfc1919#section-3>), but > direct access to the Internet is also supported, WebRTC's STUN > [RFC5389 <https://tools.ietf.org/html/rfc5389>]checks will bypass the proxy and reveal the public > address of the client."* > > All of these are obvious vulnerabilities and serious problems (not only #2 as the document suggests). > > It is stated in the document that, > > > > *"we want to avoid solutions that disable WebRTC or make it harder to use."* > > Yet, so far as my observations of WebRTC in the current version of Firefox with Ubuntu 16.10 have shown, > > there appears to be no other choice other than to disable WebRTC because its use completely compromises > > privacy and thus makes all other aspects of your system more difficult generally. > > It is stated in the document you cited that the goals here are to "Provide a privacy-friendly default behavior which strikes the > right balance between privacy and media performance for most users > and use cases. (and) For users who care more about one versus the other, provide a > means to customize the experience." > > This has clearlly not been accomplished in the context of Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit). > > Hence my request for a new security review of WebRTC based on observed vulnerabilities. > > > > > On Thu, May 25, 2017 at 1:04 PM, Justin Uberti <juberti@google.com> wrote: > >> Colin, >> >> This is an important topic, and the group has reviewed this situation in >> detail. The results have been written up in this document >> <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03>, and to >> my knowledge most browsers that support WebRTC currently conform to its >> recommendations. >> >> However, I'm not totally clear on your specific technical concern. You >> linked to an (now outdated) stackexchange page, but could you provide more >> detail about the specific situation you are concerned about? >> >> Justin >> >> On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher < >> colingallagher.rpcv@gmail.com> wrote: >> >>> To: IETF RTCWeb WG >>> >>> From: Colin Gallagher >>> https://www.linkedin.com/in/colingallagher >>> https://lifeboat.com/ex/bios.colin.gallagher >>> >>> Request for New Security Review of WebRTC based on observed >>> vulnerabilities in certain examples >>> >>> Dear IETF RTCWeb WG, >>> >>> This request relates to WebRTC. The WebRTC is in draft at >>> https://w3c.github.io/webrtc-pc/ and is described also at >>> https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API# >>> WebRTC_interfaces >>> >>> There are certain examples where the use of WebRTC has presented >>> security vulnerabilities. While not exhaustive, there are two I wanted to >>> mention that I had been exposed to recently. >>> >>> 1) The use of a video conferencing service which relies upon WebRTC >>> (that is a well established service) >>> 2) The examination of a browser based WebRTC version of a decentralized >>> exchange (that is currently under development) >>> >>> In both cases the security vulnerability which is described below was >>> the result of the use of WebRTC. >>> >>> The problem under consideration is as follows: >>> >>> As per the first example (the video conferencing service), recently I >>> came upon a vendor who shall remain unnamed who uses WebRTC as the backbone >>> for their video conferencing service. As a result, I found I was unable to >>> access the service in question without disabling some security settings >>> which I would have preferred to leave intact. >>> >>> My system is (based on what the aforementioned service detects) >>> Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 >>> Firefox/53.0. This is Ubuntu 16.10 64-bit with Firefox 53.0.2. >>> >>> However, quite some *long* while back I disabled WebRTC because of the >>> security vulnerability (described in part here on information security >>> stack exchange >>> <https://security.stackexchange.com/questions/82129/what-is-webrtc-and-how-can-i-protect-myself-against-leaking-information-that-doe>). >>> So as to mitigate this vulnerability, I changed settings in Firefox as >>> follows: >>> >>> >>> 1. I typed *about:config* in the address bar >>> 2. I found the setting *media.peerconnection.enabled* >>> 3. I set it to *false* >>> >>> Unfortunately, this setting does not allow Firefox to work with the >>> video conferencing service in question, which relies entirely on WebRTC. >>> >>> So I had to go back in and change the media.peerconnection.enabled >>> setting to *true* in Firefox in order to get it to work with the >>> service in question. While this enabled me to conference with teams that >>> desire to use the video conferencing service that rely wholly upon WebRTC, >>> it concerns me because of the security vulnerability. >>> >>> One suggested mitigation was having NoScript, but using NoScript was not >>> helpful (you generally need to disable it for the site you are viewing that >>> relies upon WebRTC, in order to obtain any functionality, and whether >>> NoScript is off or on, WebRTC still causes the vulnerability of leaking >>> information as previously described). >>> >>> Furthermore, upon reload of the browser, even after setting >>> media.peerconnection.enabled to *true*, the video conferencing service >>> wouldn't work until I installed the WebRTC 0.1.3 extension for Firefox and >>> set it to expose my real IP address as well as allowing the following: >>> >>> a. navigator.getUserMedia >>> b. window.MediaStreamTrack >>> c. window.RTCPeerConnection >>> d. window.RTCSessionDescription >>> >>> That seemed to me to be a direct consequence of the persistent and >>> ongoing security vulnerability in WebRTC. >>> >>> I contacted the video conferencing service provider and their solution >>> was simply to state that "If the peer to peer connection is of concern, you >>> can utilize our premium version which will route traffic through a >>> forwarding server with in our environment that handles the processing of >>> the video and sound of all users in the conference and send it to each user >>> individually rather than using a peer to peer connection." In other words, >>> they expect that people should have to pay in order to mitigate this >>> WebRTC security vulnerability >>> <https://security.stackexchange.com/questions/82129/what-is-webrtc-and-how-can-i-protect-myself-against-leaking-information-that-doe>, >>> because they are unwilling to design to protect all users from it. >>> >>> In a similar fashion, in the second example of the browser based WebRTC >>> version of a decentralized exchange, the user's financial information is >>> periodically exposed as a result of the information leakage which is >>> presently caused by WebRTC. (Fortunately, this browser based WebRTC >>> decentralized exchange is under development and is not currently open to >>> actual usage.) >>> >>> Although undoubtedly this has been discussed here before, I am asking >>> that WebRTC security issues be reconsidered and that a new security review >>> be done to ameliorate or eliminate this problem in terms of WebRTC leaking >>> this information. It is my view that WebRTC should be further designed and >>> developed with an eye to mitigating this serious problem, so that users of >>> services which might rely partially or wholly upon WebRTC would not have to >>> be concerned about such information leakage. >>> >>> Respectfully, >>> Colin Gallagher >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > >
- [rtcweb] Request for New Security Review of WebRT… Colin Gallagher
- Re: [rtcweb] Request for New Security Review of W… Justin Uberti
- Re: [rtcweb] Request for New Security Review of W… Colin Gallagher
- Re: [rtcweb] Request for New Security Review of W… Eric Rescorla
- Re: [rtcweb] Request for New Security Review of W… Iñaki Baz Castillo
- Re: [rtcweb] Request for New Security Review of W… Colin Gallagher
- Re: [rtcweb] Request for New Security Review of W… Justin Uberti
- Re: [rtcweb] Request for New Security Review of W… Colin Gallagher
- Re: [rtcweb] Request for New Security Review of W… Justin Uberti
- Re: [rtcweb] Request for New Security Review of W… Bernard Aboba
- Re: [rtcweb] Request for New Security Review of W… Bernard Aboba