Enable SPDY header compression

[igrigorik]

# SPDY header compression (0 for none, 9 for slow/heavy compression). Preferred is 6.
#
# BUT: header compression is flawed and vulnerable in SPDY versions 1 - 3.
# Disable with 0, until using a version of nginx with SPDY 4.
spdy_headers_comp 0;

CRIME can be partially defeated by preventing the use of compression, either at the client end, by the browser disabling the compression of SPDY requests, or by the website preventing the use of data compression on such transactions using the protocol negotiation features of the TLS protocol. - source

Note that CRIME is an attack on request headers. All SPDY-capable browsers disable both the TLS protocol compression and SPDY request header compression. The server can compress its response headers - that's not a problem.

FWIW, Google's front-end servers use "6" for the compression setting.

[konklone]

That makes total sense -- thank you for clearing this up, @igrigorik! I'll update it.

[willchan]

Minor clarifications:

• It's the default usage of header compression in SPDY 1-3 that is vulnerable to the CRIME attack on the request headers. In response, FF disabled SPDY request header compression and Chrome hacked its zlib usage to avoid mixing sensitive and non-sensitive data in the same huffman groups. Request header compression is a client-side decision, and server-side settings will not affect that. It would only affect response header compression.
• It's possible for response headers to be vulnerable to the same attack, basically following the principles of the BREACH attack. Notably, similarly to how the BREACH attack applies to HTTP response bodies in specific web applications, you can have the HTTP response headers vulnerable if the same conditions are met (they are compressed, they reflect attacker controlled input in the response headers, and the response headers contain sensitive information). But this is fairly unlikely (although not outside the realm of possibility), therefore servers probably shouldn't outright disable response header compression by default. And yes, HPACK fixes this (HTTP/2 and SPDY 4+ use HPACK header compression).

TL;DR: in your nginx config file, you should probably use the default zlib compression level. And always be careful about reflecting user input anywhere in your web app.

[konklone]

And always be careful about reflecting user input anywhere in your web app.

Hmm, I feel like this is honestly too much to ask our developers to keep in mind across all of our apps. If turning off response header compression (for SPDY 1-3) means that there's no difference in our security state after adding a feature that shows user-provided input in responses, then I'd rather keep header compression turned off entirely.

[konklone]

All right, so between the two of you's explanation, I feel pretty good about it. I'll plan to enable response header compression, and close this issue when done.

[igrigorik]

@willchan @konklone good writeup by @ivanr on BREACH mitigation: https://community.qualys.com/blogs/securitylabs/2013/08/07/defending-against-the-breach-attack

Also, note that the attack applies to response bodies as well, not just headers.

[konklone]

Closing in favor of https://github.com/fisma-ready/nginx/issues/7 (better canonical repo than this).