Re: webRTC and Content Security Policy connect-src

Den 16. jan. 2018 17:03, skrev Roman Shpount:
> On Tue, Jan 16, 2018 at 5:36 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
> 
>     On 15/01/18 23:19, Harald Alvestrand wrote:
>     > 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.
> 
>     Would not TURN servers (named by DNS names that can be looked up in
>     advance) be allowed as well?
> 
>     >
>     > Pretty close to "disable WebRTC".
> 
>     If TURN is OK it would be "allow WebRTC via relay only".
> 
> 
> TURN server simply provides relay but does not validate the ultimate
> traffic destination. I think rogue JavaScript still would be able to
> compromise a valid TURN server to establish a side communication channel
> to an undefined party. In order to limit the parties with which you are
> allowed to communicate, web page needs to limit TURN server, STUN
> servers, and ICE candidates at the same time.
> 

And since you're completely right about the TURN servers (we can ask
them to ship traffic to anywhere), it means we have to let CSP specify
a) trustable TURN servers that will send traffic where we ask them to,
and b) trustable endpoints that it's OK to ask TURN servers to send
packets to (visible in candidates).

Frankly, if we aim to protect against communication with third parties
in the setup phase, I can't see anything other than * being an useful
value if P2P communication is the goal.

(if we have working identity assertions for established peerconnections,
we also have another handle on defining who we're willing to talk to -
but we don't have that in practice yet, and post-negotiation filters
can't protect us against information leakage that happens pre-negotiation.)

Received on Tuesday, 16 January 2018 16:48:08 UTC