[tor-dev] Block Global Active Adversary Cloudflare

Wed Jan 10 18:38:58 UTC 2018

I am the reporter of #24351.  As thereto, thanks for your thoughts, 
teor; I will respond accordingly:

2018-01-10 at 00:57:53 +0000, teor <teor2345 at gmail.com> wrote:
>>On 10 Jan 2018, at 10:23, debug <tracdebug at riseup.net> wrote:
>>
>>Is there any specific reason why there is no comment from Tor-team for 
>>this issue?
>>
>> https://trac.torproject.org/projects/tor/ticket/24351
>
>Many of us have been on holidays.
>
>Also, the discussion on the ticket is hard to follow.
>It's long, and it doesn't appear to be progressing.
>Tickets aren't designed for that kind of discussion.
>
>There also appear to be several similar tickets on the same topic.
>This makes it harder for people to keep up.
>Maybe there is a response on one of the other similar tickets?

Indeed, I infer that you mean #18361, which generated well over two 
hundred comments within its first month.  Unfortunately, after its 
reporter was disappeared, discussion eventually petered out; and the 
last substantial comment for almost 14 months was by Cloudflare CTO 
jgrahamc,[0] mentioning the blinded tokens which wound up in #24321.

[0] https://trac.torproject.org/projects/tor/ticket/18361#comment:241

#24321 proposes to add third-party code to Tor Browser for the purpose 
of kowtowing to Cloudflare.  I strongly object to that, for the reasons 
I (and others!) set forth at #24321 (q.v.).  Moreover, the demand that 
Tor Browser change its behaviour to avoid being blocked by Cloudflare is 
backwards and upside-down:  It is Cloudflare which should be blocked; 
whereas with their CAPTCHA policy, they’ve done a bang-up job of 
psyching users into begging to them.

I’ve been concerned about Cloudflare for years.  The foregoing 
juxtaposition provided the momentary impetus for me to step forth and 
suggest a security feature I have desired ever since I first paused to 
think about what Cloudflare actually does.  I wish that more people 
would do that last.  I think most tech-industry people don’t even 
realize that Cloudflare fully decrypts and reads/modifies the plaintext 
of *all* TLS connections passing through their network.

>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

>Please do some background reading on this part of Tor's design before
>responding to this email, or adding anything to the bug tracker.

I will respond to that myself, since I am the one who added #24351 to 
the bug tracker.

I am deeply familiar with Tor’s design.  Indeed, years ago, before I 
first installed Tor, I read Torspec and skimmed a bunch of pertinent 
references in anonbib.  On occasion, I have also audited Tor’s source 
code[1] to my own satisfaction; this is how I discovered the ignomious 
buglet #22103 (found 2014, reported 2017).  I have not recently followed 
the cutting edge of Tor development or the latest proposals; but I do 
know how Tor works, and how its development process works.

[1] (I’m good with C, not with Javascript; I am @nym-zone on Github.)

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

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.

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

-- 
nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No!  Because I do nothing wrong, I have nothing to show.” — nullius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180110/20d5a92b/attachment.sig>