Re: [secdir] WebRTC

Eric Rescorla <ekr@rtfm.com> Tue, 10 April 2012 15:11 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A266511E810B for <secdir@ietfa.amsl.com>; Tue, 10 Apr 2012 08:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.471
X-Spam-Level:
X-Spam-Status: No, score=-100.471 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, TVD_SPACED_SUBJECT_WORD3=2.412, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQqBhZqwpVMy for <secdir@ietfa.amsl.com>; Tue, 10 Apr 2012 08:11:09 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AECD611E8108 for <secdir@ietf.org>; Tue, 10 Apr 2012 08:11:09 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so3611598vbb.31 for <secdir@ietf.org>; Tue, 10 Apr 2012 08:11:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=No99xpMA9XmCmOJireNU8zJDSGjbQbFdiEimOyKOQ6s=; b=mVXNjElUywQczeS6qa/lWZ9gigFarB0Cppgj63k0UJyJ5fG/xjLnaFQVVnyzHbQpMD Pd6oj/wQMCKD3EBK0Ni7ml94G5GsH8+emke2Z2Vncp5feL7pmYJNHtrP/fTlpSLF9FJh N4QwFb5XYsiuOZzKL6ogyKdLS48R7JZNypusHWdt3nlcvlM3PMxyS/qa0kZM/Icjkp2m hEPN9fVP9SICXvFGF6kDd1bskBEIIm1SFKWUaQ+RJjyr0qmd72bfqfvXlXGdB9+jXq+z dpMqfC5EcELiCP8NC++QGtpUIDLXM8+L/t3m8W4oM8KSxp5RYmGqnzAvLhl6pp8s1/lA R6Uw==
Received: by 10.52.69.100 with SMTP id d4mr5052337vdu.9.1334070669233; Tue, 10 Apr 2012 08:11:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.19.233 with HTTP; Tue, 10 Apr 2012 08:10:28 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <5.1.0.14.2.20120408115646.03793228@efes.iucc.ac.il>
References: <5.1.0.14.2.20120408115646.03793228@efes.iucc.ac.il>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 10 Apr 2012 08:10:28 -0700
Message-ID: <CABcZeBNNx5nTP+GWDHgupUc4dDBhbfOJ5SjUtsUeTgG88QU2TQ@mail.gmail.com>
To: Hank Nussbacher <hank@efes.iucc.ac.il>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmuNbRiZ/orRAUVJqM5l0iO5QhCSTZ7oykTj17Ex4Il+N34eZCTxnyvQXgMiCV20/j6KC9O
Cc: secdir@ietf.org
Subject: Re: [secdir] WebRTC
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 15:11:10 -0000

On Sun, Apr 8, 2012 at 2:11 AM, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
> Dear Security Area people,
>
> Quick intro:
>
> WebRTC http://www.webrtc.org/ is a free, open project that enables web
> browsers with Real-Time Communications (RTC) capabilities via simple
> Javascript APIs.   It is supported by Google, Mozilla and Opera.  One can
> test it already in Chrome. Basically, it is meant to be a Skype replacement
> technology (no app to download - all built-in to the browser).  But there
> are many other ideas that can be used here with this technology.
>
> Now we get to the security part.  As stated here:
> http://www.webrtc.org/blog/webrtcnowavailableinthechromedevchannel
> one has to specifically enable "--enable-media-stream" in order to get it to
> work. That is now, but the future plan is to have this "on" by default in FF
> and Chrome by the end of 2012.
>
> So what does the IETF have to say:
>
> Security Considerations for RTC-Web
> http://tools.ietf.org/html/draft-ietf-rtcweb-security-01
> which caused:
> RTCWEB Security Architecture
> http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01
> Section 5.2:
> "Clients MAY permit the formation of data channels without any direct user
> approval."
>
> I can just see new apps all over the place using this technology opening a
> huge can of worms for data stealing from the PC running the app that did NOT
> ask permission for the formation of a data channel without the direct user's
> permission.  This is similar in concept to ActiveX:
> http://en.wikipedia.org/wiki/ActiveX
> "This made the web "richer" but provoked objections (since such controls ran
> only on Windows) and security risks (especially given the lack of user
> intervention). Microsoft subsequently introduced security measures to make
> browsing including ActiveX safer[6] . For example:
>
>    digital signing of installation packages (Cabinet files and executables)
>    controls must explicitly declare themselves safe for scripting
>    increasingly stringent default security settings
>    Internet Explorer maintains a blacklist of bad controls"
>
> Microsoft didn't envision the security issues of a "lack of user
> intervention" and it took them 3 years to add the appropriate knobs to make
> ActiveX more secure.
>
> I am not involved in WebRTC or the IETF group - I only found out about this
> incidentally.  I raise this issue to you guys and leave it the Security Area
> to decide whether section 5 needs to be changed or not.


FWIW, I am the person who wrote the text in question and though Hank
doesn't say so he privately contacted me and the RTCWEB chairs, and
what I told him is that the specific feature he is complaining about, the
data channel, is simply a direct channel between the browsers in question.
Since that channel is created and controlled by JavaScript under control
of the Web site, that JS can just as easily tunnel data through the site
via WebSockets/XHR, etc. I.e., this is just an optimization that allows
a direct connection. Thus, requesting user consent for the use of this
feature isn't really helpful, since this feature doesn't introduce new
risks of data exfiltration. [0]

Obviously, I'd be more than willing to listen to any security analysis that
indicated that this was wrong, but the handwaving above about
ActiveX doesn't really add anything as far as I can tell.

-Ekr

[0] Note that there are risks in terms of cross-protocol attacks, and
thus we require a handshake to prevent them; see
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01#section-5.3

Similarly, we require user consent prior to transmitting data derived from
the camera and microphone because that data is not otherwise available
prior to these features.
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01#section-5.2