W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2018

Re: Ban ICE-LITE? webRTC and Content Security Policy connect-src

From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Fri, 12 Jan 2018 14:46:01 +0100
To: Harald Alvestrand <harald@alvestrand.no>, T H Panton <thp@westhawk.co.uk>
Cc: Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Cullen Jennings <fluffy@iii.ca>
Message-ID: <11d81139-d24e-5c07-8cea-fc45e4d3fd7d@gmail.com>
Disclaimer: I did my ICE lite implementation 5 years ago, so I maybe 
completely wrong.

We are assuming that ICE lite is less secure that full ICE because in 
full ICE you need to know the remote ufrag in order to create the 
request, right?

But that information will be available at the full ice endpoint as soon 
as the first incoming stun binding request is received. So wouldn't this 
mean that both full ice and ice lite are equally insecure?

As Iñaki is pointing out what would be needed is to use the remote pwd 
(which is not exchanged in stun request) in order to authenticate also 
the remote peer. This is something I have never understood about ICE, 
why it requires both ufrags to form the username, but only uses the 
local password for fingerprinting (I assume is to speed up setup up 
times not having to wait for remote peer info before starting ICE). 
Using local_pwd:remote_pwd for fingerprinting would solve this issue 
altogether for both ice and ice-lite.

Best regards
Sergio

On 12/01/2018 14:19, Harald Alvestrand wrote:
> To me, it sounds like we should ban ICE-LITE altogether.
>
> We've got a lot of security story resting on the idea that the ICE 
> request/response requires both ends to have seen the SDP.
> If that isn't true for ICE-LITE, then ICE-LITE is not safe for WebRTC.
>
> On 01/12/2018 01:20 PM, Sergio Garcia Murillo wrote:
>> Missed it, that will prevent it, right.
>>
>> On 12/01/2018 13:11, T H Panton wrote:
>>>
>>> That's covered in my proposal:
>>>
>>>>     add a CSP turn-servers whitelist (to prevent leakage via the
>>>>     credentials)
>>>
>>
>
Received on Friday, 12 January 2018 13:46:24 UTC

This archive was generated by hypermail 2.3.1 : Friday, 12 January 2018 13:46:25 UTC