This whole post is ridiculous and comes off as some personal attack without much technical merit:
- Every big network company is at the mercy of government. Not sure what the point is here... so we should ban all big companies? Everyone from the ISP to the website host to the network equipment manufacturer can and might be compromised.
- Every CDN today is a reverse proxy and MITM is what they do. That's just how it fundamentally works. No magical way around this.
- CF supports websockets now in addition to HTTP(S) for every plan. If you need more protocol support than use a service specialized for that, CF clearly states that they don't focus on mail or game servers.
- Who cares if they do mitigation? What I want is my origin to be protected, that's it. If they soak it up with network capacity or have advanced processes doesn't matter to me.
- Free plans are free, so they have every right to kick you off if you consume too many resources and are getting DDOS'ed all the time. Pro plans also get plenty of protection, you have to be seriously under attack to have them contact you about it. And in that case, 200/month is probably one of the cheapest options considering most other hosts (like AWS) will be happy to bill you like crazy or just cant even handle it.
- The "under attack" option is supposed to pose problems, because you're under attack. It's pretty clear that it's not the normal mode of operation. Don't turn this on unless you really need it.
- Not sure what the issue is with having to whitelist bots with them. A whitelist approach is far better than trying to maintain an infinite blacklist. Also they are more advanced than simple IP filters, that approach stopped working a decade ago.
- Connectivity is not good, even in much of the western world, and varies widely between location, device, capacity, etc. Latency is a real physical limitation that can only be overcome by being closer to users. Try browsing a site in another continent that's not using a CDN and see what happens. Also CF is a CDN, not sure how "use a CDN" was an answer to this.
The only real criticism is their Flexible SSL option that doesn't encrypt the connection to the origin and this has been debated endlessly. I think their recent announcement of free origin certs are a way to improve this but ultimately it's a potential security risk and up to the website operator to understand.
We use CF because they provide DNS, CDN, SSL, free bandwidth, DDOS protection and better features than others for a single flat price. It works really well for us but it's about understanding how it really works and the trade-offs. If this doesn't work for you and your security or business needs, then use something else.
> - Every big network company is at the mercy of government. Not sure what the point is here... so we should ban all big companies? Everyone from the ISP to the website host to the network equipment manufacturer can and might be compromised.
Covered in the article.
> - Every CDN today is a reverse proxy and MITM is what they do. That's just how it fundamentally works. No magical way around this.
Nope. Covered in the article.
> - CF supports websockets now in addition to HTTP(S) for every plan. If you need more protocol support than use a service specialized for that, CF clearly states that they don't focus on mail or game servers.
How does them stating this make it not a problem?
> - Who cares if they do mitigation? What I want is my origin to be protected, that's it. If they soak it up with network capacity or have advanced processes doesn't matter to me.
But your origin isn't protected, that's the point. Only their servers are.
> - Free plans are free, so they have every right to kick you off if you consume too many resources and are getting DDOS'ed all the time. Pro plans also get plenty of protection, you have to be seriously under attack to have them contact you about it. And in that case, 200/month is probably one of the cheapest options considering most other hosts (like AWS) will be happy to bill you like crazy or just cant even handle it.
You're comparing to mitigation-less providers. Compare to providers that offer mitigation instead. Apples and oranges.
> - The "under attack" option is supposed to pose problems, because you're under attack. It's pretty clear that it's not the normal mode of operation. Don't turn this on unless you really need it.
It only poses problems for legitimate users, not the attacker(s). Covered in the article.
> - Not sure what the issue is with having to whitelist bots with them. A whitelist approach is far better than trying to maintain an infinite blacklist. Also they are more advanced than simple IP filters, that approach stopped working a decade ago.
Covered in the article.
> - Connectivity is not good, even in much of the western world, and varies widely between location, device, capacity, etc. Latency is a real physical limitation that can only be overcome by being closer to users. Try browsing a site in another continent that's not using a CDN and see what happens. Also CF is a CDN, not sure how "use a CDN" was an answer to this.
And CloudFlare doesn't actually make this better. Covered in the article. And no, CloudFlare is not a CDN - it's an Anycast proxy.
> The only real criticism is their Flexible SSL option that doesn't encrypt the connection to the origin and this has been debated endlessly. I think their recent announcement of free origin certs are a way to improve this but ultimately it's a potential security risk and up to the website operator to understand.
Still doesn't solve the problem, as covered in the article.
---
Did you actually read the article, or just skim it?
I read your article and replied to each major section. Nothing is "covered" as I've clearly stated the issues.
It seems like you fundamentally don't understand what a CDN is, how it works, how latency affects website performance, and have a strange idea of "mitigation" when in actuality most DDOS protection works exactly the same way. There's no difference between Fastly, CloudFront, MaxCDN or other companies doing the exact same thing, except that CloudFlare has a few unique features and you don't like them.
Here's a test: show me exactly how using Fastly in front of my webapp is different than using CloudFlare?
> I read your article and replied to each major section. Nothing is "covered" as I've clearly stated the issues.
I'll even quote the relevant sections for you.
> - Every big network company is at the mercy of government. Not sure what the point is here... so we should ban all big companies? Everyone from the ISP to the website host to the network equipment manufacturer can and might be compromised.
"And unlike every other backbone provider and mitigation provider, they can read your traffic in plaintext, TLS or not."
(Addendum: Compromising a server is much harder to do at dragnet scale than MITMing.)
> - Every CDN today is a reverse proxy and MITM is what they do. That's just how it fundamentally works. No magical way around this.
"Using a CDN means you can still optimize your asset loading, but you don't have to forward all your pageloads through CloudFlare. Static assets are much less sensitive, from a privacy perspective."
> - The "under attack" option is supposed to pose problems, because you're under attack. It's pretty clear that it's not the normal mode of operation. Don't turn this on unless you really need it.
"Oh, and about that "I'm Under Attack" mode that you get on the Free plan as well? Yeah, well, it doesn't work. But don't take my word for it - here's proof. That code will solve the 'challenge' that it presents to your browser, in a matter of milliseconds. Any attacker can trivially do this. And the challenge can't be made more difficult, because it would make it prohibitively expensive for mobile and embedded devices to use anything hosted at CloudFlare.
But while it doesn't stop attackers, it does stop legitimate users.
[...]
Some might argue that these kind of archival bots are precisely what CloudFlare is meant to protect against, but that's not really true. If that were the case, why would there be an offer to add ArchiveBot to the whitelist to begin with? Why would the Wayback Machine be on that very same whitelist?"
> - Not sure what the issue is with having to whitelist bots with them. A whitelist approach is far better than trying to maintain an infinite blacklist. Also they are more advanced than simple IP filters, that approach stopped working a decade ago.
"I've been told that ArchiveBot can be added to the internal whitelist that CloudFlare has, but this completely misses the point. Why do I or anybody else need to talk to a centralized gatekeeper to be able to access content on the web, especially if there might be any number of such gatekeepers? This kind of approach defeats the very point of the web and how it was designed!
And for a volunteer-run organization like ArchiveTeam, it's far more tricky to implement support for these "challenge schemes" than it is for a botnet operator, who stands to profit from it. That problem only becomes worse as more services start implementing these kind of schemes, and often it takes a while for people to notice that their requests are being blocked - sometimes losing important information in the process."
> - Connectivity is not good, even in much of the western world, and varies widely between location, device, capacity, etc. Latency is a real physical limitation that can only be overcome by being closer to users. Try browsing a site in another continent that's not using a CDN and see what happens. Also CF is a CDN, not sure how "use a CDN" was an answer to this.
"But perhaps you're also targeting users in regions with historically poor connectivity, such as large parts of Asia. Well, turns out that it doesn't really work there either - CloudFlare customers routinely report performance problems in these regions that are worse than they were before they switched to CloudFlare.
This is not really surprising, given the mess of peering agreements in Asia; using CloudFlare just means you're adding an additional hop to go through, which increases the risk of ending up on a strange and slow route.
And this is the problem with CloudFlare in general - you can't usually make things faster by routing connections through somewhere, because you're adding an extra location for the traffic to travel to, before reaching the origin server. There are some cases where these kind of techniques can make a real difference, but they are so rare that it's unreasonable to build a business model on it. Yet, that's precisely what CloudFlare has done."
> The only real criticism is their Flexible SSL option that doesn't encrypt the connection to the origin and this has been debated endlessly. I think their recent announcement of free origin certs are a way to improve this but ultimately it's a potential security risk and up to the website operator to understand.
"But let's pretend that CloudFlare realizes that Flexible SSL was a mistake, and removes the option. They'd then require TLS between CloudFlare servers and the origin server as well. While this solves the specific problem of other ISPs meddling with the connection, it leaves a bigger problem unsolved: the fact that CloudFlare itself acts as an MITM (man-in-the-middle). By the very definition of how their system works, they must decrypt and then re-encrypt all traffic, meaning they will always be able to see all the traffic on your site, no matter what you do."
--
So yes, it's all covered in the article. If you believe that something isn't fully addressed, or it somehow isn't accurate, or you don't understand how it relates to that - then ask concrete questions. Don't just throw your hands up in the air going "BUT IT DOESN'T COVER THAT!", when it clearly has.
> It seems like you fundamentally don't understand what a CDN is, how it works, how latency affects website performance, and have a strange idea of "mitigation" when in actuality most DDOS protection works exactly the same way.
No, it doesn't. From the article:
"Traditional DDoS mitigation services work by analyzing the packets coming in, spotting unusual patterns, and (temporarily) blocking the origin of that traffic. They never need to know what the traffic contains, they only need to care about the patterns in which it is received. This means that you can tunnel TLS-encrypted traffic through a DDoS mitigation service just fine, without the mitigation service ever seeing the plaintext traffic... and you're still protected."
> There's no difference between Fastly, CloudFront, MaxCDN or other companies doing the exact same thing, except that CloudFlare has a few unique features and you don't like them.
Again, straight from the article:
"While there are some newer providers that offer similar services to CloudFlare - and I consider them bad on exactly the same grounds - they run on a much smaller scale, and have much less impact."
> Here's a test: show me exactly how using Fastly in front of my webapp is different than using CloudFlare?
When did I ever claim it was? If it works the same, it's prone to the same issues. This is a complete strawman.
- Every big network company is at the mercy of government. Not sure what the point is here... so we should ban all big companies? Everyone from the ISP to the website host to the network equipment manufacturer can and might be compromised.
- Every CDN today is a reverse proxy and MITM is what they do. That's just how it fundamentally works. No magical way around this.
- CF supports websockets now in addition to HTTP(S) for every plan. If you need more protocol support than use a service specialized for that, CF clearly states that they don't focus on mail or game servers.
- Who cares if they do mitigation? What I want is my origin to be protected, that's it. If they soak it up with network capacity or have advanced processes doesn't matter to me.
- Free plans are free, so they have every right to kick you off if you consume too many resources and are getting DDOS'ed all the time. Pro plans also get plenty of protection, you have to be seriously under attack to have them contact you about it. And in that case, 200/month is probably one of the cheapest options considering most other hosts (like AWS) will be happy to bill you like crazy or just cant even handle it.
- The "under attack" option is supposed to pose problems, because you're under attack. It's pretty clear that it's not the normal mode of operation. Don't turn this on unless you really need it.
- Not sure what the issue is with having to whitelist bots with them. A whitelist approach is far better than trying to maintain an infinite blacklist. Also they are more advanced than simple IP filters, that approach stopped working a decade ago.
- Connectivity is not good, even in much of the western world, and varies widely between location, device, capacity, etc. Latency is a real physical limitation that can only be overcome by being closer to users. Try browsing a site in another continent that's not using a CDN and see what happens. Also CF is a CDN, not sure how "use a CDN" was an answer to this.
The only real criticism is their Flexible SSL option that doesn't encrypt the connection to the origin and this has been debated endlessly. I think their recent announcement of free origin certs are a way to improve this but ultimately it's a potential security risk and up to the website operator to understand.
We use CF because they provide DNS, CDN, SSL, free bandwidth, DDOS protection and better features than others for a single flat price. It works really well for us but it's about understanding how it really works and the trade-offs. If this doesn't work for you and your security or business needs, then use something else.