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.
Here is the basic config I'm using with it: