Sorry that's IP and port. So maybe domain-name-only remote ICE candidates with whitelisted domains might work. But I think that would mean ICE would then not work p2p, only c2s. On Fri, Jan 12, 2018, 8:22 AM Peter Thatcher <pthatcher@google.com> wrote: > 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:40:48 UTC