The CloudFlare MITM

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.


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.

The Chameleon, first impressions

The Chameleon USB stick is advertised as a way to securely and transparently encrypt portions of a file-system by performing the actual encryption directly on the hardware device using a symmetric AES-256 key.

It’s pitched as an easy way to benefit from strong encryption for your sensitive data with the protection of a physical token. This sounded interesting, so I thought I’d give it a shot and report the results.

It didn’t go very far.

Chameleon supports Windows XP, Vista, and 7.

That was quick. None of us uses Windows so the hands-on review ended here.

Out of curiosity I kept reading the manual to find out that you can “duplicate” a lost Chameleon:

The dialog box of shame

The way it works is that when setting the Chameleon up you can provide it with a passphrase, from which the actual encryption key is derived. By doing so it limits the entropy of the key to the entropy of the passphrase. And for most users that’ll dramatically weaken the encryption.

People being really bad at generating randomness is something that you should know if you manufacture a secure hardware element.

Should encrypted data get stolen it would be possible to crack the key with the usual offline-cracking methods that enable attackers to break long and seemingly strong passwords.

Tools like the password haystack are very misleading when assessing the strength of a passphrase or a password. That’s because they don’t check whether your passphrase matches a common pattern or whether it has a meaning as a sentence for example. Such tools would be accurate only if the characters, or words, were chosen purely randomly.

Fortunately that can be fixed without changing the hardware: let the user provide a passphrase but mix it up with the output of a decent RNG, derive a 256 bit secret from it. That’s the secret that would need to be backed-up and from which the actual key would be derived.

This point is, incidentally, the very reason why brainwallets, unless done rigth, are a very bad idea from a security point of view.

If this got overlooked, what else did?

Malleability, not a problem for us

The issue of transaction malleability has been a prominent one during the last couple of weeks. It’s quite likely MtGox, and maybe others, suffered some losses because of it.

The core of the issue is that the ID of Bitcoin transactions can, under certain conditions, be changed. It is just the ID that can be changed though, not the transaction contents.

This has been exploited by some malicious users who managed to get some exchanges to send money multiple times for the same withdrawal request.

The reason for which this is not a problem for Bitcoin-Central is that we understand that it’s not wise to let an automated system send large amounts of money in irreversible transactions without constant human oversight.

We’re not immune because we have specific technical measures in place, we are immune because we track what we do, we can track what we do because we’re properly organized to do so. When you send a single transaction per day batching all the withdrawal requests it is much easier to not get fooled by a user who claims he didn’t receive his funds.

The security of an automated system also lies in the organizational procedures that are in place to ensure proper human oversight on sensitive actions.

It wouldn’t be very secure to let an ATM dispense gold ingots, it’s not very secure either to let an automated system send hard cash over the internet.