Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07

[Randell Jesup <[e-mail]>]

On 2/21/2014 11:27 AM, Magnus Westerlund wrote:
> 5. Section 3.2:
>     U-C 7:  Proxy browsing, where a browser uses data channels of a
>             PeerConnection to send and receive HTTP/HTTPS requests and
>             data, for example to avoid local Internet filtering or
>             monitoring.
>
> >From a data channel perspective this doesn't look strange at all,
> however I get the shivers from the security implications of this. To my
> understanding Peer A using Peer B to proxy browse must have B fetch all
> elements that A needs into its sandbox and then transfer it to A over
> the PeerConnections Data Channel. Thus, all you do are revealed to B,
> massive privacy consideration. Or am I missing someway that A can tunnel
> its HTTP request through B without having B see the content of those
> requests, I am especially concerned with HTTPS.
>
> If this use case is going to stay, I do want some security consideration
> discussion around it.

I'll note that there are active projects looking to use this.  Yes, it 
will likely expose non-https data to the proxy.
https traffic should in theory be as protected as it normally is against 
proxies.

This usage would support various forms of monitoring-avoidance (and 
avoidance of relying on local network resources such as in a WiFi 
hotspot).  It's not a direct replacement for Tor, but it's also much 
less intrusive than Tor.  It inherently requires some level of trust of 
the person proxying for you.

We can expose some of the security considerations, but the primary ones 
would be dependent on how this is used, not that this protocol has the 
characteristics that would support such a use.  This is mostly saying 
"we want it to be low overhead for stream creation and initial messages 
and support a bunch of them at once".


-- 
Randell Jesup -- rjesup a t mozilla d o t com