- From: Byron Campen <docfaraday@gmail.com>
- Date: Fri, 12 Jan 2018 08:16:32 -0600
- To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, 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
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