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

Re: webRTC and Content Security Policy connect-src

From: Roman Shpount <roman@telurix.com>
Date: Tue, 16 Jan 2018 11:03:46 -0500
Message-ID: <CAD5OKxuCmYAi7Y6i6OYFQ==accjmpurr4QMGuEJpfNnxKqKUEA@mail.gmail.com>
To: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Tue, Jan 16, 2018 at 5:36 AM, Stefan HÃ¥kansson LK <
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.

Regards,
_____________
Roman Shpount
Received on Tuesday, 16 January 2018 16:04:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 16:04:13 UTC