Is SSL and Compression never secure in nginx?

[Robert Krüger]

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 yahoo.fr> 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.
> http://breachattack.com/
>
> ​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 lesspain.de>
> 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.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150728/7f1dff52/attachment.html>