Live data from Hacker News

The Trouble with CloudFlare

blog.torproject.org

151–160 of 361 posts

Re: The Trouble with CloudFlare

#151

Earlier quoted context omitted.

* facepalm * No room for nuance, huh? Or appreciation for the position CloudFlare is in and their obligation to their clients? How would you solve this? Abuse from Tor IPs is a known and documented problem. If you have a solution, I'll bet CloudFlare has a job opening.

Absolutely not. I believe in privacy and have zero tolerance for big businesses who throw their weight around at the expense of minority communities (Tor users in this case). I understand CloudFlare's need to make a profit. That is why we need to turn treating Tor traffic like normal traffic into a good business decision.

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.

Re: The Trouble with CloudFlare

#152
post #142
post #130

Earlier quoted context omitted.

Exactly. But I strongly disagree. You don't blame mask manufacturers for malicious people wearing masks. It's like city guards banning everyone with a mask from entering and issuing IDs to them. Then they're using those IDs to determine what they should and shouldn't see in the city, tracking them everywhere "across cities" etc. In the interest of privacy, it is best to instead use the dynamic nature and types of the…

> Going with the mask analogy, they should instead check if a person is brute forcing lock combinations. Maybe even condition on the fact that they're wearing a mask. That's what they're doing. They are seeing brute forcing come from a bunch of IPs and they're blocking those. What do you expect them to block on? The people using the anonymous service voluntarily identifying themselves on every request (cookies, brows…

Instead of having IP-based reputation system, that persists for quite a while, they could have a time limit per IP for specific kinds of requests.

Like if you fail to log in to a site, 2^(attempts) timeout from that IP for that page only. Can also integrate a combination of request headers. Sure, it's still IP-based reputation, but it doesn't persist and is much less intrusive.

Most sites require specific cookies on consecutive requests, and such blocking should be on the app side only.

There are solutions in each case and all of them are harder than IP-based blocking. However, in the interest of privacy, they should adopt these more nuanced solutions.

Re: The Trouble with CloudFlare

#153
post #60

Maybe I'm a cranky, old-school network operator, but this is a very cut and dry problem. Tor runs a network that is rife with abuse and fraud. Tor needs to clean up and police its network. If it doesn't, it will be put on blacklists and customers will take active measures to block traffic from it. This is no different than a network or AS that is spammer friendly, botnet friendly, carder friendly, etc. All of those n…

Filtering of outbound traffic from Tor exit nodes can only be done by Tor exit node operators. The Tor project can kick out some defaults (like, say, blocking SMTP) but ultimately it wouldn't matter...the bad actors will just find ways around the filters, or devise new ways to abuse the system. Static filters will never work. It's like hoping everyone will do source address verification on egress.

Cloudflare just have to get smarter here. It's their business to do dynamic filtering and balance this stuff, not Tors.

Re: The Trouble with CloudFlare

#154

Earlier quoted context omitted.

Hi, I'm completely sympathetic to your problem - Tor is used by lots of spammers - totally understandable to try to prevent this spam from hitting your customers. But most of the services I run can't really be affected by this sort of spam (no public comment systems for example). I use CloudFlare on a few of my domains, if I don't care about bot traffic and just want to turn this CAPTCHA system off entirely, is there…

Yeah, I don't get why CloudFlare are so overaggressive with the captchas. The vast majority of captcha'd pages by CloudFlare on Tor which makes secure web browsing so cumbersome are completely read-only, while some may have a comment system hosted by a third party like Disqus and Facebook (and are therefore protected already). Other sites should have the captchas on a different level than the front page, like the log…

"Read-only" pages are still fertile ground for layer 7 DDOS.

Re: The Trouble with CloudFlare

#155
post #7

This is a tough situation. I don't know about 94% of TOR traffic being fraudulent but I'm sure it's high. But I'm one of the legit users that gets taken out by blacklisting. I use a VPN service pretty regularly and it makes accessing my Cloudflare account and sites using it incredibly annoying.

> I don't know about 94% of TOR traffic being fraudulent but I'm sure it's high.

I was curious and ran a quick check on my servers. 5 servers, about 300 domains, checked my logs going back 1 week. I could find just ONE legitimate session. Everything else was something trying to break WordPress or PHPMyAdmin or something else. I'd love to support Tor but I feel like I can't fight this fight.

Re: The Trouble with CloudFlare

#156

Earlier quoted context omitted.

* facepalm * No room for nuance, huh? Or appreciation for the position CloudFlare is in and their obligation to their clients? How would you solve this? Abuse from Tor IPs is a known and documented problem. If you have a solution, I'll bet CloudFlare has a job opening.

Absolutely not. I believe in privacy and have zero tolerance for big businesses who throw their weight around at the expense of minority communities (Tor users in this case). I understand CloudFlare's need to make a profit. That is why we need to turn treating Tor traffic like normal traffic into a good business decision.

"Absolutely not. I believe in privacy and have zero tolerance for big businesses who throw their weight around at the expense of minority communities (Tor users in this case)."

You're fine with the anonymity industry throwing their weight around at the expense of a handful of CDN's, though. I understand Tor's need to protect users. That's why they need to find a way to treat malicious traffic different than normal traffic. Then adopting them might be a good business decision.

Re: The Trouble with CloudFlare

#157
post #123

Earlier quoted context omitted.

> I'm not following the connection between a large percentage of Tor requests being malicious and the fact that Tor users have almost the same conversion rate. The point is that blocking or de facto blocking an IP address which is shared by many different users just because one is malicious is costing CloudFlare's customers money.

The reason some e-commerce sites are blocking Tor is not because of low conversion rates (that would be silly), but because of fraud (and attacks) coming from Tor users. Those two numbers are not related, and it has nothing to do with why CloudFlare shows captchas for Tor users. The argument doesn't address the fact that a large percentage of Tor traffic is malicious at all. It's a straw man argument, really. On top…

The point of the argument is that preventing fraud using IP blocking is costing you money that you could have in your pocket if you would instead prevent fraud using signature detection or some other method.

Re: The Trouble with CloudFlare

#158
post #154

Earlier quoted context omitted.

Yeah, I don't get why CloudFlare are so overaggressive with the captchas. The vast majority of captcha'd pages by CloudFlare on Tor which makes secure web browsing so cumbersome are completely read-only, while some may have a comment system hosted by a third party like Disqus and Facebook (and are therefore protected already). Other sites should have the captchas on a different level than the front page, like the log…

"Read-only" pages are still fertile ground for layer 7 DDOS.

It wouldn't be hard to only display the captchas if sudden increased traffic from Tor exits indicated that a DDOS through Tor was in action.

Re: The Trouble with CloudFlare

#159
I would expect most of the malicious traffic coming out of Tor isn't using Tor browser. I wonder what the attack numbers look like for Tor browser vs not Tor browser. Cloudflare has client side checks already, which could be extended to check whether the browser is Tor browser, and if so, don't block it.

Re: The Trouble with CloudFlare

#160
post #145

The main problem with CloudFlare is how dumb their "protection" is. It doesn't make sense at all to block Tor users from just accessing read-only content, like CloudFlare does today. Forms/login pages/comment boxes etc should be protected of course, and most people wouldn't have anything against solving a captcha for logging in, but preventing people from just reading stuff anonymously/securely is borderline evil fro…

This was addressed in CloudFlare's blog post: > One suggestion has been that we treat GET requests for static content differently than we do more risky requests like POSTs. We actually already do treat more dangerous requests differently than less risky requests. The problem is Tor exit nodes often have very bad reputations due to all the malicious requests they send, and you can do a lot of harm just with GETs. Cont…

Hm, I didn't notice that part and I hadn't thought about ad click fraud and vulnerability scanning.

Preventing content scraping for publicly accessible content is kind of dumb and impossible in my view anyway though. For the few that care about making scraping more cumbersome the option should be there to enable the captchas, but I don't think it should be a default.

Ad click fraud is a harder problem to figure out, but should be a issue for the ad-networks to deal with and not the sites with the ads.

I'm torn about preventing vulnerability scanning. While I do it on my server using mod_security, it's also a form of "security by obscurity", which I'm not that much a fan of.

Anyway, disabling captchas completely should be a very visible option.

The protections on "dangerous GET requests" are probably only needed for a small minority of CloudFlare sites, so what should be the default setting becomes a question of what's most valued the most - safety for the many (making Tor usage easy and not cumbersome) or security for the few (who rely on the default settings protecting them from "niche" security issues).

I think making Tor usage easy by default would be best for the security of the web at large, but I can see why CloudFlare has different priorities.

Post reply on HN