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;

What does the following header do?

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

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

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...

> 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).

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

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.

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

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

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.

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.

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.

> 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.

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.

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