4 ms·

Ohhh boy. > Single-homed bandwidth can be gotten for $0.35/TB, DDoS mitigation services are plentiful and sometimes even provided by default, and the web is ge

by Veratyr 10y ago

Ohhh boy. > Single-homed bandwidth can be gotten for $0.35/TB, DDoS mitigation services are plentiful and sometimes even provided by default, and the web is generally Fast Enough. This only works when you're buying _a lot_ of bandwidth or you're buying cheap bandwidth (which usually has sub-standard routing). If you host your app servers on a standard cloud like AWS you're paying dollars per TB (but you're on a damn good network). DDoS mitigation services in many cases consist primarily of "we'll blackhole your IP if one happens". DDoS mitigation services that are affordable and leave your site running are costly. The web is _maybe_ generally Fast Enough when you're lucky to be on an ISP and network connection that gives you a decent path to wherever your content is hosted but that's not a given, particularly these days when the majority of most services' users are mobile, users are increasingly geographically distributed and consumer ISPs are increasingly hostile towards service providers (e.g. if your transit was through Cogent, Comcast's Netflix dispute may have interfered). > Essentially, there's not really a reason to use CloudFlare anymore, and the majority of sites won't see any real benefit from it at all. I'll go into the alternatives further down the article, but I want to address some of the problems that CloudFlare introduces first. You haven't provided nearly enough evidence to backup this statement. > Encryption Yes, like any CDN, CloudFlare needs to have access to your content in order to cache it. Like any CDN, if the connection between the edge nodes and your own servers is not secure, a hostile ISP can do whatever it wants with it. This isn't CloudFlare specific or even CloudFlare universal. This here is a fault in your backend service. CloudFlare offers you the option to encrypt that traffic and you've chosen not to. > In contrast, CloudFlare is just a reverse proxy with a very fast connection. Layer 3/4 attacks (those aimed at the underlying network infrastructure, rather than the application or protocol itself) will only ever reach up to the point where it's handled by a server rather than just passed through, and in a "reverse proxy"-type setup, that server is CloudFlare. They're not actually mitigating anything, it just so happens that they are the other side of the connection and thus "take the hit"! So what you're saying is that a DDoS isn't hitting my servers and my users still get their content? That's called DDoS mitigation. Just because it doesn't work the way you're used to doesn't mean it's not working. > Indeed it is essentially impossible to archive something that's in "I'm Under Attack" mode, despite that usually being the exact moment where archival is necessary! Preventing automated systems from making requests to your site when you're in the middle of a DDoS seems sensible enough. If it's truly necessary (and permitted), contact the site and ask for the IP of the backend. If your work is appreciated, they'll give it to you. As a site operator, if you want to archive my site, I'd rather you contact me. I'll give you my backend IP and hell, might even give you rsync access or something. Archiving through a browser is the least desirable way to have my stuff archived. > In most of the Western world, connectivity is pretty good. You can go from most places in the US to Europe and back - across the ocean! - in about 140 milliseconds. A commonly used metric in the web development industry is that your page and all your assets should be loaded in under 300 milliseconds. I'm located in Silicon Valley and a ping to Germany takes 172ms, a ping to Canada takes 90, a ping to Amsterdam takes 154 and so on. A ping to San Jose where my nearest CloudFlare/Akamai/everything POP is located takes 14ms. > Assuming you're declaring all the assets on your page directly, that would make it two roundtrips totalling about 280 milliseconds, since the assets can be retrieved in parallel. This is incredibly optimistic. Open up the Network tab in Chrome's dev tools and open Amazon, Facebook, even a WordPress blog sometime. Hell, HN's front page barely loads that fast. > CloudFlare can't cache the actual pageloads locally, because they are dynamic and different for everybody. This depends entirely on the content of the page. Not all content is dynamic. Blogs and news sites for example are largely static. Further, CloudFlare can cache the static _parts_ of the page and send only the dynamic content: https://blog.cloudflare.com/cacheing-the-uncacheable-cloudflares-railgun-73454/ https://blog.cloudflare.com/cacheing-the-uncacheable-cloudfl... > So why not just use a CDN? 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. CloudFlare is a CDN. Why not use CloudFlare as a CDN for your static assets? CloudFlare isn't making you turn it on for all your domains. You can totally turn CloudFlare on for static.mysite.com and leave mysite.com on your own server. > 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. This is the same for every CDN and like every CDN, you're relying on the CDN's internal network to get somewhere faster than your own would, and for the CDN's cache to eliminate the need even to do the round trip. If the content is already in Asia, the CDN doesn't need to make the request back to the origin at all. That eliminates entire intercontinental round trips and that's massive. > Unfortunately, all of these issues together mean that CloudFlare is essentially breaking the open web. Extreme centralization, breaking the trust model of SSL/TLS, a misguided IP blocking strategy, requiring specific technologies like JavaScript to be able to access sites, and so on. None of this benefits anybody but CloudFlare and its partners. No, you have opinions biased by (valid but not universal) philosophies and concerns. These features are desired and beneficial to many people. This is way too much text for me so I'll stop here. TL;DR: This article mainly complains about things that are common to every CDN, while demonising CloudFlare specifically for unknown reasons. The rest is mainly complaints about Under Attack Mode.

ffwd 10y ago
> Like any CDN, if the connection between the edge nodes and your own servers is not secure, a hostile ISP can do whatever it wants with it. Unless I'm mistaken, most regular small/medium sized users of CDN will use a 'plug n play' type CDN, where the CDN just pulls from the origin server via the public http, and in that scenario you can't really fake SSL if you didn't set it up on your server, and your users won't believe that they are browsing through https when on your site. Cloudflare changes this model and superficially tells the user they're using https, but then on the second link to cloudflare, it's unencrypted. Even worse, as we can see here and elsewhere, a lot of people explicitly sign up to cloudflare for SSL! That means most likely they didn't set up ssl on their server. > I'll give you my backend IP and hell, might even give you rsync access or something. Archiving through a browser is the least desirable way to have my stuff archived. Yeah but this is the most optimistic view of it all. If you are at all familiar with archiveteam and others, the main method for archiving web sites is through the public web site. For many reasons, site admins might not want to give access directly to their server, so the most atomic and simplest path is to simply crawl the web site, in order to 'get everything' (all the sites), as long as you don't flood the server with requests and such, which most don't do. > No, you have opinions biased by (valid but not universal) philosophies and concerns. These features are desired and beneficial to many people. So you don't have any worries about Cloudflare and the centralization? What about tor users right to privacy and how the capchas are completely insane? Cloudflare is unfortunately a huge pain in the ass and I'm not sure they can be trusted. There's no proof they are connected to any governments as far as i know, but they have now become this standard thing that everyone enables because it's free, and the surveillance possibilities are _vast_, even worse than cookies/advertising IMO because there is almost no way to circumvent it as a normal end user
- Veratyr 10y ago
  > Cloudflare changes this model and superficially tells the user they're using https, but then on the second link to cloudflare, it's unencrypted. Even worse, as we can see here and elsewhere, a lot of people explicitly sign up to cloudflare for SSL! That means most likely they didn't set up ssl on their server. This essentially pushes any MITM to CloudFlare's network, which is _usually_ better than the user's and so far has exactly one confirmed interception. This is a valid concern and could certainly be better but I believe eliminating the CloudFlare -> User vector from a potential attack is a good thing. > Yeah but this is the most optimistic view of it all. If you are at all familiar with archiveteam and others, the main method for archiving web sites is through the public web site. For many reasons, site admins might not want to give access directly to their server, so the most atomic and simplest path is to simply crawl the web site, in order to 'get everything' (all the sites), as long as you don't flood the server with requests and such, which most don't do. While I generally support archival efforts, making a large number of automated HTTP requests (you're archiving the entire site after all) while I'm in the middle of a DDoS is not appreciated, particularly if any of that content has to come from a database (because you're accessing old stuff that isn't in my site cache). This could make a barely tolerable DDoS completely take down my origin. > So you don't have any worries about Cloudflare and the centralization? What about tor users right to privacy and how the capchas are completely insane? Cloudflare is unfortunately a huge pain in the ass and I'm not sure they can be trusted. There's no proof they are connected to any governments as far as i know, but they have now become this standard thing that everyone enables because it's free, and the surveillance possibilities are _vast_, even worse than cookies/advertising IMO because there is almost no way to circumvent it as a normal end user Like I said, the philosophies and concerns have some merit but they're not universal. I have no issues with CloudFlare and "centralisation". If CloudFlare is shown to commit some kind of wrongdoing there's absolutely nothing stopping me from moving elsewhere.

by Veratyr 10y ago

ffwd 10y ago

> Like any CDN, if the connection between the edge nodes and your own servers is not secure, a hostile ISP can do whatever it wants with it. Unless I'm mistaken, most regular small/medium sized users of CDN will use a 'plug n play' type CDN, where the CDN just pulls from the origin server via the public http, and in that scenario you can't really fake SSL if you didn't set it up on your server, and your users won't believe that they are browsing through https when on your site. Cloudflare changes this model and superficially tells the user they're using https, but then on the second link to cloudflare, it's unencrypted. Even worse, as we can see here and elsewhere, a lot of people explicitly sign up to cloudflare for SSL! That means most likely they didn't set up ssl on their server. > I'll give you my backend IP and hell, might even give you rsync access or something. Archiving through a browser is the least desirable way to have my stuff archived. Yeah but this is the most optimistic view of it all. If you are at all familiar with archiveteam and others, the main method for archiving web sites is through the public web site. For many reasons, site admins might not want to give access directly to their server, so the most atomic and simplest path is to simply crawl the web site, in order to 'get everything' (all the sites), as long as you don't flood the server with requests and such, which most don't do. > No, you have opinions biased by (valid but not universal) philosophies and concerns. These features are desired and beneficial to many people. So you don't have any worries about Cloudflare and the centralization? What about tor users right to privacy and how the capchas are completely insane? Cloudflare is unfortunately a huge pain in the ass and I'm not sure they can be trusted. There's no proof they are connected to any governments as far as i know, but they have now become this standard thing that everyone enables because it's free, and the surveillance possibilities are _vast_, even worse than cookies/advertising IMO because there is almost no way to circumvent it as a normal end user

Veratyr 10y ago
> Cloudflare changes this model and superficially tells the user they're using https, but then on the second link to cloudflare, it's unencrypted. Even worse, as we can see here and elsewhere, a lot of people explicitly sign up to cloudflare for SSL! That means most likely they didn't set up ssl on their server. This essentially pushes any MITM to CloudFlare's network, which is _usually_ better than the user's and so far has exactly one confirmed interception. This is a valid concern and could certainly be better but I believe eliminating the CloudFlare -> User vector from a potential attack is a good thing. > Yeah but this is the most optimistic view of it all. If you are at all familiar with archiveteam and others, the main method for archiving web sites is through the public web site. For many reasons, site admins might not want to give access directly to their server, so the most atomic and simplest path is to simply crawl the web site, in order to 'get everything' (all the sites), as long as you don't flood the server with requests and such, which most don't do. While I generally support archival efforts, making a large number of automated HTTP requests (you're archiving the entire site after all) while I'm in the middle of a DDoS is not appreciated, particularly if any of that content has to come from a database (because you're accessing old stuff that isn't in my site cache). This could make a barely tolerable DDoS completely take down my origin. > So you don't have any worries about Cloudflare and the centralization? What about tor users right to privacy and how the capchas are completely insane? Cloudflare is unfortunately a huge pain in the ass and I'm not sure they can be trusted. There's no proof they are connected to any governments as far as i know, but they have now become this standard thing that everyone enables because it's free, and the surveillance possibilities are _vast_, even worse than cookies/advertising IMO because there is almost no way to circumvent it as a normal end user Like I said, the philosophies and concerns have some merit but they're not universal. I have no issues with CloudFlare and "centralisation". If CloudFlare is shown to commit some kind of wrongdoing there's absolutely nothing stopping me from moving elsewhere.