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

Re: webRTC and Content Security Policy connect-src

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 16 Jan 2018 17:45:26 +0000
To: Harald Alvestrand <harald@alvestrand.no>, Roman Shpount <roman@telurix.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <HE1PR07MB3418CF6494A424541DCF1E37C9EA0@HE1PR07MB3418.eurprd07.prod.outlook.com>
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.
Received on Tuesday, 16 January 2018 17:46:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 17:46:24 UTC