Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have read so much on all this but not entirely sure I understand what has gone on.

Also, is this one, two or three problems?

It looks to me like three, but it's all very confusing:


It seems the solution may be to simply not use compression with HTTPS traffic (or is that just on one of them?)

I use GZIP compression. Is that okay, or is that part of the problem?

I also use Ubuntu 12.04 LTS

Also, is non-HTTPS traffic okay?

So after reading all the theory I just want the solution. I think this may be the solution, but can someone please confirm I have understood everything so I am not likely to suffer from this attack:

SOLUTION: Use GZIP compression on HTTP traffic, but don't use any compression on HTTPS traffic
share|improve this question
up vote 5 down vote accepted

CRIME and BREACH (note there's an "R" in there) use TLS level compression to "leak" information about the encrypted data. Very shortly: If you can control part of the data stream and send different data, when you send data that is the same as part of the stream that you do not control the output will be smaller (as compression will de-duplicate them) and you'll know the contents of the part that you don't control.

BEAST takes advantage of a flaw in CBC encryption in TLS 1.0. It's mostly impractical, but a demonstration exploit has been created and definitely works. There are two potential fixes for this, disable CBC Encryption (which includes basically all "good" encryption for TLS, leaving you with RC4 which has vulnerabilities of it's own, including leaking plaintext) or disabling TLS 1.0 and using only TLS 1.1 (or newer, ie 1.2).

The attacks are mostly impractical, but if you're in a high security environment (like PCIDSS or EHR) you'll need to disable TLS Compression and TLS 1.0 CBC Encyrption. The TLS Compression is completely separate from content compression (ie Deflate and GZip). As of the latest stats, about 2/3 of HTTPS Servers are "vulnerable" to BEAST, about 1/6 to CRIME. Keeping things in perspective, 1/3 are vulnerable because they're running a stupid configuration that doesn't properly protect data at nearly any level.

In response to your comment: What are commonly marketed as "SSL Certificates" are actually x509 Certificates and have nothing to do with SSL other than being used by the protocol. When you're getting a Cert, make sure it's either 2048 or 4096 bits (the former is very common) RSA or 384+ bit ECDSA. Certificates use asymmetric encryption, which is horridly slow - for that reason their not used to encrypt the data transported over SSL/TLS. They're used only for agreeing on a key for the stream cypher to use.

Common stream cyphers are RSA, RC4, Camellia, and DES/3DES. This is where you run into the 64-bit, 128-bit, 256-bit encryption - it's the key size of those stream cyphers. RSA is the "best" of the widely supported cyphers from a SysAdmin's viewpoint - but it suffers from the CBC issue in the BEAST attack above. RC4 "leaks" plaintext. Camellia is pretty great, but not universally supported, so you can't rely it in a public environment. DES/3DES is broken and shouldn't be used anymore, ever.

You're essentially stumbling over the same issue as millions of others: The choice between universal support and functional security. You can't have both right now. Disabling TLS Compression is a bit of a no-brainer in my opinion, as content compression makes up most of the difference - thus little cost for "fixing" the problem. But the stream cypher choice is pretty much: implement flawed security with RC4 or AES, or require TLS 1.1+ and break your website for half the Internet.

Footnote: Don't worry, this will all seem like spilled milk when quantum processors hit 128+ bits and make cracking "SSL Certificates" trivial. We're probably less than 10 years away from that, currently at 4-bits.

share|improve this answer
Thanks for what is obviously a top answer. Based on your comments, plus some other research and also the fact most sites still use TLS 1.0 (I tested a banking site and also and also that many mobiles won't support TLS 1.1 yet, I believe I will take the following action (please advise if I am wrong): "Get a top quality 256-bit SSL certificate and follow all best practices for the server OS to ensure the best security, and there's not much else you can do in reality for most use cases". I follow this for my Ubuntu 12.04: - am I on the right track? – user2143356 Oct 18 '13 at 18:55
Moar info in updated answer – Chris S Oct 18 '13 at 20:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.