Is SSL and Compression never secure in nginx?

[Maxim Dounin]

Hello!

On Mon, Jul 27, 2015 at 05:24:21PM +0200, Robert Krüger 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.

The CRIME attack only applies when you are using SSL compression, 
which is always off in nginx. 

There is a similar attack on gzip http compression, BREACH.  It 
only applies if you return sensitive data in a response with some 
user-controlled data, and compress them together.  Such attacks 
usually can be more or less easily mitigated by either not 
compressing sensitive responses (nginx allows to control gzip 
compression on a per-location basis) or implementing some rate 
limits (like limit_req).

See here for more details:

https://en.wikipedia.org/wiki/BREACH_(security_exploit)

-- 
Maxim Dounin
http://nginx.org/