Re: [rtcweb] Resolving RTP/SDES question in Paris

[Hadriel Kaplan <[e-mail]>]

On Mar 20, 2012, at 9:40 AM, Roman Shpount wrote:

> Once again, I understand how this helps in case of HTTPS, but how would this help in case of WebRTC? Media description is carried in some sort of application defined protocol (can even be transmitted over an encrypted SCTP data channel or encrypted in javaScript), so monitoring proxy cannot reliably modify it. I understand how it can be allowed to fake the signature on modified SDP by inserting a certificate in the browser, but how would the proxy get to the SDP in the first place?

I was trying to follow this thread backwards from today, to try to grok how you got to the conclusion that an organization with strict media monitoring policies wouldn't be able to do so for WebRTC.  I think the above email is where I get disconnected form the train of thought.

If, as in another email you sent, an organization such as the military or jail or whatever controls its network such that they use the whitelist model of only authorized applications allowed our of their network, and everything goes through the HTTP proxy, then the above statement of:

> Media description is carried in some sort of application defined protocol (can even be transmitted over an encrypted SCTP data channel or encrypted in javaScript), so monitoring proxy cannot reliably modify it.

… makes no sense to me.

If you were preventing unknown applications, you would not allow unknown UDP or TCP destination ports to be used to get out of the network.  The HTTP Proxy has to (1) know your web application wants to use another set of ports, and (2) has to allow it.  Ergo, there can be no "encrypted SCTP data channel" that was not previously authorized; nor would encrypting SDP-type-info in Javascript help you one iota, because you won't be able to actually use it to send media, since the HTTP proxy is not opening new ports for you to reach the Internet.

So I don't understand what the problem is.  If you run a super-tight network like that and you *do not* want WebRTC to work because you can't monitor it, then by design it won't work.  If you run a super-tight network like that and you *do* want WebRTC to work, then you either have to be willing to install custom browsers/apps, or your HTTP Proxy has to be able to see the HTTP traffic and correctly parse the Javascript-passed data and be a media b2bua.  That's a really nasty set of constraints, especially trying to grok the javascript enough to be a media b2bua, and undoubtedly means it won't work for many WebRTC websites.  But that's arguably the right thing to happen - downloading javascript is akin to downloading a new application for each website, and again by definition this is a network that only wants to allow applications it wants to allow, so that's what it gets: per-application control, and thus requires per-application knowledge/support.  Anything your proxy doesn't understand doesn't work, but again that's kinda the point of a super-tight policy.

Personally, if I were running such an org, and I don't know if it's possible, but I'd go get some form of rootkit/kernel-mod to intercept audio/video/keystrokes well below the user layer, so that you wouldn't have to worry what application was running - just intercept the audio/screen/keyboard somewhere near the drivers.  Presumably some companies make such things, for just such organizations? (sort of like the equivalent of CarrierIQ)  That way it doesn't matter whether it's WebRTC, Flash, or native apps.

-hadriel