Re: webRTC and Content Security Policy connect-src

On 12 January 2018 at 12:53, Iñaki Baz Castillo <ibc@aliax.net> wrote:
>> Proposal:
>
>> a) Ban ice-lite on pages with any CSP set
>
> Too hard to understand the rationale.
>
>
>> c) add a allow-ice-lite CSP
>
> Even harder to understand IMHO.
>
>
>> c) test plain ICE to make sure it fails if the far side sends no valid requests.
>
> In ICE Lite the remote won't send requests at all.
>
>
>
> A solution coming to my mind would be:
>
> 1. The browser signals its ice-ufrag to the remote (via HTTP/webSocket, etc).
>
> 2. The browser then send STUN Binding Requests (as always, with the
> remote ice-ufrag, etc) to the remote ICE Lite endpoint.
>
> 3. The remote MUST reply to those Binding Requests with, somehow, the
> sender's ice-ufrag included (and fingerprinted) into the STUN
> response.
>
> 4. Upon receipt of the ICE response, the browser MUST verify whether
> the ICE response has the local ice-ufrag. Otherwise it's dropped.
>
> So, in the use case above, the browser MUST signal its local
> ice-ufrag, which means that it must use HTTP or WebSocket (yep, or
> TURN credentials, but that's a different story), so existing CSP rules
> (content-src) join the party and, if set, would make it impossible for
> the attacker JS to provide the remote endpoint with its local
> ice-ufrag. End of the story.
>
> These steps would make both, Full ICE and ICE Lite, have the same
> security concerns.
>
> NOTE: Of course, for this to work, calling pc.setLocalDescription()
> with mangled ice-ufrag should NOT work.


To summarize: The current issue with ICE Lite is that it's not needed
for the browser (ICE controlling) to provide the remote with the
browser *internally* and *dynamically* generated tokens (such as the
ice-ufrag). With my proposal above, this would change so the JS should
always signal its local ice-ufrag to the remote (otherwise ICE
responses would be discarded). And for that, the JS must send it via
HTTP/WebSocket, so habemus CSP rules to block them.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Friday, 12 January 2018 12:02:29 UTC