Earlier quoted context omitted.
You can whitelist CIDR ranges of /16 and /24 currently. So yes, you can to some extent whitelist everyone.
Yes, just add 65536 exceptions!
No need to add 10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, and a few others...
The Trouble with CloudFlare
291–300 of 361 posts
Re: The Trouble with CloudFlare
#292Earlier quoted context omitted.
This is where 3D Secure truly shines; instead of completely refusing a transaction, you can request the issuing bank (= bank of the card used to pay with) to accept the liability in case of fraud (normally, it's the merchant who has to give the money back). Usually the issuing bank will then request the customer for additional challenge, e.g. a 2FA token, a code in SMS, or just their birthday. Some don't even require…
3D Secure is a complete disaster. It encourages users to put ridiculously sensitive information like social security numbers and bank credentials into an iframe in the merchant site. This trains users to be phished.
Social security numbers?! Who the hell implemented it like THAT?
3D Secure redirects to the bank's site (not in an iframe! a real window with a visible address bar) where you enter a one-time code from SMS!
Re: The Trouble with CloudFlare
#293How about this solution: (yes, it's only 5% serious)
From every publically available internet do something that appears malicious until cloudflare's servers annoy everyone. At that point they'll be forced to find a new solution.
This only occurred to be because I get their captchas on public wifi in Starbucks and other public wifi in Japan
Re: The Trouble with CloudFlare
#294Payments originating from TOR IP addresses absolutely are more likely to be fraudulent. Anyone running an online business could tell you that.
I wouldn't even consider doing any payments through Tor. All I want is to read fucking blog posts without CAPTCHAs!
Re: The Trouble with CloudFlare
#295Earlier quoted context omitted.
3D Secure is a complete disaster. It encourages users to put ridiculously sensitive information like social security numbers and bank credentials into an iframe in the merchant site. This trains users to be phished.
Social security numbers?! Who the hell implemented it like THAT? 3D Secure redirects to the bank's site (not in an iframe! a real window with a visible address bar) where you enter a one-time code from SMS!
I have worked with systems implementing 3D Secure and have multiple credit cards that trigger it. I can assure you that the standard deployment for US-based banks and merchants uses iframes and in the majority of cases will ask for enough personal information to steal your identity or drain your bank account.
Re: The Trouble with CloudFlare
#296Earlier quoted context omitted.
You misunderstand the problem. The issue is that CloudFlare is treating Tor traffic like any other traffic. What you want is special treatment for Tor above and beyond the whitelisting feature CloudFlare already offers to site owners.
> CloudFlare is treating Tor traffic like any other traffic I don't see this in any practical fashion. I can visit a CloudFlare hosted site from the regular internet for hours (even scrape automatically) with no problems; the first time I hit the same site through Tor, it gets a double or triple capchca. Perhaps it should be a blacklist instead of a whitelist. Defaults matter.
Eh. No thanks. "Default deny" is the only sane security default.
Re: The Trouble with CloudFlare
#297Earlier quoted context omitted.
When are GET requests unsafe?
ddos or sqli, see the cf article
A respectable CDN should be able to handle lots of GET requests, even if by attack. As others have pointed out, the Tor network can't support much traffic, so DDoS by GET requests does not seem like a big concern.
Re: The Trouble with CloudFlare
#298Earlier quoted context omitted.
I'm a long-time Tor user that's been affected by CloudFlare captchas for a few years. I appreciate that you (CloudFlare) are trying to tackle the problem, but I feel that both CloudFlare and the Tor community have defeatist attitudes toward this issue. I have the following suggestions for CloudFlare: 1. Can you provide better documentation for your customers about what Tor is, and reasons for/against white/blacklisti…
1. Can you provide better documentation for your customers about what Tor is, and reasons for/against white/blacklisting Tor? For example, when a customer selects to Block or Captcha Tor, a tiny link could show up somewhere that says something like "This affects users who seek privacy, find out more." I'll make sure the product team sees that suggestion. 2. In addition to better docs, can you setup something that let…
>> 2. In addition to better docs, can you setup something that lets site operators view the site as a Tor user?
>
> That seems like an enormous amount of work when anyone can just get the Tor Browser and test it out.
Sure, but most site operators aren't going to get the Tor browser to test it out -- especially if they don't realize that that is something they should do.
By "view site as Tor user" I simply meant having a way for site operators to interact with the captcha page that CloudFlare presents users. That should be easy to setup; it can even be just a static HTML page that's linked from the documentation on Tor. I didn't mean that you should display the page through Tor.
Re: The Trouble with CloudFlare
#299Cleary cloudflare's customers prefer this behavior, it's their website, they are free to block tor traffic if they like.
Re: The Trouble with CloudFlare
#300Earlier quoted context omitted.
I'm a long-time Tor user that's been affected by CloudFlare captchas for a few years. I appreciate that you (CloudFlare) are trying to tackle the problem, but I feel that both CloudFlare and the Tor community have defeatist attitudes toward this issue. I have the following suggestions for CloudFlare: 1. Can you provide better documentation for your customers about what Tor is, and reasons for/against white/blacklisti…
1. Can you provide better documentation for your customers about what Tor is, and reasons for/against white/blacklisting Tor? For example, when a customer selects to Block or Captcha Tor, a tiny link could show up somewhere that says something like "This affects users who seek privacy, find out more." I'll make sure the product team sees that suggestion. 2. In addition to better docs, can you setup something that let…
> If you read the Trac thread you'll see that I've answered that. In short, I don't want to do it because that diverts engineering resource away from the right thing to work on (which is reduce the need for CAPTCHA).
I agree, but thinking about GET-only requests is one approach to reducing the need for CAPTCHA. For example, maybe CloudFlare could have better Tor defaults for sites that are serving only static content, and default to Captcha for sites that are POST-heavy (just a high level idea).
Basically, most of the time, GETs have nice properties: idempotent, pure, etc. I think a solution to the captcha problem could take these into account.
I do not think the other solution proposed in the CF blog post, using proof of work with some sort of blinded tokens, is going to work well. A hashcash style proof-of-work is easily defeated with a botnet or FPGA, and reputation-based systems are an ongoing research area.
It's possible there is a silver bullet that we haven't found yet. Have Tor or CloudFlare considered putting out a call for research into the problem?