- From: Byron Campen <docfaraday@gmail.com>
- Date: Fri, 12 Jan 2018 08:03:17 -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
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:03:35 UTC