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

     Forcing TURN-only operation when you specify a TURN-server 
whitelist seems like it violates the almost universal model of "Here's 
some TURN servers, use them if you have to, but try to establish a 
direct connection with the peer".

Best regards,
Byron Campen

On 1/12/18 8:10 AM, Sergio Garcia Murillo wrote:
> My understanding is that if we add the stun/turn urls to CSP, a 
> peerconnection will not be allowed to be created if no valid stun/turn 
> servers are used.
>
> Regards
> Sergio
>
> On 12/01/2018 15:03, Byron Campen wrote:
>>     The STUN/TURN servers don't matter here; this works without them.
>>
>> Best regards,
>> Byron Campen
>>
>> On 1/12/18 7:57 AM, Sergio Garcia Murillo wrote:
>>> 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
>>> Sergio
>>>
>>> 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 14:16:49 UTC