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

[Richard Barnes <[e-mail]>]

On Thu, Jun 20, 2013 at 9:11 PM, Hadriel Kaplan
<[e-mail]>wrote:

>
> On Jun 20, 2013, at 6:24 PM, Richard Barnes <[e-mail]> wrote:
>
> > It's more secure in the sense that it makes a malicious web server do
> more work: It forces the web server to act as the PBX and terminate DTLS,
> instead of just pulling the key out of the SDP and decrypting media.  So
> the browser user is (incrementally) better protected against the malicious
> web server.
>
> Uh huh.  So, like, the only people who could afford to do that and would
> want to do that would be criminals, drug dealers, mobsters, casinos, news
> organizations, political parties, and governments then?  Phew!  And here I
> was being worried.
>
> But wait a minute... I was under the distinct impression from people in
> this group that doing DTLS-SRTP termination on the gateways was no big deal
> for "modern" servers... that it was so cheap and trivial that your cell
> phone could do it for umpteen streams... that we shouldn't be worried about
> the overhead of it whatsoever.  Surely you can't be telling me that it's at
> all difficult for someone running a malicious web site to do it?!?
> ;)


Look, I said it was "incremental", right?  :)  At the very least, it keeps
out the script kiddies.   If you compromise my web site, you have to have
some other resources to compromise the users' voice sessions; you can't
just do it from the web server you've pwned.  You might not be up against a
tiger every time; sometimes, it's just a house cat.



> > 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.

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."

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.

--Richard



> > It's more secure in the sense that SDES has no end-to-end authentication
> [1], so implementing SDES creates bid-down attacks.  If an attacker can't
> get a valid identity, he just claims not to support DTLS-SRTP.  So the
> browser user is better protected against bid-down attacks by remote users
> (e.g., the malicious web server's PBX).
>
> This is just another symptom of talking to a malicious web server, and
> basically a repeat of the argument that DTLS-EKT is "more secure" because a
> malicious web server has to do a little more work to steal everything.
>  It's like being stuck in a big cage with a man-eating lion and deciding to
> run around in circles in the hopes the lion isn't going to chase you.  If
> he's hungry at all, you're dead; chasing you down is not sufficiently more
> difficult for him to stay hungry.
>
> -hadriel
>
>