A few days ago, Cloudflare reverse proxies were found to be leaking personally-identifiable information contained in requests handled by these proxies, into the data of other requests going through them, provided these other requests met certain conditions. This information included cookies, passwords, authentication tokens and encryption keys, and to make matters worse, it had already been cached by multiple systems, including Google’s web cache. See the Google’s Project Zero report, and also Cloudflare’s blog response. People have also compiled lists of websites that might be affected.
We use Cloudflare’s DNS hosting service on some of our websites. However, these are not directly affected by this security problem, because we never used Cloudflare’s reverse proxy features – and, most importantly, not during the “greatest period of impact”, which according to them, was between February 13 and February 18. Cloudflare’s DNS hosting was not affected by this issue. In addition, earlier today Cloudflare sent us an email, assuring that the domain for which we have DNS hosted by them “is not one of the domains where [they] have discovered exposed data in any third party caches”.
Still, if you used your dotAccount password on any other sign-in system, we heavily recommend that you change it immediately. Even though your password was certainly not leaked when in transit to our websites, it could have been leaked when signing in to other websites behind Cloudflare’s proxy service. From on now, use different passwords for each website.
Despite using some of Cloudflare’s services, we have always made a conscious effort to avoid their reverse proxying offers. While it is true that a large percentage of today’s web traffic goes through them, it is our understanding that the advertised increase in website availability and speed, do not make up for the potential security troubles and the need to trust yet another party.
Furthermore, a large part of the traffic handled by us, namely with the tny.im shortener, is not well-suited to caching, or would be hard to integrate with Cloudflare, to say the least. Any security or availability problem affecting Cloudflare will almost certainly affect all of the websites that use it, as could be seen with this incident.
It is also our belief that having a major portion of internet traffic going through one same entity poses a threat to the decentralized model of the internet, introducing a prominent single point of failure. This is true especially when said entity sells caching and request manipulation as one of their main features (see their “ScrapeShield” feature).
Their DNS hosting service was not affected by this issue, but it has had its share of availability issues in the past. We use it mainly because it is one of the few that can be controlled through an API, but we don’t need this at the moment. Migrating to another DNS hosting service is a possibility that was already being studied before this news broke, and which will now be considered more seriously.