Re: webRTC and Content Security Policy connect-src

On Mon, Jan 15, 2018 at 5:45 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On Tue, Jan 16, 2018 at 5:18 AM, Roman Shpount <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