Is SSL and Compression never secure in nginx?

[B.R.]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150727/394fbe7a/attachment.html>