EDIT 13/05/2014 : I didn’t know it when writing these lines, but Cloudflare was actually hacked a little while ago, this makes the following only more relevant.
A trend we’ve seen in the last couple years in the Bitcoin ecosystem is the usage of various DDoS protection services such as CloudFlare and Prolexic.
The way these services work is that they sit between the internet and the website to protect and “filter” the malicious packets and only let “legitimate” requests through. That’s usually referred to as a “Man-In-The-Middle”, or MITM.
Currently CloudFlare seems to be the most popular, so we’ll use it as an example, but the arguments apply just as well to any similar service.
In addition to DDoS mitigation, CloudFlare provides websites with a bunch of additional goodies: CDN, analytics, first level WAF, service of static pages when the website is overloaded etc. All these features make it a pretty popular choice for a lot of websites.
Using CloudFlare has some downsides though, especially if you handle sensitive data, such as financial data, and even more sensitive data: Bitcoin-related information.
What could possibly go wrong?
For an SSL-protected website, using CloudFlare has major security implications. When your website is secured with an SSL certificate CloudFlare requires it do be able to do its job. In other words, all your traffic transits in clear through the CloudFlare servers. If your trade is organic cupcakes, you probably won’t care. If you’re CTO at Bitstamp, then keep reading.
It wouldn’t be that bad if you handed over your SSL certificate to some random guy on the internet, because that guy would still have to manage to listen to your connections. In the CloudFlare case it’s much worse, you’re voluntarily setting up a permanent MITM, and giving the attacker all the cryptographic keys to decrypt your traffic on the fly on the way in, and alter the response on the way out.
Just a couple of things that can be done easily, and with the assurance of not being detected, if one can access the unencrypted channel:
- Your passwords could be sniffed,
- your sessions could be hijacked (and 2FA won’t help),
- your identification documents could be stolen,
- a foreign government could subpoena CloudFlare
A big part of the problem is that most of these attacks would go undetected, and that they could be performed selectively. There would also be no way to relate an account getting mysteriously compromised to a password having been leaked at CloudFlare.
Conclusion
This reality won’t change no matter how much marketing talk is poured over the issue, by using DDoS mitigation you’re allowing someone you don’t know to look at your unencrypted traffic.
And that’s why, at Bitcoin-Central, we don’t use CloudFlare.
Paymium 
Reblogged this on mashime.
One bit of criticism here: “By using DDoS mitigation you’re allowing someone you don’t know to look at your unencrypted traffic” is a misleading statement. This only applies to reverse-proxy-type DDoS mitigation, such as the ‘mitigation’ that CloudFlare offers. If you’re using for example a standard GRE tunnel from a provider such as JavaPipe, X4B, etc., this is not a problem – as far as the mitigation system is concerned, it’s filtering arbitrary TCP or UDP data.
It is absolutely correct that this applies only to certain types of DDoS mitigations.
The DDoS mitigation services you mention perform weakly against “smarter” DDoSes, and that’s why it’s CloudFlare et al. that you actually see in the wild.
Filtering arbitrary data is mostly the problem of the people in charge of the infrastructure, for all I know my website could be behind such a thing without me knowing about it.
CloudFlare DDoS mitigation is actually fairly rare in the wild – the Free and Pro plans do not come with any explicit DDoS mitigation, they just act as a pincushion for SYN floods (due to the way it works). If I had to make a completely statistics-less guess, GRE-tunnel-type and dedicated appliance DDoS mitigation would be far more common in the wild – it’s just not as obvious as CloudFlare being inbetween.
It’s also important to point out that DDoS mitigation appliances work using pattern recognition (which is why they can filter nearly all attacks without knowing what data is being sent), and that this takes a lot of processing power (which is exactly why dedicated appliances exist for it). Unless you are paying for it, it’s almost certain that you’re not behind a real mitigation appliance or tunnel – they are quite expensive.
Agreed. CloudFlare is a horrible trend in the Bitcoin space. Many major exchanges use it. Even Blockchain.info uses it! Inexcusable!
cloudflare-watch.org/honeypot.html
I appreciate the write up, but 5 days before this article was written Cloudflare started offering Full (Strict) SSL, where traffic between Cloudflare and the origin server is encrypted AND the origin server’s cert is validated.
It’d be nice if you update the article to keep people informed. Cloudflare is the poor man’s best option for DDoS protection, even if a rudimentary one.
No, that’s marketing bullshit, it doesn’t address the issue at all.
In some cases no protection is better than cloudflare protection
Tilera and Abor do the job nicely thanks, you can stick CloudFlare where the sun dont shine, im more a fan of edgecast and it probably the reason we use all three.
It is definitely a single point of failure and this was visible during Heartbleed panic. CloudFlare was lucky to get a hint before others, but not everyone was and as result you could sniff WemineLTC’s traffic mixed with large UK retail bank’s traffic just because both used Incapsula cloud provider (see http://ipsec.pl/ssl-tls/2014/why-heartbleed-dangerous-exploiting-cve-2014-0160.html)