[tor-dev] Block Global Active Adversary Cloudflare
nullius at nym.zone
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
>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, mentioning the blinded tokens which wound up in #24321.
#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
“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:
>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 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.
>Then, if you think this change belongs in Tor, Tor has a proposals
>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
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
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...
Size: 228 bytes
Desc: not available
More information about the tor-dev