As I pointed out on the other thread (why do we have 3 now?), I think any packets being sent by the browser where the JS can control the destination port is sufficient to convey information. On Fri, Jan 12, 2018, 5:48 AM Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> 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 16:23:03 UTC