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.
