Re: webRTC and Content Security Policy connect-src

On Tue, Jan 16, 2018 at 12:45 PM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 16/01/18 17:48, Harald Alvestrand wrote:
> > Den 16. jan. 2018 17:03, skrev Roman Shpount:
> >> On Tue, Jan 16, 2018 at 5:36 AM, Stefan Håkansson LK
> >> <stefan.lk.hakansson@ericsson.com
> >> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
> >>
> >>      On 15/01/18 23:19, Harald Alvestrand wrote:
> >>      > I think there's a pretty obvious intersection here: If CSP
> connect-src:
> >>      > is set, only access to addresses that are already known to be
> addresses
> >>      > of permitted hosts are permitted.
> >>      >
> >>      > That allows a single use case that I can see: Centralized
> conferencing
> >>      > servers, with all servers including STUN servers named by DNS
> names that
> >>      > can be looked up in advance.
> >>
> >>      Would not TURN servers (named by DNS names that can be looked up in
> >>      advance) be allowed as well?
> >>
> >>      >
> >>      > Pretty close to "disable WebRTC".
> >>
> >>      If TURN is OK it would be "allow WebRTC via relay only".
> >>
> >>
> >> TURN server simply provides relay but does not validate the ultimate
> >> traffic destination. I think rogue JavaScript still would be able to
> >> compromise a valid TURN server to establish a side communication channel
> >> to an undefined party. In order to limit the parties with which you are
> >> allowed to communicate, web page needs to limit TURN server, STUN
> >> servers, and ICE candidates at the same time.
> >>
> >
> > And since you're completely right about the TURN servers (we can ask
> > them to ship traffic to anywhere), it means we have to let CSP specify
> > a) trustable TURN servers that will send traffic where we ask them to,
> > and b) trustable endpoints that it's OK to ask TURN servers to send
> > packets to (visible in candidates).
>
> I'm probably thicker than usual, but that seems like what we require
> from "Centralized conferencing servers, with all servers including STUN
> servers named by DNS names that can be looked up in advance." as well -
> I don't see a big difference.
>

There is still a small caveat here: with HTTPS DNS name, browser would use
a certificate to validate that it is indeed communicating with the expected
server. With TURN servers (except TURNS) and ICE candidates, connections
are not verified to match the valid certificate associated with the domain
name. Final communications will be validated using a DTLS fingerprint, but
this is still a subject to manipulation by the malicious JavaScript. So,
listing TURN domain names and only using ICE candidates which point to
listed domains is safer then doing nothing, but it is still less secure
then listing HTTPS servers.

I almost feel that blocking WebRTC completely and then figuring out correct
way to unblock it (through IdP or candidate signing) is a better option.

Regards,
_____________
Roman Shpount