webrtc vs socks proxies (was: Re: [rtcweb] ICE exposes 'real' local IP to javascript)

changing subject.

Am 05.02.2015 um 22:02 schrieb Harald Alvestrand:
[...]
> I would see much more benefit in someone trying for a writeup that
> describes precisely the threat they see, what mitigations they see
> against the possible threat, and - importantly - what functionality we
> would lose by implementing those mitigations.

So here is one aspect I found worrying: socks proxies.

When using a socks (v4) proxy (ssh -D, apparently also a common setup 
for some tor users) and there exists a "more direct route" to the 
internet, the "public ip" is "exposed".


Possible mitigation: WebRTC should honor the proxy settings. Here, this 
would mean disabling UDP. Any TCP traffic (including TURN and ICE-TCP) 
is routed via the socks server. As a result, instead of the "public ip" 
the one of the socks server is exposed. Which is what happen for all 
other kinds of requests as well.


Functionality loss:
With UDP disabled, TURN/TCP or TURN/TLS are going to be used via the 
proxy. Sites that don't use TURN/TCP or TURN/TLS are not going to work. 
This might affect datachannel-only use-cases that elide TURN by routing 
via an overlay mesh.

This increases the load on the socks server. I don't think this is 
relevant, socks has been used for filetransfer in the past so proxies 
should be able to deal with that.
RETURN can allow optimizing this by making TURN traffic go over 
dedicated TURN servers or allowing it to leak.


This is mostly a question of what the user expectation is regarding 
leakyness. I don't know about users. I only spoke to one who was using 
tor occasionally and concerned.

Received on Tuesday, 10 February 2015 15:37:12 UTC