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

Re: webRTC and Content Security Policy connect-src

From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Tue, 16 Jan 2018 00:18:15 +0100
To: Roman Shpount <roman@telurix.com>, Martin Thomson <martin.thomson@gmail.com>
Cc: T H Panton <thp@westhawk.co.uk>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Iñaki Baz Castillo <ibc@aliax.net>, Cullen Jennings <fluffy@iii.ca>
Message-ID: <c065fd07-9171-fa18-e6bc-9ea6ed9fe653@gmail.com>
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

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
Received on Monday, 15 January 2018 23:18:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 15 January 2018 23:18:52 UTC