Re: webRTC and Content Security Policy connect-src

Yes, in that case all communications would have to go either via a 
secured TURN server, or have one of the peers with controlled external 
IP address (an agent in a call center for example).

But let's keep in mind that we are talking about paranoid grade security 
scenario that requires the usage of webrtc (like the banking case), so I 
would not assume this not a weird deployment requirement for them (been 
there, done that).

For normal cases, either don't use CSP, don't use webrtc, or whitelist 
stun/turn servers and enable all candidates (which won't make you immune 
to this kind of attacks but will make them much more difficult as the 
attacker needs to target specifically your service by knowing how to get 
the stun/turn servers url and credentials for them).

Regards
Sergio

On 12/01/2018 23:24, Peter Thatcher wrote:
>
> Ah, I see what I was missing: you can have the p2p endpoint connect 
> back to you without it having a whitelisted domain (assuming 
> peer-reflexive addresses are indeed safe).  But then if the remote 
> side is also CSP, then it can't connect to the local side.
>
> Would a remote TURN candidate also work?   The TURN server could be 
> the whitelisted domain for the remote candidate.  Then both sides 
> could be CSP.
>
> So it doesn't completely break down.  It just requires a lot more TURN 
> (or RETURN).
>
>
> On Fri, Jan 12, 2018, 2:16 PM Peter Thatcher <pthatcher@google.com 
> <mailto:pthatcher@google.com>> wrote:
>
>     Ah, yes.  You are right.   Peer-reflexive candidates might be safe
>     then.
>
>
>     On Fri, Jan 12, 2018, 2:12 PM Sergio Garcia Murillo
>     <sergio.garcia.murillo@gmail.com
>     <mailto:sergio.garcia.murillo@gmail.com>> wrote:
>
>         On 12/01/2018 22:38, Peter Thatcher wrote:
>>
>>             Unless you get lucky and peer-reflexive happens to work,
>>             which it won't if both sides have the same CSP poilicy.
>>
>>
>>         Hmmm.... I forgot about peer-reflexive candidates.  Those
>>         would allow JS to send data out by creating a PeerConnection,
>>         gathering STUN candidates along with ICE ufrag/pwd (even with
>>         a whitelisted STUN server), send those candidates to a
>>         controlled server, send an ICE check from the server to the
>>         client, and get the client connect back.
>>
>>         Which means whitelisted domain candidates wouldn't be
>>         enough.  You'd also have to disable peer reflexive candidates.
>
>         What do you mean by "send those candidates to a controlled
>         server"? If CSP is in place you should not be able to do so.
>
>         Regards
>
>         Sergio
>
>