Re: [rtcweb] Consensus call regarding media security

[Iñaki Baz Castillo <[e-mail]>]

2012/3/29 Roman Shpount <[e-mail]>:
> First of  all, HTTP WebSocket connection are normally not allowed from HTTPS
> initiated sessions (or generate a warning).

Ok, I didn't check that.


> Second, my point was that SDES-SRTP is no more secure then plain RTP when
> signaling is transmitted over clear channel. You are saying the same thing.

Right:)


> If SDES-SRTP is allowed, there is no harm in allowing plain RTP from HTTP,
> since, as far as security is concerned, there is no difference.

The only I meant is that the signaling must be secured. Otherwise,
using SDES-SRTP adds no security at all. But the signaling could be a
different connection (i.e. WebSocket) different from the HTTP(s)
connection used to retrieve the web.

Let's assume this example:

- The browser access the web via plain HTTP.

- The JS opens two websocket connections:
  1) First one for the WebRTC signaling, a secure WS connection.
  2) Second one for other realtime stuff, a NON secure WS connection.


If the SDES key is carried over the first WS connection (wss) then
it's ok, it provides confidenciality. But if the SDES key is carried
over the second WS connection (ws, so unsecure) then it's
interceptable and therefore also the SRTP.

Question: can the WebRTC stack figure which WS connection is being
used for WebRTC signaling?
Autoanswer: NO, since the signaling protocol is up to the app developer.

So Houston we have a problem if we try to make requirements in which
SDES-SRTP can be used. I'm in favour of mandating SDES-SRTP in WebRTC,
but we need to solve this issue, and it is not easy (AFAIK).


Regards.

-- 
Iñaki Baz Castillo
<[e-mail]>