- From: Lennart Grahl <lennart.grahl@gmail.com>
- Date: Fri, 12 Jan 2018 14:52:11 +0100
- To: Sergio Garcia Murillo <sergio.garcia.murillo@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
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:52:35 UTC