One of my projects, ancient-origins.net, gets 3 million views per month, so serving the page fast is an important element. Using the CDN of Cloudflare improved the speed significantly, reducing the page loading times to appropriate levels. Additionally their security features make sure to block attacks on our site.
Their CDN features, although good, still lack in speed in comparison to their competitors (e.g. Incapsula, MaxCDN, etc.).
I've been using it for almost one year.
No issues with the deployment. Their process is pretty simple and fast.
Yes, there were a few times when some of their CDN nodes would fail, creating serious speed issues with the site without any warning or notification from their side. Also, many times, even if our server is working properly, Cloudflare would report it as being down.
No scalability issues so far.
I would give them a 9/10. They respond pretty fast to requests.
Technical Support:I would give an 8/10 to their technical support. We haven’t had many issues, but when we do, it appears that sometimes they are not willing to look deeper into them to try and find a solution.
We used MaxCDN, but we switched to Cloudflare because MaxCDN lacks security features.
The initial setup is pretty straightforward and doesn’t require any technical knowledge, since everything is done on their site.
The implementation was done in-house, since it is a simple process.
This is difficult to calculate; however, improving the page loading speed always impacts the traffic on a site positively.
The original setup cost was zero, and the monthly cost is around $30 for three sites using the Business Cloudflare plan.
We evaluated MaxCDN and Incapsula.
If your budget is low, then Cloudflare is the only cost effective solution, at least to begin with. The best combination of CDN and security features at a low price. At a slightly higher budget, Incapsula may be a better solution especially since they provide a faster CDN and better security features.
CloudFlare is an incredibly advanced content delivery network (CDN) that offers boosts to the security and performance of your site. They act as a reverse proxy and shield your web server from exposure to the wider Internet. You get huge bandwidth savings and a reduction in the resources consumed on your server, so why have I just decided to 'go it alone'?
CloudFlare launched their beta in June 2010 and very soon after they followed with their official launch in September of the same year. Their free accounts come with many of the great features they offer and their blog makes for some really interesting reading. This all sounds like a match made in heaven but I recently found myself faced with the tough decision of leaving CloudFlare and losing their support. This meant having my domain name resolve directly to the IP of my server. Whilst that may sound like a totally normal prospect for most, after you've enjoyed the protection and security of having someone act as your doorman, it's a slightly daunting prospect. Not only would I lose their security, but I'd also be subjecting my server to the full force of any traffic aimed at my domain name.
Because CloudFlare act as a reverse proxy, a user's browser connects to the CloudFlare servers which then request the content from the host server on behalf of the user. This puts CloudFlare directly between you and your visitors, allowing them to cache content and protect your server by not allowing users to connect directly to it. This is fine when the site is loading over http but when you want to start loading over https, it brings up a few problems. There isn't really a requirement as such for me to serve content over https, I don't have user logins and the site doesn't serve sensitive or confidential data. For me, it was mainly about the learning process and showing that it can be done for free. If you head over to StartSSL and pick up one of their free SSL/TLS certificates, it will bear your domain name. This immediately presents a problem when the browser is not connecting to your server when a user enters that domain name into the address bar. Now, CloudFlare offer different solutions to this problem depending on which type of account you have. Their free accounts do not support any form of SSL, you have to step up to at least a Pro account ($20 a month) to get SSL support. At the Pro level, the account I used to have, you can enable SSL support and take advantage of the benefits of CloudFlare but serve over https instead.
Once you're on a paid account plan, you can enable SSL on your site with a single click thanks to CloudFlare's Flexible SSL. The CloudFlare servers present their own SSL certificate to the user so that the transfer of information between them is encrypted. From here, as the data travels from CloudFlare to the hosting server, you can use your standard SSL certificate issued by a CA, a self signed certificate, or, worryingly, nothing.
Once I started investigating the upgrade to a paid plan so that I could get SSL support, I was startled at the prospect of Flexible SSL. Here, we have a solution that seems to break two of the key principles of implementing SSL/TLS. When we visit a site and see https in the address bar, I think it's fair to say there are some assumptions that we could generally make and should be able to make. The SSL certificate assures us that the site we are connected to is the site we typed in the address bar, and that our traffic is encrypted during transmission to that site. Flexible SSL seems to break both of these principles. The certificate that is issued belongs to CloudFlare and not the site you're trying to connect to, and traffic on the other side of CloudFlare between their network and the host site is not encrypted. There is of course the option to move to Full SSL, you can even use a self signed certificate between CloudFlare and the host, but I imagine there are sites out there that don't. The ability to present your site over https when the full route is not encrypted seems to be a breach of the trust that the user places on the indications their browser is giving them. There is the argument that encrypting part of the transport layer is better than encrypting none of it. Anyone between the user and their nearest CloudFlare server, like an attacker on a local network or even their ISP or government, wouldn't be able to access their traffic, but after the CloudFlare server it's back into the wild without any protection. Given that it's really easy to create your own self signed certificate, or you can get a free one from StartSSL, I just can't see the requirement for Flexible SSL. The benefits of encrypting the first leg of the transport layer are far outweighed by the detriment of giving false impressions on securely transmitting data. If you're on a shared hosting plan that would be costly to upgrade to SSL support, or don't know how or can't implement it on your server, Flexible SSL is nothing more than an illusion of security that you're presenting to your visitors.
If you want to ensure that data is always encrypted whilst it's being transported, you need to enable Full SSL, which requires SSL on the host server. As I've mentioned, you don't need to pay for a certificate as you can use a self signed certificate or get one from StartSSL. Once that's installed and you enable Full SSL, CloudFlare will only communicate with the host using a secure transport layer.
Now we're up and running, all traffic will be encrypted during transit. Problem solved, right? Well, even though I was using Full SSL, I still had my concerns. Whilst CloudFlare are a trusted party in all of this, I didn't feel comfortable with the idea of having a man in the middle of my secure transport layer. That, and the certificate being issued to the browser still carried someone else's name. For most users, when you connect to a site and see https in the address bar, I think it's fair to say there would be an expectation they were talking to me, directly. Not only that, but there is still a point in the transport layer where data isn't encrypted, inside CloudFlare. I think CloudFlare apps are a prime example of this, allowing the ability to inject Google Analytics code into your pages for example. I want to be clear that this isn't a criticism of CloudFlare, the services they offer are fantastic, I just have my reservations when it comes to running your secure transport layer through a third party. For a site that loads over http no one can have a realistic expectation that someone else hasn't seen or altered your traffic during transit. The other problem with this is that CloudFlare never used to validate the certificate between them and the host. It would accept any certificate and go with it.
The lack of certificate validation has been recently resolved with a new feature announced by CloudFlare, Full SSL (Strict). This means CloudFlare will now validate the certificate presented by the host server. This came as quite a surprise to me as I was already using a valid certificate so just assumed that it was being validated and accepted by CloudFlare. As it turns out, I could have literally used just about any certificate I'd liked and it would have worked just fine. Not only that, but anyone could MiTM my perfectly valid SSL certificate, swap it out, and CloudFlare would have been just as happy. To me, their blog post should be more along the lines of 'we now do SSL properly' than 'hey we added a new feature'. Connecting to a host securely and then not validating the certificate means that you're not connecting to the host securely. If there was some way to pin a self signed cert in the CloudFlare control panel, this option would be perfectly acceptable, which is what I expected you should have to do if using a self signed certificate. As it turns out, there is no such option. Worryingly, the non-strict version of Full SSL will remain. CloudFlare are going to automatically switch everyone with a valid certificate to Full SSL (Strict), but for those that don't read the CloudFlare blog, I wonder if they will ever find out.
It is possible to get around the issue of serving your visitors a CloudFlare issued SSL certificate by upgrading to a Business or even Enterprise account. Starting at $200 a month for the Business account, or an average $5,000 a month for Enterprise accounts, you can upload your own certificate and private key to CloudFlare. Whilst your visitors are now being served with your own SSL certificate, I can't see the benefit this brings. The user, much like with the Flexible SSL option, is now under the impression that they're communicating with you directly and securely. Even if they check the certificate, they will see that it is issued to your domain and have no reason to suspect that their traffic isn't travelling directly to the host before being decrypted. To set this up requires the disclosure of your private key, something that in itself should highlight the kind of breach to transport layer security this causes.
One of my biggest concerns with coming out from behind CloudFlare was the impact it would have on my server. I'm currently using DigitalOcean (referral link) to host my blog and with the ability to rapidly scale the hardware capabilities of my VPS, I cautiously flipped the switch. Within the first hour it was immediately clear just how much of the demand on your resources CloudFlare can alleviate. I saw jumps in traffic at the network interface and CPU utilisation as soon as I hit the button. Whilst none of these increases were enough to cause any worries, it does provide evidence for the claims CloudFlare make about just how much they can save you in resource terms. At almost double the average daily bandwidth usage, I can say that CloudFlare were saving me about 45% of the bandwidth used by traffic hitting my site. This is from both their efforts in caching my content and serving it on my behalf, and traffic that they will have dropped and not allowed through based on it appearing malicious. I'm also seeing average CPU loads approaching double what they were, but still only falling well within the single digit range. As it turns out, my VPS is perfectly capable of handling the regular traffic my blog gets but I am still acutely aware of the greater exposure I now face. That being said, I feel the value of honouring the core principles of SSL/TLS to be worthwhile.
I know I mentioned it earlier, but I wanted to be clear that this isn't a complaint about CloudFlare. I still use CloudFlare to resolve my DNS queries as they run one of the fastest DNS services around. Thanks for that guys! Their free account offers an awful lot of functionality and savings alone, before you get on to the minimal $20 a month for a Pro account which comes with it's own great list of features. If you're hosting a site that serves content over http it's really a no brainer as to whether or not you should make use of a free CloudFlare account. If you're hosting a huge amount of content there's little reason not to use them. My only real problem comes with the introduction of SSL/TLS and the unavoidable requirement to have a man in the middle of your secure connection. If you truly have a requirement for a secure transport layer I have to question the sanity of breaking the chain of custody of your data.
I’ve been with CloudFlare for a year and a half at the time of writing this post and realized that I never gave it a review of any kind. What kind of terrible person am I?
I worked for a couple a few years ago who was using a content management system called Joomla to build their clients’ sites. We would launch a site by simply pointing the DNS settings to our servers and calling it good.
Then we started getting hacked. A lot.
With the number of sites we had on our server, the exploits found in the plugins being used, as well as poor server practices, we had a huge target on our chest.
A while later I decided to leave to company to go on to do other things. One of those things was to open my own web development and hosting shop.
First things first: Get away from Joomla.
Next: Learn WordPress.
Now let’s get a server setup.
The first thing I did when I got my server setup was make sure that no one was allowed to host on my server unless we ran all of the DNS through CloudFlare. No exceptions.
A couple of things I noticed when I got all this in place:
Most importantly: My sites never got hacked (fingers crossed).
I attribute the latter to a couple of things, but mostly I would like to think that CloudFlare had a huge part in that. If you don’t know what CloudFlare is, watch their promotional video.
Here’s some other cool stuff about this site from the last 30 days:
That’s pretty amazing stuff! I didn’t have to pay anything for better website security and reduced server load.
If you’re looking for the same, be sure to go get signed up at CloudFlare. It’s easy to setup and the results speak for themselves.
Devon, thank you for the great insight and facts.
-MG