AnsweredAssumed Answered

SSL/TLS BREACH vulnerability CVE-2013-3587

Question asked by Michael Peters on Sep 5, 2015
Latest reply on Sep 8, 2015 by Ivan Ristić

It was brought to my attention that my librelamp.com host is vulnerable to BREACH.

 

I downloaded the testssl.sh utility that was used, and it appears that any TLS connection that uses gzip compression on the server will be flagged as vulnerable.

 

I looked at the vulnerability itself, and it appears that actually is not the case.

 

For static content like images, or for dynamic content that is not user specific, it doesn't matter. The content being sent isn't secret so using BREACH to discover it is moot, you can discover the content by just doing a request to the the URL itself.

 

So for that kind of content, disabling gzip compression on the server only bloats the response, it does not actually add any security.

 

Where there may be an issue is things like session cookie data, CSRF tokens, and any other content that is generated specifically for the specific user making the request. However even then to pull it off, it appears that the attacker must be able to inject content into the request the client is making. This requires some type of an XSS/CSRF attack is taking place.

 

If the server is using a sane Content-Security-Policy then the user, at least with modern clients, should be protected from XSS/CSRF attacks taking place unless the client's implementation of CSP is severely broken.

 

So while disabling gzip compression would take away the potential attack vector, at the cost of larger responses from the server, sending a proper CSP header makes it a client issue and not a server issue.

 

Is my assessment correct?

Outcomes