Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO)

[Adam Roach <[e-mail]>]

On 8/11/15 15:37, carlo von lynX wrote:
> Then I need to know if there actually is a consensus on
> the practical recommendation of
>      - disabling the network interface API when proxy is configured

I'm not sure this has been discussed in earnest here or elsewhere. 
There's been some discussion of maybe pushing all RTP traffic through am 
HTTP proxy when one is configured [3], but this has been highly 
controversial.

The problem is that, while HTTP proxies were designed with a number of 
purposes in mind -- see page 10 of [1], and section 2 of [2] -- none of 
them were "making it appear that a user is in a different part of the 
network than he really is." They can be *used* to do that (with a lot of 
caveats [3]), but their primary purposes lie elsewhere.

What you're advocating only makes sense in the context of appearing to 
come from a part of the network that you're not in. It's kind of a 
tail-wagging-the-dog approach: if you're using proxies for their 
designed purpose, then this disabling is not what you want to happen. In 
the intended use cases, what you want is the ability to discover some 
kind of local TURN server that does for RTP what HTTP proxies are 
designed to do for HTTP (again, see section 2 of [2]).

However, that raises a potentially interesting approach. One of the 
things we're working on in the TRAM working group is exactly this kind 
of TURN server discovery. If we had some means of learning this from a 
configured HTTP proxy (and a means of this field saying "and only use 
relayed candidates"), then the web browser might be able to use it as an 
alternate discovery mechanism. If we add this kind of discovery, then 
proxies that are deployed for the purposes you care about -- appearing 
to come from a different part of the network than the one you're in -- 
can point your browser to a TURN server that is colocated with the HTTP 
proxy. That way, WebRTC traffic will originate from the same point in 
the network as HTTP traffic. It also seems possible that we could 
include some way for this field to basically say "don't use WebRTC if 
you're using this proxy."

>      - otherwise asking user for permission to access such API

Based on discussions that I've seen so far, I believe that more people 
oppose such a proposal than support it -- but it's not clear to me that 
there's consensus in either direction. It's easier to call for consensus 
around text in an internet-draft, though, than suggestions in an email. 
At the very least, it would be the first step in determining what kind 
of compromise might be reached.

/a
____
[0] 
https://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03
[1] https://tools.ietf.org/html/rfc7230
[2] https://tools.ietf.org/html/draft-nottingham-http-proxy-problem-01
[3] For example, what would you make of a connection that originates 
from an IP address in Ireland, but has a date that appears to be in 
UTC+3:30, and a language setting of "fa-IR"?