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@gmail.com> wrote:

...

On 10 Jan 2018, at 10:23, debug <tracdebug@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@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

On 2018-01-10 at 23:25:05 +0000, teor <teor2345@gmail.com> wrote:

Sending every remote site address from the Tor process to an extension increases the surface area for attacks.

[...]

This gives the extension access to the content of every encrypted page.

[...]

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

Hello, teor, You evidently conflated two discrete options I discussed: One for an IP-blacklisting Tor controller process completely separate from the browser or any other application; and the other for an application-level browser extension which would be as benign as NoScript. (N.b., NoScript has “access to the content of every encrypted page”.) The former was just an off-the-cuff thought of how Core Tor could be made to block undesired destinations in the manner of a firewall (or router null-route), without modifying Core Tor or requiring any sort of proposal process. It would *not* interact with the browser. Even if it somehow did, I don’t see how you think it would obtain the contents of encrypted pages. What I described does not work that way, on its face. Most of all, it would NOT be part of the browser. Giving the browser (or extensions living inside the browser process) unfettered control port access would be both stupid and insane, and I am neither; indeed, I never run Tor Browser in its stock configuration because that gives it *far* too much access to Tor already (and I agree with pretty much everything Yawning said here: [0]). The latter is a browser extension which already exists, in the wild, today. It works by detecting Cloudflare-specific HTTP response headers which Cloudflare injects (and which Cloudflare would not be able to inject, if they did not actively MITM the TLS connection). It also works with non-Tor Firefox, without any Tor at all; it obviously does not interact with the Tor process in any way, shape, or form. https://addons.mozilla.org/en-US/firefox/addon/block-cloudflare-mitm-attack/ https://github.com/nym-zone/block_cloudflare_mitm_fx (Not written by me. I’m really a C guy, not a Javascript guy. I am simply trying to facilitate and encourage development.) Really, please, don’t mistake my proposal as something totally moronic. I will not be accused of trying to build some wack-job Tor controller into a web browser extension (!), or anything tantamount to that. [0] https://lists.torproject.org/pipermail/tbb-dev/2018-January/000736.html -- nullius@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