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

As I expect you are aware, the RETURN draft currently contains contrary
guidance on this point (
http://tools.ietf.org/html/draft-schwartz-rtcweb-return-04#section-5.8):
"WebRTC
browsers MUST by default (i.e. unless deliberately configured otherwise)
treat SOCKS5 proxies as leaky"

My expectation is that most proxy users are _not_ using the proxy in an
attempt to improve their privacy.  Rather, they are using the proxy in an
attempt to improve their ability to access network resources, such as when
operating on a restricted network or when accessing intranet resources.
For those users, it would be unexpected and unfortunate if activating the
proxy made many websites _stop_ working.

However, the main reason for this recommendation was to maintain
compatibility with existing browsers, which (as you've noticed) do not
block UDP when a SOCKS proxy is activated.

My feeling is that browsers should provide an option to configure a sealed
proxy, but I generally expect that browser settings configuration consoles
are out of scope for this working group.

P.S. There is also the additional complication that SOCKS proxies are often
configured by PAC files, which determine proxy settings for each request
depending on its URL, but RTCPeerConnection objects are not associated with
a destination URL.

On Tue, Feb 10, 2015 at 10:36 AM, Philipp Hancke <fippo@goodadvice.pages.de>
wrote:

> 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.
>
>