Re: [tor-dev] Block Global Active Adversary Cloudflare

[teor <teor2345@xxxxxxxxx>]

Hi,

On 11 Jan 2018, at 05:38, nullius <nullius@xxxxxxxx> wrote:

>> Here's what I suggest you do:
>> 
>> Blocking an entire CDN would be a major change to either Tor or Tor Browser's design. It's not likely to happen, because of the security vs usability tradeoff. Significantly reducing the usability of Tor would decrease the number of users, making Tor's anonymity set smaller, and reducing anonymity for everyone.
> 
> My suggestion is to tie blocking behaviour to the Security Slider.  I do understand that blocking Javascript, etc. by default would have the same “anonymity set” impact as you describe; and that’s why we have the Security Slider to begin with, so let’s use it!
> 
> I do almost all my web surfing on “High”; and I can attest, that already breaks most of today’s Web.  Users who surf on “High” security can be expected to *desire* some additional breakage, if that helps protect the confidentiality and integrity of their communications.  Thus, I suggest that Cloudflare should be blocked by default on “High” (with an “Add exception” style override button).
> 
> On “Medium” security, I suggest that at least clear warning should be displayed.  I’m on the fence about whether it should block by default here, or offer to set an option to block with the same popup widget used for various other permissions issues (“Allow this: Always/Never”).
> 
> On “Low” security—well, users who surf on “Low” security are already suicidal, anyway.  (I myself *never* use the “Low” security level—never!)  The lock icon should still be changed, perhaps with the same display as used on mixed-content sites.  But I do not think Cloudflare should be blocked by default on the “Low” security level.
> 
> I believe the foregoing should address your concerns about the “security vs. usability tradeoff”, for reasons identical to those discussed at:
> 
> https://www.torproject.org/projects/torbrowser/design/#security-slider
> 
> https://www.torproject.org/docs/faq.html.en#TBBJavaScriptEnabled
> 
>> … 
> 
>> Then, if you think this change belongs in Tor, Tor has a proposals process:
>> https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt
>> 
>> Please submit a proposal with reasons for the change, and a design.
> 
> I don’t see this as a suitable change for Core Tor.
> 
> With no need for a proposal, it *should* be relatively straightforward to build a generalized blacklisting (sort of IP null-routing) utility using the Tor Control Protocol—perhaps using __LeaveStreamsUnattached and juggling streams and circuits ourselves?  It is only a bit tricky due to name resolution occurring on the exit:  We usually won’t know the destination IP address until Tor receives a RELAY_CONNECTED cell.

Sending every remote site address from the Tor process to an extension
increases the surface area for attacks. The browser needs to have URLs to
do its job, but even it doesn't get IP addresses. Each extension that we add
to the browser should have the minimum information it needs to operate.

Another alternative is to add an option to Tor that rejects remote site
addresses, much like the existing ReachableAddresses option for entry
nodes, or the ExcludeNodes options for relays. I can see this being a
plausible feature for people who want to resist DNS poisoning,  if they
know the netblocks in advance.

> Add a list of IP addresses registered to Cloudflare in the RIR databases, and we’re done.  (I assume that they have all their own allocations, though I’d investigate that assumption if I were actually doing this.)
> 
> But this would provide no application-level UI integration or override mechanism for the user.  Cloudflare is easy to detect at the application level, due to their injection of Cloudflare-specific HTTP headers.  Wherefore I filed #24351 against Tor Browser, not Core Tor.

This gives the extension access to the content of every encrypted page.
This is a greater level of access than CloudFlare. The same objections
to CloudFlare apply, But the extension knows more, because it runs on
the local user's machine, knows about multiple remote sites, and could
collect local information as well.

>> If you think this change belongs in Tor Browser, please send a short change proposal to the tbb-dev list.
> 
> Good idea, thanks.  When time permits, I may try to work up something suitable.

Please develop a least-authority design. Don't become the new CloudFlare.

T
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev