From gk at torproject.org Sat Dec 31 14:41:00 2016 From: gk at torproject.org (Georg Koppen) Date: Sat, 31 Dec 2016 14:41:00 +0000 Subject: [tor-access] Mitigating attacks that would lead to falling back to a purely CAPTCHA-based solution In-Reply-To: References: Message-ID: <245ce0b5-7616-76e9-00bc-ce24bce89659@torproject.org> Hi, While re-reading the specification after talking to Cloudflare people at CCC I realized there is even an IETF draft of the blinded token idea in the Git repository. Looking at that one closer I found there is a potential anti-DDoS protection mentioned that is missing in the specification itself. The idea is to include a proof-of-work (PoW) mechanism to avoid the option to send many viable-looking but invalid tokens to the Cloudflare servers engaging them in lots of expensive public-key operations before the tokens finally get dismissed. Now, I've heard the specification is about to get updated significantly but I am wondering whether that PoW feature will be in it or not. In general I feel this issue, the token stockpiling problem (section 8.3 in the spec) and any other one making it likely that the current CAPTCHA-based "solution", which is still a fallback ("We also leave the door open to an elevated threat response that does not offer to accept bypass tokens."), is getting resurrected needs to get addressed. The last thing I want to happen is investing all the effort in getting the blinded token solution properly deployed just to realize one week (or N weeks) later we are back at square zero due to just a single jerk using newly created attack opportunities over Tor forcing Cloudflare into disabling that bypass token solution again. This is not just some theoretical issue which might be entertaining to get discussed in an academic context. Rather, there are very likely attackers out there that are interested in it as we have seen that Cloudflare-style CAPTCHAs lead to users abandoning Tor which a) makes those more vulnerable and b) lowers the protections Tor provides to all of the remaining users. Georg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: