Nginx 1.5.10 released with SPDY 3.1 support

[jvt]

http://nginx.org/en/CHANGES?1.5.10

[d0ugie]

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 or is there a quicker solution? Thanks!

[bungle → d0ugie]

Yes, it works with their official packages, at least. Just updated today.

Here is the basic config I'm using with it:

  listen                        x.x.x.x:443 default_server deferred spdy;
  listen                        [x:x:x:x::x]:443 default_server deferred spdy ipv6only=on;
  spdy_headers_comp             7;
  ssl                           on;
  ssl_certificate               /etc/ssl/private/x.crt;
  ssl_certificate_key           /etc/ssl/private/x.key;
  ssl_trusted_certificate       /etc/ssl/private/x.trust;
  ssl_protocols                 TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers                   EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;
  ssl_prefer_server_ciphers     on;
  ssl_stapling                  on;
  ssl_stapling_verify           on;
  resolver                      8.8.8.8 x.x.x.x
  add_header                    Strict-Transport-Security "max-age=15768000; includeSubDomains";
  add_header                    X-Frame-Options   DENY;
  add_header                    Alternate-Protocol  443:npn-spdy/3;

[nodesocket → bungle]

What does the following header do?

    add_header                    Alternate-Protocol  443:npn-spdy/3;

Also, what exactly does deferred do on the listen directive?

[conductor → nodesocket]

This is from the section 3.3.1 of SPDY Protocol - Draft 2 [0]:

"When a server receives a non-SPDY request which could have been served via SPDY, it should append a Alternate-Protocol header into the response stream. Note that it is valid to have multiple Alternate-Protocols headers. The field-value can also be specified as a comma-separated list, as per RFC2616 section 4.2."

And you can read about "deferred" here: https://stackoverflow.com/questions/8449058/what-does-the-de...

[0] - http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...

[elithrar → conductor]

> And you can read about "deferred" here: https://stackoverflow.com/questions/8449058/what-does-the-de...

Thanks for the link; I'm curious as to the downsides however (the article linked in the article doesn't fully cover them), and a Google search doesn't yield anything concrete (i.e. deferred on vs. off).

[nly → bungle]

Any specific reason why you went for an STS timeout of 6 months?

[pixl97 → nly]

SSL Labs test will not give you a A+ rating if it is not set at least that long. HSTS headers should always be set for a long period of time to avoid a client that only rarely connects to a site having a MITM attack occur.

[BobVerg → bungle]

"spdy_headers_comp 7;" looks like huge overkill. It provides about 10% better compression ratio than setting 1, but two times slower.

[nodesocket → BobVerg]

I was wondering why by default it is 0/off. Are there issues with client/browser compatibility?

[BobVerg → nodesocket]

It's because of CRIME vulnerability.

[nodesocket → BobVerg]

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

[hobohacker → nodesocket]

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.

[BobVerg → hobohacker]

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

[hobohacker → BobVerg]

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.

[welder → d0ugie]

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

[mnordhoff → welder]

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.

[ShaneOG → mnordhoff]

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

[mfjordvald → d0ugie]

> 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 or is there a quicker solution? Thanks!

In Vanilla nginx said user would need to recompile yes. Do note that the make file contains an 'upgrade' target, though, which performs a seamless binary upgrade.

[givehimagun → d0ugie]

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.

[ShaneOG → d0ugie]

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

[fafner]

Just in time for Firefox 27 with SPDY 3.1 support https://www.mozilla.org/en-US/firefox/27.0/releasenotes/

[BobVerg]

There are official Linux packages with the latest version: http://nginx.org/en/linux_packages.html#mainline

[IgorPartola → BobVerg]

Don't see the latest version at http://nginx.org/packages, at least for Ubuntu. It's still showing up as 1.4.4.

[spindritf → IgorPartola]

It's here http://nginx.org/packages/mainline/

There are two branches: stable[1] and mainline[2]. The cool new stuff goes to mainline first.

[1] http://nginx.org/en/linux_packages.html#stable

[2] http://nginx.org/en/linux_packages.html#mainline

[grk → IgorPartola]

They're at http://nginx.org/packages/mainline/

[wiremine]

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?

[bitskits → wiremine]

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.

[vbtechguy]

Nginx SPDY 3.1 working fine at https://blog.centminmod.com/250 :)