7 ms·
> 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
by yajoe 13y ago
> 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.
[1] http://news.softpedia.com/news/Django-BREACH-Attack-Against-HTTPS-Can-Be-Used-to-Compromise-CSRF-Protection-373647.shtml http://news.softpedia.com/news/Django-BREACH-Attack-Against-...
[2] http://stacks.11craft.com/what-is-breach-how-can-we-protect-django-projects-against-it.html http://stacks.11craft.com/what-is-breach-how-can-we-protect-...
- elchief 13y agoGeneral. 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.
- yajoe 13y agoThanks. 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).