Is SSL and Compression never secure in nginx?
mdounin at mdounin.ru
Mon Jul 27 17:34:14 UTC 2015
On Mon, Jul 27, 2015 at 05:24:21PM +0200, Robert Krüger wrote:
> 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:
More information about the nginx