Re: Ban ICE-LITE? webRTC and Content Security Policy connect-src

Hi,

What Taylor said is correct.

Note, however, that ICEbis explicitly allows agents and ICE usages to use local policy for deciding when media starts.

Regards,

Christer


Sent from my iPhone

On 12 Jan 2018, at 19.36, Taylor Brandstetter <deadbeef@google.com<mailto:deadbeef@google.com>> wrote:

In Full ICE both endpoint need to send STUN requests (including
remote credentials) *before* media can be sent by any of them. Not
true in ICE Lite (obviously).

I don't think that's actually true. All it takes for an endpoint to begin sending media is to send a connectivity check and receive a response. That's what Chrome does at least, and I can't find anything in the standard that indicates otherwise.

So, I don't see that there's any problem unique to ICE lite; this seems like a general issue.

On Fri, Jan 12, 2018 at 8:40 AM, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:

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<mailto: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<mailto: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)