Re: [rtcweb] No Interim on SDES at this juncture

Hadriel Kaplan <> Fri, 21 June 2013 02:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 613E521E80DF for <>; Thu, 20 Jun 2013 19:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.553
X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xstqsNwE0xMi for <>; Thu, 20 Jun 2013 19:58:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 738CD21E80F3 for <>; Thu, 20 Jun 2013 19:58:38 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5L2wXRx012047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 02:58:34 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id r5L2wWhc019156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 02:58:33 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id r5L2wWrO019148; Fri, 21 Jun 2013 02:58:32 GMT
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 19:58:32 -0700
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <>
In-Reply-To: <>
Date: Thu, 20 Jun 2013 22:58:33 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Richard Barnes <>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: []
Cc: "" <>
Subject: Re: [rtcweb] No Interim on SDES at this juncture
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Jun 2013 02:58:44 -0000

On Jun 20, 2013, at 10:14 PM, Richard Barnes <> wrote:

> > It's more secure in the sense that JS can't access the key, so an injected script can't grab the key and exfiltrate it.  So the browser user is better protected against XSS risks.
> This part I'd like to understand better.  Can you explain it?
> If a Browser cannot determine what server the JS being executed for WebRTC API calls/callbacks came from, or cannot tell if it came from one over HTTPS in particular, then using SDES might be a real problem.  I was under the impression browsers did know those things (or at least that they're theoretically supposed to, ignoring that  there are "bugs" here and there).
> As with many things in the web security model, the answer is "It's complicated".  The wikipedia article on XSS is pretty good.
> <>
> The upshot is that your typical web page gets cobbled together out of many pieces, often from different domains.  Scripts from multiple sources get imported into the overall security context of the page.  This composition can happen deliberately (e.g., mashups, JS libraries) or maliciously (XSS).  Let me provide an example of each:
> 1. Suppose I use jQuery to do pretty layout on my page.  There's nothing that actually constrains jQuery to only do layout.  If jQuery is out to get me, it could do something like overwrite window.PeerConnection, so that all of the page's WebRTC calls go through the jQuery library and are subject to its control.  So if the PeerConnection API exposes keys, jQuery can steal them.

We've talked about that one before I think.  If jQuery is out to get you, it's game over.  It's essentially equivalent to a malicious web-server, except of course that the operator of the web-server isn't intending to be malicious (which is an important distinction).  But again, not only does jQuery have access to information such as who you're talking to and when, it can also redirect your media to a gateway of its choosing to terminate the DTLS-SRTP and record it, by fiddling with the JSON/SDP stuff.

> 2. Suppose the overall page is loaded over HTTPS, but one of the scripts is loaded over HTTP.  Then the overall security context for the page is HTTPS, but if an attacker can hijack that HTTP load to introduce a script, in which case he can do the same bad stuff that jQuery could in the above example.  (This is why we have the following sentence in draft-ietf-rtcweb-security-arch: "It is RECOMMENDED that browsers which allow active mixed content nevertheless disable RTCWEB functionality in mixed content settings."

Right, and I think we've talked about that before too in the context of SDES: I think people were ok with limiting it further for SDES with a statement saying it must not be used in mixed content settings if one of the scripts came in on HTTP. (although I could be wrong on whether any consensus was reached on that point - it was a long time ago and I have a memory leak)

> There are mitigations to a lot of these sorts of issues, but some are still being developed.  And of course, there's no guarantee that a given site will follow all the best practices.  So it seems sensible to limit the damage that an injected script can do.

Right, and I'm hoping the Browser vendors can tell us if browsers can safely know whether all the JS running on a given page is from HTTPS or not, and not allow SDES if the JS is not all from (signed) HTTPS.  If not, then I agree that's another negative downside for SDES.  In fact I think it's even a problem for DTLS-SRTP.  I don't know why we'd be ok with using HTTP at all, if we're *truly* concerned about MitM and malicious 3rd party JS attacks.