Live data from Hacker News

Nginx 1.5.10 released with SPDY 3.1 support

nginx.org

21–29 of 29 posts

Re: Nginx 1.5.10 released with SPDY 3.1 support

#21

I'm still new to SPDY, although I'm going to check it out with this release. Are there any best practices or recommendations for running SPDY in production alongside HTTP?

Nothing comes to mind. It runs alongside HTTPS (not HTTP), and in my experience "just works" if a client supports it. In Nginx, its a simple flag flip in the sites-available file.

Re: Nginx 1.5.10 released with SPDY 3.1 support

#22
post #6
post #3

Nice, Nginx! Anyone know if this version of Nginx comes with SPDY enabled? If so can it be installed with SPDY enabled in binaries through package managers, and if not, should 1.5.10 be compiled using --with-http_ssl_module and --with-http_spdy_module in order to take advantage of this? If someone compiles 1.5.10 without that argument and then one day decides he wants to light up SPDY, does he need to recompile Nginx…

Just verified on my server and Spdy is enabled if you use the mainline package from: http://nginx.org/en/linux_packages.html#mainline You can check your Spdy connections in Chrome from this page: chrome://net-internals/#spdy

In the past, there have sometimes been configuration differences between the official packages for different OSes. I know SPDY is enabled on Ubuntu, but I'm not certain of all of the others.

Re: Nginx 1.5.10 released with SPDY 3.1 support

#23
post #14

Earlier quoted context omitted.

It's because of CRIME vulnerability.

More information about CRIME. http://en.wikipedia.org/wiki/CRIME_(security_exploit) For now, disabling SPDY header compression is the right approach. Security > Performance.

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

#24
post #3

Nice, Nginx! Anyone know if this version of Nginx comes with SPDY enabled? If so can it be installed with SPDY enabled in binaries through package managers, and if not, should 1.5.10 be compiled using --with-http_ssl_module and --with-http_spdy_module in order to take advantage of this? If someone compiles 1.5.10 without that argument and then one day decides he wants to light up SPDY, does he need to recompile Nginx…

Compiled 1.5.10 with ssl + spdy module and worked like a charm. On my SSL server blocks, I added `spdy` to the end of the listen string.

Re: Nginx 1.5.10 released with SPDY 3.1 support

#25

Earlier quoted context omitted.

More information about CRIME. http://en.wikipedia.org/wiki/CRIME_(security_exploit) For now, disabling SPDY header compression is the right approach. Security > Performance.

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.

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

#26
post #3

Nice, Nginx! Anyone know if this version of Nginx comes with SPDY enabled? If so can it be installed with SPDY enabled in binaries through package managers, and if not, should 1.5.10 be compiled using --with-http_ssl_module and --with-http_spdy_module in order to take advantage of this? If someone compiles 1.5.10 without that argument and then one day decides he wants to light up SPDY, does he need to recompile Nginx…

It's not enabled in the official packages for CentOS 6 :(

Re: Nginx 1.5.10 released with SPDY 3.1 support

#27
post #6

Earlier quoted context omitted.

Just verified on my server and Spdy is enabled if you use the mainline package from: http://nginx.org/en/linux_packages.html#mainline You can check your Spdy connections in Chrome from this page: chrome://net-internals/#spdy

In the past, there have sometimes been configuration differences between the official packages for different OSes. I know SPDY is enabled on Ubuntu, but I'm not certain of all of the others.

It's not enabled by default for CentOS 6. I've just checked.

Re: Nginx 1.5.10 released with SPDY 3.1 support

#28
post #25

Earlier quoted context omitted.

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.

CRIME attack isn't specific to request or response. If you pass secrets in response headers, then the attack can be performed against them.

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.
Post reply on HN