Re: webRTC and Content Security Policy connect-src

We're clearly in a state where someone, somewhere, has to say something
about the interaction between CSP and WebRTC - and if we want it to be
said with good understanding of WebRTC, it'd better be us.

As far as I can tell, csp: connect-src <list of hosts> is *supposed* to
give a guarantee that "Javascript will only cause packets to be sent to
hosts in the list".

(Whether it's realistic or not depends on a lot of factors, including
the TTL on the DNS entry of the hosts in the host list - but I digress).

WebRTC, on the other hand, assumes that you'll be allowed to send
packets to any IP address that occurs in a candidate or a configured
TURN server - including IP addresses with no corresponding DNS address.

I think there's a pretty obvious intersection here: If CSP connect-src:
is set, only access to addresses that are already known to be addresses
of permitted hosts are permitted.

That allows a single use case that I can see: Centralized conferencing
servers, with all servers including STUN servers named by DNS names that
can be looked up in advance.

Pretty close to "disable WebRTC".

There may be other CSP policies that allow more extensive WebRTC usage,
including ones that we define simply to allow that, but I don't
understand CSP enough to tell what they should be yet.

Another problem is where to write this down. The WebRTC spec seems like
the wrong place; if we're doing packet-level and IP-address-level stuff,
this seems more proper for an IETF document than for a W3C document -
but CSP is, as far as I know, an W3C-only thing.

New document?


Den 15. jan. 2018 19:18, skrev Roman Shpount:
> On Sun, Jan 14, 2018 at 10:33 PM, Martin Thomson
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
> 
>     (Re: Roman's suggestion about identity.  Though it would be nice if we
>     could do something to restrict communications based on identity,
>     identity can't help here.  It takes effect too late in the process.)
> 
> 
> I agree identity happen too late in the process. What is needed here is
> ability to cryptographically sign ICE candidates, TURN and STUN servers.
> Signing with certificate of some well known domain listed in CSP seems
> like a good option. This, of cause, will require API extensions to
> provide these signatures.
> 
> Ability to disable webrtc from CSP is great, but we need ability to
> restrict web page communications even when WebRTC is used. For instance,
> as a real time communication provider user, I do not want rogue
> javascript sharing all my communications with third parties.
> 
> Regards,
> _____________
> Roman Shpount
>

Received on Monday, 15 January 2018 22:16:56 UTC