Re:Nginx 1.5.10 released with SPDY 3.1 support
by BobVerg on Tuesday February 04, 2014 @01:23PM
(#7179257)
"spdy_headers_comp 7;" looks like huge overkill. It provides about 10% better compression ratio than setting 1, but two times slower.
[ Parent
| on HN ]
Re:Nginx 1.5.10 released with SPDY 3.1 support
by nodesocket on Tuesday February 04, 2014 @01:27PM
(#7179288)
I was wondering why by default it is 0/off. Are there issues with client/browser compatibility?
Re:Nginx 1.5.10 released with SPDY 3.1 support
by BobVerg on Tuesday February 04, 2014 @01:46PM
(#7179436)
It's because of CRIME vulnerability.
Re:Nginx 1.5.10 released with SPDY 3.1 support
by nodesocket on Tuesday February 04, 2014 @04:42PM
(#7180432)
More information about CRIME. http://en.wikipedia.org/wiki/CRIME_(security_exploit) For now, disabling SPDY header compression is the right approach. Security > Performance.
Re:Nginx 1.5.10 released with SPDY 3.1 support
by hobohacker on Wednesday February 05, 2014 @02:34AM
(#7182418)
Let's be clear that the original CRIME attack was against request header secrets. Therefore, disabling response header compression (as nginx defaults to) does not prevent that. SPDY/3.1 request header compression is a client-side choice, not server-side.
Re:Nginx 1.5.10 released with SPDY 3.1 support
by BobVerg on Wednesday February 05, 2014 @05:04AM
(#7182863)
CRIME attack isn't specific to request or response. If you pass secrets in response headers, then the attack can be performed against them.
Re:Nginx 1.5.10 released with SPDY 3.1 support
by hobohacker on Wednesday February 05, 2014 @11:47PM
(#7188784)
That's true, which is why I was careful to say in its original form :) Since the original attack was on cookies (request headers). To my knowledge, no other SPDY server defaults response header compression to off. But yeah, if your application does pass secrets in response headers, you should be careful.