[rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities
Colin Gallagher <colingallagher.rpcv@gmail.com> Thu, 25 May 2017 00:35 UTC
Return-Path: <colingallagher.rpcv@gmail.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 BC294128C81 for <rtcweb@ietfa.amsl.com>; Wed, 24 May 2017 17:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.702
X-Spam-Level:
X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 MQJZYYQ9j2He for <rtcweb@ietfa.amsl.com>; Wed, 24 May 2017 17:35:18 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 499941200C5 for <rtcweb@ietf.org>; Wed, 24 May 2017 17:35:18 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id 9so150544935pfj.1 for <rtcweb@ietf.org>; Wed, 24 May 2017 17:35:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=8o4kvxad1K9qNe2bTokMhrq1YU2naaYLnqcMsx70F/c=; b=OItBjxXTAIqiqeO7pFvQevo9zGfkqXfI/DLBUh6QkOMXjx7nKajHxZqpFQp+4Ayqaz Z+Ina9QU2uXSuwsS5apLzH6wnEpMC91uAdFov/yakYWFuQf1Lt/gVOgRLEnPEMU9u5d9 V2XN1u+fVIR5Udn2lTNVCfX/3+mOQspG7/gZHjlq4s+CYe6EXd6I6P9eZt7crzCa6+lr BtJsjUz8ix+6W+QNYBIJMMzXUGAtgouGhLPcBd8rUB+RK3t2P/c9iZj2HFOXMg/nDA3p JPEJOFFny5cbNs1UH4kD81C9NNMCkcNKE4Ip/k9IAd3d4hXbt5SnbxbMoJKu71TwOrBp bP2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8o4kvxad1K9qNe2bTokMhrq1YU2naaYLnqcMsx70F/c=; b=YfhrLPM6f0gg29lJjXBOUWo1tr87bVlYBG1hVF9cvu+lOPB3F8RHsElWULJnOIb/dD XcH1YFjvAgiuiVSe7/hcITdxdCug4MK0TFE5x3VHDOW1Oqv+UaPvyQ1GCmeY5PSckCjt KTXjBLCUjjm+M3iRzbfmOjLm5xma17UZc4/ipQPIbonQhA3ADLhdFKw1tXHHRG+wC3z4 w8cRs8d+ts8bnKQPM3l7iBqWVq+pWhZJdpZRVXhqzgTOjAjR/BTxd9tt0dO7qxugkVLn 1XHXq8HcPWlCFzUFVQKKNPaXRlYD0Ku10aOevXPpMtRtY+Mmb46IsS2g3nVbCRBsesJ7 k2tA==
X-Gm-Message-State: AODbwcATNMKJ5GsuuVuaqOInu0MMUDu4hdLlHPtvRur4k6obrHxggBHo Imz2Ed3QuB/lkGSZVyR+ve5GoJo1b/HEAHM=
X-Received: by 10.99.160.17 with SMTP id r17mr29222509pge.95.1495672517687; Wed, 24 May 2017 17:35:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.166.111 with HTTP; Wed, 24 May 2017 17:35:17 -0700 (PDT)
From: Colin Gallagher <colingallagher.rpcv@gmail.com>
Date: Wed, 24 May 2017 17:35:17 -0700
Message-ID: <CABghAMiVwwDY0jE72XZRv2WhaEF53WnnFgjQu953eGqtR07vUQ@mail.gmail.com>
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="f403045e38a41e01a105504e6529"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/Ir7FfOFGqczHRxJQuWWK6-3vMHs>
Subject: [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: Thu, 25 May 2017 00:35:21 -0000
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] 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