> Don't forget to disable TLS compression and HTTP compression for pages containing session ids or CSRF tokens.
Dumb question: Is this general advice or is it specific to django due to the "BREACH" [1][2] https attack? It's not clear if it the underlying flaw is in using a CSRF token or something specific to django's implementation. I had never heard this before, so thank you.
General. Don't use TLS compression or HTTP compression for any information you want to keep secret. BREACH and CRIME attacks exploit this.
You can still use, say, HTML minification.
You can compress your js and css as long as you make sure you aren't sending your confidential information in those request/response headers. A good way to do this is to setup a subdomain for media that never uses cookies.
Thanks. We've been segregating authenticated vs non-authenticated traffic to different domains for a few years now (we had the same realization as moot), but I was unaware about this specific exploit related to TLS compression.
That said, it seems on nginx TLS compression was not enabled by default, so we are ok (for this known vulnerability).
You can still use, say, HTML minification.
You can compress your js and css as long as you make sure you aren't sending your confidential information in those request/response headers. A good way to do this is to setup a subdomain for media that never uses cookies.