Should disable compression when using SSL about server-configs-nginx HOT 13 CLOSED

BREACH Attacks are not a threat for anonymous pages, since they contain no sensitive data and are publicly available for search engines to index.

BREACH Attacks only occur on sensitive data inside a logged in section, and such section is usually (99% of the time)* is handled by a session cookie. After 2016, a session cookie could protect from CSRF and BREACH attacks easily using the SameSite=Lax or SameSite=Strict cookie flags since all browsers now support this cookie flag.

It's important to understand that a breach attack runs from the user's logged in browser on a different browser tab. So the user could be logged into his www.bank.com, and he opens another browser tab in a domain www.evil-attacker.com. The site evil-attacker will have some javascript code running on the users browser accessing www.bank.com many times to try and identify sensitive info.

Using a Same-Site cookie flag will make www.evil-attacker.com unable to communicate with www.bank.com since the browser identifies Same-Site cookie, checks if the requests to www.bank.com are initiated by www.bank.com (the same site) or another site (www.evil-attacker.com). Once the browser identifies that www.evil-attacker.com is sending the requests, it simply avoids sending the session cookie of www.bank.com with the request and thus FULLY protects from CSRF and BREACH.

Reference: https://www.sjoerdlangkemper.nl/2016/11/07/current-state-of-breach-attack/

(99% of the time)*: What I meant here is that there is some new breed of developers that are - unfortunately - no longer using session cookies to handle authentication and instead using Browser Local Storage for tracking the session id in web applications which is advised against in OWASP security recommendations (due to the lack of the secure cookie flags like Same-Site not being available in Local Storage).

What's The Take Away?
GZIP is good. Leave it as is. Don't worry about GZIP being enabled on the webserver, protecting from BREACH attacks is not the responsibility of the webserver. BREACH attacks are the responsibility of the browser and browsers have become mature enough to handle it correctly using Same-Site cookie flags.

from server-configs-nginx.

Since it is becoming the standard to use HTTPS for sites, especially with Google ranking such sites higher and with Let's Encrypt use skyrocketing with no good reason to not encrypt these days. I think the default should be to disable it. Having an accidental performance drop on non HTTPS sites is better than HTTPS sites being accidentally vulnerable. Security > Performance.

from server-configs-nginx.

@Zumochi brings up a great point though, what about static asset only domains?
I run a node JS app behind an NGINX proxy. NGINX just serves static content, nothing is vulnerable there. Just have logos and product photos.

I am going to turn on GZIP for static.mydomain.io and keep app.mydomain.io uncompressed.

from server-configs-nginx.

CRIME exploits SSL/TLS compression which is disabled since nginx 1.3.2.

BREACH exploits HTTP compression. Disabling HTTP compression (aka gzip off) works but is unfortunately bad for performance. More complicated solutions are mentioned in Defending against the BREACH Attack and Wikipedia.

Not sure what to do, just wanted to add more context.

from server-configs-nginx.

You don't want 2 out of 10 visitors vulnerable.

If you have analytics for your site, you'll probably note that it's not 20% of your visitors.. The support you link to (unless much has changed since) is mostly unsupported by niche browsers or much older/outdated browser versions. Only the partial support with IE/Safari may be relevant to your audience, but statistically your site is likely to have a more favourable demographic with support.

from server-configs-nginx.

Turning gzip off isn't imo the best thing to do; it does eliminate the possibility for an attack, but because of the nature of the attack not all sites are vulnerable. As such doing that penalizes many sites to protect a few.

http://breachattack.com has a list of things you can do; better application design seems more appropriate but i need to read in more about it.

from server-configs-nginx.

Hey! Sorry for bumping such an old issue, but I would like to ask, wouldn't it be alright to add gzip compression to static content only (such as content marked in expires.conf)?
I think (but please, correct me if I'm wrong!) this wouldn't effect security because there are no secret values transmitted through such files.

from server-configs-nginx.

@basilabbas - thanks for the update.
I did decide to gzip activate all my domains/subdomains, previously I'd only done so for my static asset domain (static.mydomain.io).

from server-configs-nginx.

I stumbled upon a corresponding discussion about header compression in Nginx and the impact of BREACH and CRIME attacks: 18F/https#24

My conclusion

1. You should consider what kind of information your web server is processing. Do you handle sensitive user data and secrets or only simple static files and assets?
2. Like @AD7six already mentioned disabling the gzip compression module is in most cases not a very valuable option.

from server-configs-nginx.

I don't know much about this issue, but I'm surprised by the lack of activity here. Isn't the breach attack serious enough to warrant turning off gzip by default when using HTTPS?

from server-configs-nginx.

I just faced this, for my surprise, this isn't a topic with lots of interaction in the community ... i really don't know what to do, some people say it's fine to take the risks (depending of the content), some people say it's risky and some say it's really dangerous.

For instance, i'm gonna priorize Security over perfomance, but, it's an interesting point to keep looking further.

Also, to separate the static files on another domain is an awesome idea, well done @Zumochi

Thanks !

from server-configs-nginx.

https://caniuse.com/#feat=same-site-cookie-attribute ~81% global support. I'd prefer to wait to enable until that number becomes more practical. You don't want 2 out of 10 visitors vulnerable.

from server-configs-nginx.

Closing as inactive and perfectly covered by @basilabbas's comment #72 (comment)

from server-configs-nginx.