Re: webRTC and Content Security Policy connect-src

Guys, this issue has been open since 2014.. could we compromise on 
something that we could deliver now? More advanced ideas can be covered 
in next charter..

Best regards
Sergio

On 16/01/2018 0:06, Roman Shpount wrote:
> On Mon, Jan 15, 2018 at 5:45 PM, Martin Thomson 
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>
>     On Tue, Jan 16, 2018 at 5:18 AM, Roman Shpount <roman@telurix.com
>     <mailto:roman@telurix.com>> wrote:
>     > I agree identity happen too late in the process. What is needed
>     here is
>     > ability to cryptographically sign ICE candidates, TURN and STUN
>     servers.
>     > Signing with certificate of some well known domain listed in CSP
>     seems like
>     > a good option. This, of cause, will require API extensions to
>     provide these
>     > signatures.
>
>     Actually, it doesn't need changes, just a shift in what the browser
>     provides to the IdP.  The main cost is in latency.  At some point it
>     is necessary to go back to a server and adding that for trickle ICE
>     would hurt.  Also, the marginal gain is tiny.  We're talking about
>     CSP, which is belt-and-braces defense against script issues, it's not
>     bulletproofing for the entire negotiation.
>
>
> What I do not want to happen is that rogue JavaScript is inherently 
> allowed to create a communication side channel if WebRTC is enabled. 
> WebRTC services (business communications, call centers, personal chat) 
> often carry very personal and sensitive communications. At the same 
> time such services are often fairly complex from a scrip point of view 
> so they present a big target for rogue JavaScript attacks.
>
> In case of WebRTC I think CSP solution should mean that browser stack 
> should accept session description from a specified list of known 
> sources, not that browser should only communicate with the specified 
> list of servers. I would like to see a solution which allows 
> legitimate p2p use cases but stops unexpected communication leaks. 
> STUN and TURN servers can probably be covered by existing connect-src 
> to prevent leaks, since they are typically known in advance. There is 
> also a need for a mechanism to verify that ICE candidate came from a 
> well known source before any communication is sent to these 
> candidates. This can be a cryptographic signature which will have the 
> minimal effect on latency (should allow browser to retrieve the public 
> key once and re-use it), or IdP (which will need to be extended and 
> will likely require a round trip for each trickle ICE update). In any 
> case, what is needed is mechanism that verifies not only the DTLS 
> fingerprint but also every ICE candidate.
>
> Regards,
> _____________
> Roman Shpount
>