Is SSL and Compression never secure in nginx?

Robert Krüger krueger at
Tue Jul 28 08:13:37 UTC 2015

OK, thanks a lot for the feedback. That helped. I will try to find out if
one of the "fixes" applies to our case.

On Mon, Jul 27, 2015 at 7:35 PM, B.R. <reallfqq-nginx at> wrote:

> CRIME has been superseeded by BREACH, and it is in no way related to any
> specific Web server, but to the more general concepts of TLS-encrypted
> (gzip-?)compressed HTTP content (SPDY is fine).
> On the following website you will get all the details as well as a
> cheat-sheet list of ideas to mitigate it. Disabling gzip compression when
> encrypting HTTP content is one idea.
> ​The baseline is: nginx in itself has nothing to do with it.​
> ---
> *B. R.*
> On Mon, Jul 27, 2015 at 5:24 PM, Robert Krüger <krueger at>
> wrote:
>> Hi,
>> I am working in a project where a password-protected extranet application
>> is behind an nginx proxy using ssl.
>> Now I asked the admin to enable server-side http-compression because we
>> tend to have rather lengthy json responses from our REST api and they
>> compress very well and the performance gain would be significant. He
>> decline doing that, explaining that because of the CRIME vulnerability, it
>> is not a good idea to enable compression when using ssl with nginx. Is this
>> really always the case? Are there scenarios where the vulnerability is not
>> a problem? I am trying to understand this better to make an informed
>> decision because not using compression (encryption is a must) would incur
>> other costs (optimizations in the code) and I don't just want to waste that
>> time and money unless I have to.
>> Thanks in advance,
>> Robert
>> _______________________________________________
>> nginx mailing list
>> nginx at
> _______________________________________________
> nginx mailing list
> nginx at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list