Cloudflare do not appear to respect the GDPR.

I've escalated this to the highest levels of Cloudflare, but they just don't seem to be able to take any action. This is concerning.

Terence Eden is on Mastodon

@edent

@jgrahamc @Cloudflare Done. It was the email apologising for your most recent outage.

---

Sadly, John Graham-Cumming - the CTO - deleted his Tweet saying that he'd look into it. I assume that JGC doesn't like his personal data being misused. If only I were able to delete my personal data from Cloudflare, eh?

Luckily, the Internet Archive has a backup

Despite promising an investigation and a response from their Data Protection Office - I've received no assurance that they have respected my rights.

Timeline

At the start of August last year, I cancelled my Cloudflare account. I received confirmation from them that I was no longer a customer. My login was disabled. That should have been the last I heard from them.

Two months later, I received an email update about their privacy policy.

I complained on Twitter, and their CTO promised he'd look into it:

(Again, tweet deleted, but saved in the Internet Archive)

I never heard back from John. But one of his minions sent me this:

When we receive a request for account deletion, we may retain the email address on the account up to a year to ensure that we comply with internal policies and legal obligations.

*Pffft* Whatever. No mention of that is made in their privacy policy.

At the end of August this year - well over 12 months after I unsubscribed - I received another email from Cloudflare. This time apologising for their downtime!

Terence Eden is on Mastodon

@edent

Replying to @edentJust received more spam from @Cloudflare. With no unsubscribe link.
It has been more than a year since I asked them to delete my account.

You cannot trust Cloudflare with your personal data. pic.x.com/y3qkyagm81

---

There was no option to unsubscribe. I'm not a customer - but apparently I still have to receive emails from them.

I got a message from someone at Cloudflare who said that they have multiple customer mailing lists and they are rarely in sync with each other. They don't have a good idea of who they are sending emails to, or whether people have consented. I think this is unacceptable for a company of this size to be so lax about their GDPR obligations.

I asked Cloudflare to report this breach to the Information Commissioners Office, and I suggested that they may need to notify the SEC if they are expecting a large fine. They may also need to let investors know if they have misrepresented their customer numbers.

I asked JGC and Cloudflare PR for a comment - but they were not inclined to provide one. They said their DPO would get back to me last week, but I heard nothing.

At this point, I can only conclude that Cloudflare do not respect their users' privacy. Cloudflare has no idea who its customers are, nor how many they have. Cloudflare doesn't care about your data rights.

CLOUDFLARE’S PROMISE

Our mission to help build a better Internet is rooted in the importance we place on establishing trust with our Customers, users, and the Internet community globally. To earn and maintain that trust, we commit to communicating transparently, providing security, and protecting the privacy of data on our systems. Cloudflare's privacy policy

*bitter laugh*

I wonder how many people bought shares in their IPO based on inaccurate customer numbers?

Timeline

• 2019-08-04 I raised a support ticket to close my account.
• 2019-08-05 CloudFlare sent me confirmation that they'd removed my account.
• 2019-10-02 I received an email from CloudFlare "because I am a customer"

The ironic thing? It was an update to their privacy policy!

I can't log in to CloudFlare, and I can't reset my password. So they appear to have disabled my account. But, somewhere in their labyrinthine data warehouse, they still retain my email address and other information. They seem to think it's acceptable to call me their customer and continue to contact me.

Does it really take over 2 months to remove someone's data? If this message had been a physical bit of post, I'd get it - they're often prepared months in advance. But this is the Internet. We expect global giants with no legacy infrastructure to be able to instantly manipulate data.

I emailed their privacy team to find out exactly why they're still emailing ex-customers. After a month, I hadn't heard back from them. But a bit of public Twitter prompting got the CTO to respond.

A few hours later, I got this:

Sorry for the late reply about your issue. When we receive a request for account deletion, we may retain the email address on the account up to a year to ensure that we comply with internal policies and legal obligations. Per your account deletion request, we scheduled your account for deletion and it has not yet been purged. This is why you received the email about our updated privacy policy. Your account is scheduled to be purged from our systems and when that happens, you should no longer receive communications from us unless that email address is used to sign up for a new account.

Politely, I think that's bunkum. Their new privacy policy doesn't make any mention of retaining data for a year. I can't comment on the legal aspects, but I've never had another company continue to email me after they've "deleted" my account. Or are they saying I am still beholden to their policies even after I'm no longer a customer?

I can't help but wonder what other data are they holding hostage. How many of their "active" customers have "deleted" their accounts?

Upon registering with the Internet giant, users are encouraged to confirm their email addresses. So far, so standard. This is the confirmation message CloudFlare sends out:

Looks good! Hey! I wonder where that garish orange button goes?

WHAT!?! An http URl? Surely some mistake. Every baby-in-a-basket knows that we should use https everywhere.

No matter, I'll click on the raw link underneath. That's got an https at the start, right? WRONG!

Yup, the clumsy clowns at CloudFlare have managed to turn a secure URl into an insecure one. Bless.

Why do they do this? Because they want to track every click on their emails. Their statistics are more important than your security.

Why is this bad?

Links to http sites are not secure. That means your visit to that URl can be seen by your ISP and anyone else between you and your destination.

A user clicking on that insecure URl risks having their request intercepted. While an attacker can't log in using the data they've captured, they would be able to redirect the user and phish their details.

It gets worse!

Hey, at least email.cloudflare.com belongs to Cloudflare, right?

Well... Not quite. Visit it, and you'll find that it is run by Customer.io's edge event collection service.

Visit an incorrect URl like email.cloudflare.com/example and you'll be taken to Customer.io's site.

Basically, if Customer.io gets hacked, or goes rogue, they can start phishing all of Cloudflare's customers. Nice...

How to solve it?

STOP TRACKING EVERY LINK IN YOUR EMAILS!

Or, if you really have to - make sure your tracking server supports https and is controlled by you.

Disclosure timeline

I went through HackerOne in the vague hope of getting a tiny bug bounty.

• 2018-10-19 - Disclosed
• 2018-10-26 - Response from HackerOne asking for clarification
• 2018-10-27 - "We were able to validate your report, and we have submitted it to the appropriate remediation team for review."
• 2018-11-05 - Informed them that I indented to publish on the 19th. Received no objection.
• 2018-11-19 - Response from HackerOne "It looks like the problem has been solved and future emails will provide https:// verification links."
• 2018-11-20 - Published

All this has happened before...

This is an identical bug to the one I disclosed to Udacity who were kind enough to say thanks and send me some merchandising.

I've started using Better WP Security on my blogs. It automatically takes care of securing WordPress against the most common forms of attack. One thing it does particularly well is lock out people who repeatedly try an incorrect password to log in.

Additionally, I've also added CloudFlare to my sites. CloudFlare acts as a CDN - when people visit my site, they're actually hitting the CloudFlare service - CloudFlare caches my content, saving me bandwidth.

You can see where this is going, can't you?

That the IP address of CloudFlare! Due to my inability to perform homographic disambiguation I had repeatedly tried to enter the wrong login details in my management app (i.e. I thought the password had a capital I in it rather than a lower-case l).

All of a sudden, CloudFlaretly was locked out. No worries, I thought, I'll just go in to the database and remove the block.

Only, of course, I couldn't. My entire site was behind CloudFlare. CloudFlare couldn't access my site. Therefore, I couldn't access my site!

So, how to get out of this conundrum?

I could have changed the DNS records of my site to point back to my host - rather than CloudFlare - but that would have taken several minutes to propagate. Luckily, my delightful web provider VidaHost has a Cpanel console which isn't behind my domain names. From there, I was able to go into phpMyAdmin and access the Better WP Security lockout database - called "wp_bwps_lockouts". I found the offending IP address and removed it from the block.

That restored access, but how could I prevent it happening again?

CloudFlare offers Page Rules which allow you to disable CloudFlare for a partclar page, or set of pages.

Setting an exclude rule for

http://example.com/wp-admin

will stop CloudFlare from proxying and cacheing requests to your WordPress admin panel.

It's also possible to "pause" CloudFlare temporarily but that would have lead to a rather large load on my website.

Conclusion

What have we learned today?

• The unexpected interplay of two independent products can have an "interesting" effect on your service.
• Always have a backup plan for accessing your server.
• If someone is using a tool to automatically blacklist IP addresses, it's possible to provoke a Denial of Service attack by proxying requests through a critical piece of their infrastructure.
• Avoid ambiguous characters in passwords - or at least ensure you use a font which clearly shows the difference between Il1, O0, 5S, etc.
• Don't panic!