- From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Date: Fri, 12 Jan 2018 14:57:07 +0100
- To: 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
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 13:57:29 UTC