Tag Archives: problem

… or not migrating to Cloudflare


Several days ago I wrote a blogpost about my Cloudflare migration. I have done a bit more research since then and unfortunately, there are a few nasty little snags that could really hurt your website if you use Cloudflare without considering some of the nastier implications of the way in which Cloudflare and similar services work.

Main issues

There are two main issues, as described by an interesting blogpost on the blog of Sven Slootweg. Sven is the former administrator of AnonNews.org, and a security researcher. He was also suspected of being part of LulzSec, a very high profile group of hackers. I’ve read most of his posts now and I take them very seriously.

What he states is basically that

  • CloudFlare offers services that are very insecure by default [1];
  • CloudFlare has a business model that depends on them being the “Man in the Middle” with access to a lot of traffic [1];
  • CloudFlare does not mitigate DDOS attacks, unless they are quite small and only affect your webserver [1];
  • Some other minor issues, which I’ll skip. You should read the references for things like issues with Tor [2], SEO rankings [3], website impersonation [4], etcetera, to determine whether they apply to you.

The main problem with the security is that while the user may consider his or her experience to be encrypted (by SSL), the path from CloudFlare to the origin server is not. Now, consider an enduser in a country with an oppressive government who uses your CloudFlare-fronted website. CloudFlare may have a local server in that country. Suppose the user visits a page on the governments blacklist and leaves a nasty comment. Normally, SSL would encrypt all traffic and the government couldn’t intercept the traffic and look inside it. Well, not unless they were using a bit more resources than a simple scanner. But with CloudFlare the traffic between the CloudFlare local server and the webserver hosting the incriminating page, that traffic goes over the border *unencrypted*. Ouch. In some countries, your user will not survive this experience. And the user isn’t even warned: the browser tells the user that everything is fine. Even an SSL test (https://www.ssllabs.com/ssltest/analyze.html?d=www.grundsatzlich-it.nl) will say so. But it’s not. Oh, and if you have a front-end that accepts credit card information, that information will *also* travel the entire internet unencrypted. Not as dangerous as the first scenario, but probably not something you’d like to see as someone using a webstore.

Now, you can actually use the option to also encrypt the traffic between CloudFlare and your server. Let’s just say it’s not the default and requires a bit more expertise than just “point and click”. However, it’s not that difficult. That still leaves CloudFlare as the single point where a lot of web traffic goes through – entirely unencrypted. Sven Slootweg comments that:

This may not sound that bad – after all, they’re just a service provider, right? – but let’s put this in context for a moment. Currently, CloudFlare essentially controls 11% of the 10k biggest websites, over 8% of the 100k biggest websites (source), and almost 5% of sites on the entire web (source). According to their own numbers from 2012(!), they had more traffic than several of the most popular sites and services on earth combined, and almost half the traffic of Facebook. It has only grown since. And unlike every other backbone provider and mitigation provider, they can read your traffic in plaintext, TLS or not.

And finally, the DDOS issue. CloudFlare uses a method that mitigates against DDOS attacks by putting up a front page that asks you to enter a CAPTCHA. Apart from the fact it blocks bots, even backup bots, this doesn’t actually stop any big DDOS attack against something other than your web pages since it doesn’t block attacks by inspecting the packets but just relies on the CAPTCHA and stands in front of you. Dedicated DDOS mitigation works by making sure the packets never reach the real servers – CLoudFlare actually lets the packets reach their servers and relies on having “enough servers”. Given the new threat environment with DDOS attacks now going up to 600 Gbit/sec thanks to the “Internet of (apparently quite insecure) Things”, this may not be enough. Certainly, for the money you have to pay for the mitigation service it’s probably more effective to pay a dedicated DDOS protection service. Since CloudFlare is also responsible for hosting many of the DDOS-service provider websites, paying them for DDOS protection feels a bit like paying protection money to the Mafia.

The verdict

If you use CloudFlare to avoid buying a real certificate to secure your blog on “Human rights in Russia”, or run a webstore that accepts creditcard payments on your own webpages instead of using a payment processor page, you’re opening your users up to huge risks. And pleading innocent is less and less an option now that this information is out there. You can actually get better protection but CloudFlare will always be a Man in the Middle. Sven’s blog lists a number of alternatives if you can’t accept that.

However, for websites like mine, it’s not a big deal to accept less security. After all, before I migrated to CloudFlare the entire site was in cleartext. It’s slightly more secure now than it was, and thanks to this information I will make it more secure in the near future by using a better certificate.

If you move to CloudFlare like I did, you need to carefully weigh the pro’s and cons – better than I did, at least – before moving. But for a lot of blogs it may still be a very good option. If however your webshop or political blog is hosted by CloudFlare, you’d better do some checking before you post or pay. When in doubt, do not enter.


[1] http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-problem/
[2] https://blog.torproject.org/blog/trouble-cloudflare

[3] https://salt.agency/blog/seo-rankings-cloudflare/

[4] https://scotthelme.co.uk/tls-conundrum-and-leaving-cloudflare/
[5] https://scotthelme.co.uk/cloudflares-great-new-features-and-why-i-wont-use-them/

[6] https://www.ssllabs.com/ssltest/analyze.html?d=www.grundsatzlich-it.nl