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 21:38:54 +0000
Message-ID: <CAJrXDUE3Ssp7xZcJeGKekoaxBPVc_EidsYdFZFFnRvGh2Pxcpg@mail.gmail.com>
To: T H Panton <thp@westhawk.co.uk>
Cc: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, Cullen Jennings <fluffy@iii.ca>, IƱaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Fri, Jan 12, 2018 at 10:22 AM T H Panton <thp@westhawk.co.uk> wrote:

>
>
> On 12 Jan 2018, at 18:17, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
>
>    - remote candidates: any remote candidate passed to an PC (either on
>    the setRemoteDescription or addIceCandidate) not maching an entry on the
>    whitelist will be discarded
>
> You've just disabled P2P in webrtc.
>

Can a p2p endpoint have a whitelisted domain?

If yes, then you can put it in a remote candidate and it will work. But
then why do you need p2p in the first place?

If no, then CSP says you can't connect to it.  But then CSP is inherently
incompatible with p2p.



> 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.
Received on Friday, 12 January 2018 21:39:38 UTC

This archive was generated by hypermail 2.3.1 : Friday, 12 January 2018 21:39:39 UTC