> There are no known security vulnerabilities with HTTP/1.x's style of compression That's because HTTP/1.x only supports compressing response bodies

You are completely wrong. The BREACH attack showed that you can be vulnerable to a compression oracle by merely compressing response bodies: http://breachattack.com/

> For the love of god, keep using compression with your websites, whether HTTP/1.x, TLS + HTTP/1.x, or HTTP/2

You can continue compressing files such as CSS that don't reflect any attacker-controlled content, but compression of dynamic HTML pages is likely to be insecure.

It's quite depressing that we can't have both compression and encryption at the same time - text is very compressible - particularly HTML markup...

Theoretically, you can, as long as any secrets within the response body are represented as a "literal" (that is, uncompressed) within the compressed stream.

In practice, there isn't a way I know of to mark the relevant parts of the response body so that the compression, which is usually done as a separate post-processing step, will know to avoid compressing these parts of the stream. And it would be very fragile; forgetting to mark a secret as "do not compress this" would work perfectly fine but reintroduce the vulnerability.

Simply enough in HTTP2: lift out the relevant parts of the response body—turn them into separate resources and refer to them in the original object by their URL. When the client then requests those dependent objects, deliver them uncompressed. (And server-hint/push the dependent objects if you can, of course.)

Could the order be reversed, encrypting first then compressing second?

So only compress when sending over the wire?

You could, but you wouldn't compress much.

Encrypted data is supposed to look random, and as a consequence, it tends to compress very poorly.

Interesting. I was afraid that'd be the answer. Thanks for the reply.

You can with HTTP/2.

so I have gzip compression specified in my nginx config and I use SSL for everything.

Is my server vulnerable to this?

Your app is vulnerable if it includes content from the user (e.g. a GET query parameter or something from a POST request body) in the response, and includes secret info (e.g. an anti-CSRF token) in that same response.

Wow, that's scary. I imagine quite a lot of people are unaware of this.

I personally use SSL on my personal site just because I like the idea that readers can be sure the content is what I've sent, rather than because the information is private / sensitive. So I'm not personally concerned because this doesn't allow anyone to MITM the connection, just read it.

I suppose that adding a small random bit into the page could defeat this known-plaintext attack?

Not really. The theory behind the attack is that if the user-specified content is equal to the secret content, it will compress more effectively and have a smaller content length. The other content on the page doesn't really matter.

Adding data of random length will make the attack more difficult, but won't defeat it entirely. This is called length hiding.

See http://breachattack.com/ for a more thorough explanation by smarter people.

The attack depends on a secret to match a user-provided string enough for the compression algorithm to notice this redundancy?

A counter-measure then would be to scramble the user input in the page with a random key, and include this key into the page for de-scrambling using JavaScript. It will still efficiently compress the parts of the page which are not user-controlled.

Yes and Yes (assuming your random key isn't guessable).

breachattack.com suggests masking the secret with a per-request random key, but masking the user input would work too.

> de-scrambling using JavaScript

No thank you.

ahhhh! Thank you I had completely forgotten about BREACH and was fixated on CRIME