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

[Hadriel Kaplan <[e-mail]>]

On Jun 20, 2013, at 10:14 PM, Richard Barnes <[e-mail]> 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.
> <http://en.wikipedia.org/wiki/Cross-site_scripting>
> 
> 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. 

-hadriel