W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2018

Re: webRTC and Content Security Policy connect-src

From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 12 Jan 2018 22:24:50 +0000
Message-ID: <CAJrXDUHsEocYE4CbWcEzzUwC4mex8u-LeoppWjt=ouvPxfVomg@mail.gmail.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: T H Panton <thp@westhawk.co.uk>, Cullen Jennings <fluffy@iii.ca>, IƱaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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

On Fri, Jan 12, 2018, 2:16 PM Peter Thatcher <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> 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
Received on Friday, 12 January 2018 22:25:24 UTC

This archive was generated by hypermail 2.3.1 : Friday, 12 January 2018 22:25:25 UTC