2018-01-10 at 00:57:53 +0000, teor <teor2345@xxxxxxxxx> wrote:
On 10 Jan 2018, at 10:23, debug <tracdebug@xxxxxxxxxx> wrote:Is there any specific reason why there is no comment from Tor-team for this issue?https://trac.torproject.org/projects/tor/ticket/24351Many 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@xxxxxxxx | 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev