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> 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