- From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Date: Fri, 12 Jan 2018 15:10:51 +0100
- To: Byron Campen <docfaraday@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
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:11:18 UTC