Live data from Hacker News

The Trouble with CloudFlare

blog.torproject.org

261–270 of 361 posts

Re: The Trouble with CloudFlare

#261

Earlier quoted context omitted.

The main point I took away from the article, that from one exit node many users originate. Some users are spammer. They contaminate the exit node IP. CF blocks an IP for spam, but does not remove the block after some time (when the spammer moved on).

The somewhat-faster way to reduce this annoyance (I've been hit by this) is to 'block'/captcha the offending IPs for a time (depends on whatever metrics CloudFlare think is best) then unblock it. At least this will reduce legitimate user's annoyance, instead of being blocked indefinitely My own experience: Tried accessing wikialpha from work LAN, 'blocked' by endless captcha (for a few months already) and opening the…

Given how much of TOR traffic is malicious (94%), what you propose would get all TOR traffic always considered malicious.

Re: The Trouble with CloudFlare

#262

Earlier quoted context omitted.

Thanks. Can I whitelist the whole internet (by using /0 perhaps?) using this method? I've seen people complaining about this issue on VPNs and such too.

You can whitelist CIDR ranges of /16 and /24 currently. So yes, you can to some extent whitelist everyone.

Yes, just add 65536 exceptions!

Re: The Trouble with CloudFlare

#263
post #166
post #152

Earlier quoted context omitted.

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…

So a single IP address can DDoS each page of a website for a little while before CloudFlare blocks them? That makes the whole protection pretty useless. I guess it would stop someone from brute-forcing password attempts, but that's not the only thing they're trying to protect against here.

A single IP can't "DDoS" anything.

Re: The Trouble with CloudFlare

#264

I [I'm CloudFlare's CTO] have been engaging with the Tor folks through their Trac interface here for about 6 weeks: https://trac.torproject.org/projects/tor/ticket/18361 and been very open about CloudFlare is addressing this. My plan is to continue to do so through that ticket as I've made various commitments there (some of which, like whitelisting, we've already rolled out). It's worth reading the entire ticket to g…

Out of curiosity, did you also write the previous blog post from CloudFlare that sparked this reaction from Tor?

No, that was written by the CEO (eastdakota here). He asked me to copy edit it which I did. I wrote the conclusion (because he was sleeping) and I added the two charts.

On the CloudFlare blog if someone's name is on it they wrote it .

Re: The Trouble with CloudFlare

#265
post #74
post #69

Earlier quoted context omitted.

> I know Tor doesn't want to be in the network regulation business, but .... That is exactly why there is a Tor. Tor is for enabling anonymous communication. Now deciding who can do what or why would limit use and that would limit its ability to anonymous communication.

It's not a binary thing. You can regulate out fraud, abuse, and DDoS attacks without harming the legitimate use cases. It's like selling alcohol (cigarettes, porn, gambling), but not to minors. You can say "it's OK for this crowd not OK for this crowd". Otherwise you'd probably claim that said regulation would go against the very thing that the merchant is trying to do: make as much money as possible.

> It's not a binary thing.

Well the thing is how do you regulate totally anonymous users? How would you know what the binary 0 and 1 are doing in tor?

Re: The Trouble with CloudFlare

#266
post #230

Tor has acknowledged their "botnet problem" since at least 2013: https://research.torproject.org/techreports/botnet-tr-2013-1... That same paper walks through the challenges of dealing with it and doesn't find any satisfactory solutions. As I wrote in our post on the topic, there's a trade off between security, anonymity, and convenience. CloudFlare provides security to our customers. We believe in the importance of…

You still purposefully resolve spam domains on at least tim.ns.cloudflare.com and leah.ns.cloudflare.com and refuse do to anything about it. I see a certain hypocrisy in claiming to protect your customers, and at the same time enabling criminal operations through allowing them use of your infrastructure. (For the record and because you tell me this at every point of contact, I know your main business is reverse-proxy…

Yep and on top of that they have for years they have allowed DDoS 'booters' to stay online, with the claim of "we have no way to remove the content, we're just a reverse proxy." If they're not actually hosting it, they think it's OK for whatever it is to pass through their network.

http://www.crimeflare.com/damon.html

Re: The Trouble with CloudFlare

#267

Earlier quoted context omitted.

> The bad actor is the organization or person responsible for administering the network where the abuse is originating. The bad actor is the individual who acts bad. The Post Office is not a bad actor for delivering letters. > allow them to externalize the costs of their lack of enforcement Tor is not an enforcement agency. Neither is CloudFlare. The costs of bad actors are your costs. You have the technical ability…

Of course they're not an enforcement agency, that's kind of the point - there is no enforcement agency. We all have to contribute by being good citizens. I subscribe to the idea that it's an ISP's responsibility to police its own network for abuse and my responsibility to police mine. You apparently subscribe to the idea that it's my responsibility to just accept whatever shit you fling at me and it's my problem to d…

There are two ways to deal with badness. The first is to try to identify bad people and then stop them from doing anything whatsoever. The second is to identify bad acts and stop anyone from doing bad acts.

The second one is the only one that works without massive collateral damage.

Identifying bad people is only an abstraction over identifying bad acts and it leaks like a sieve. A reformed thief is entirely capable of buying an apple without incident, because not all acts by bad people are bad acts. But a thief has no reputation as a thief until after they steal for the first time. The only way to stop bad things is to detect bad things.

But the true failure of reputation systems is that as soon as multiple people share an identity they disintegrate entirely. Innocent people get blamed for malicious acts of other people through no fault of their own and with no ability to prevent it. The only way reputation systems can work at all is if people can prevent other people from using their identities.

Which means that IPv4 addresses can't be identities, because we don't have enough of them for them not to be shared.

And forcing common carriers to stop doing business with anyone who has ever done anything bad has another problem. It imposes the death penalty for jaywalking. You send spam once -- or get falsely accused of sending spam -- and you're blacklisted. It puts too many innocent people into the same bucket as guilty people and then the innocent people fight you alongside the guilty. It creates the market for these VPN services because too many servers are wrongly using IP addresses as identities. Then the bad people also use the VPN services and bypass your "security" because it was never security to begin with, so you block the VPN services which destroys those and they're replaced with others you haven't blocked. Meanwhile the real bad people also use botnets which are unaffected, so you aren't actually blocking the bad people, you're only blocking the one IP address that they share with the good guys.

You don't want this fight. Most of the people you're fighting are innocent. People need to learn to detect bad acts, not "bad IP addresses."

Re: The Trouble with CloudFlare

#268
post #253
post #248

Earlier quoted context omitted.

Is this a wording issue? > Akamai found that the "conversion rate" of Tor IP addresses clicking on ads and performing commercial activity was "virtually equal" to that of non-Tor IP addresses So when seeing actual web traffic things are identical. That only measures real web traffic. It doesn't measure all the SSH attacks, SPAM being sent, possibly checking for vulnerabilities and unpatched software/etc.

CloudFlare doesn't do anything other than web traffic. It's basically an nginx reverse proxy on steroids.

Oh, right. Well you still have automated scans for vulnerable servers on HTTP that don't try to really 'access' the website.

Re: The Trouble with CloudFlare

#269
post #260
post #247

Earlier quoted context omitted.

I think it's clear he understands how it works. > what you are saying goes against Tor's principals That's why it will probably never be cleaned up. That's also why more and more people will probably block access from Tor. CloudFlare says they get a 95% attack rate from it. A blog post the other day said FotoForensics gets about 91% attacks from Tor. No one is going to put up with 91% attacks for long. And if that me…

> I think it's clear he understands how it works. Agree to disagree :) > if that means Tor becomes it's own walled garden that doesn't 'interact' with the public internet, so be it Most websites are not using Cloudflare and have no idea how to block a range of ips. So no Tor is not going to become its own walled garden.

I work for a company that makes appliances to secure companies' networks.

I'm promise you that CloudFlare isn't the only group that offers to block TOR as an option (or just has it blocked by default).

Re: The Trouble with CloudFlare

#270

Earlier quoted context omitted.

You can whitelist CIDR ranges of /16 and /24 currently. So yes, you can to some extent whitelist everyone.

If I can only to /16s at the largest, I would have to add on the order 65k ranges to accomplish it... not exactly desirable way to spend an afternoon. Even via API I don't think they'd be too happy with me.

I agree, this is not the most efficient way to whitelist everyone, but my point was to outline you can whitelist whoever you want. Hopefully support for wider ranges will be added.
Post reply on HN