News for hackers. Stuff that matters.
Re:Nginx 1.5.10 released with SPDY 3.1 support by bungle on Tuesday February 04, 2014 @12:48PM (#7179022)
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;
Re:Nginx 1.5.10 released with SPDY 3.1 support by nodesocket on Tuesday February 04, 2014 @01:13PM (#7179196)
What does the following header do?

    add_header                    Alternate-Protocol  443:npn-spdy/3;
Also, what exactly does deferred do on the listen directive?
Re:Nginx 1.5.10 released with SPDY 3.1 support by conductor on Tuesday February 04, 2014 @01:58PM (#7179517)
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...

Re:Nginx 1.5.10 released with SPDY 3.1 support by elithrar on Tuesday February 04, 2014 @06:50PM (#7181032)
> 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).

Re:Nginx 1.5.10 released with SPDY 3.1 support by nly on Tuesday February 04, 2014 @12:51PM (#7179048)
Any specific reason why you went for an STS timeout of 6 months?
Re:Nginx 1.5.10 released with SPDY 3.1 support by pixl97 on Tuesday February 04, 2014 @01:30PM (#7179316)
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.
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.
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.