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:57:07 +0100
To: Lennart Grahl <lennart.grahl@gmail.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, T H Panton <thp@westhawk.co.uk>, Iñaki Baz Castillo <ibc@aliax.net>, Cullen Jennings <fluffy@iii.ca>, public-webrtc@w3.org
Message-ID: <c2586ee9-e7f5-ab93-074a-9b807ee56f76@gmail.com>
You could consider that if you have the sun/turn urls on your CSP they 
would be authenticated. So the malicious code should first learn how to 
get the username/pwd for your service before doing what you say.

A the code is already running on the your browser, it would definitively 
be able to do that and the proposed solution would just make it more 
difficult to perform a general attack, but not a targeted one to a 
specific server using webrtc. Note that people not using webrtc will be 
safe anyway.

Best regards

On 12/01/2018 14:52, Lennart Grahl wrote:
> I'm not sure restricting STUN/TURN servers, or banning ICE lite, or what
> you've suggested now would resolve this issue:
> What if I create an RTCPeerConnection and I use allowed STUN/TURN
> servers (if any). I create an offer and provide a fake answer with some
> data encoded as part of ICE ufrag/pwd. Then I'll pass fake remote
> candidates that include an IP I want to send this information to. The
> ICE agent will start sending STUN binding requests to that IP which
> contains my data as part of the username. Shouldn't that work?
> Cheers
> Lennart
> On 12.01.2018 14:46, Sergio Garcia Murillo wrote:
>> 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:57:29 UTC

This archive was generated by hypermail 2.3.1 : Friday, 12 January 2018 13:57:30 UTC