--- Comment #22 from Ryan Lane <> ---
(In reply to Gabriel Wicke from comment #21)
> So I guess this is waiting for a more up to date version of nginx at this
> point.
> (In reply to Ryan Lane from comment #16)
> > > Yeah -- the packaged build of Nginx that we are running in production was 
> > > not
> > > compiled with the requisite flag for SPDY support. But your broader point 
> > > is
> > > correct: it is pretty simple to do, and there is no compelling reason not 
> > > to
> > > do
> > > it, AFAIK.
> > 
> > Except that our infrastructure isn't really set up in an ideal way to use
> > SPDY. We use multiple endpoints, for instance.
> Do you mean us using several domains? Even just using it for the API and
> bits would already be a good step forward. We can optimize further down the
> road.
> > Can you use a shared SSL cache? 
> Can you describe what this is about?

Sure. Currently we use source hash in LVS to ensure a client always hits the
same frontend SSL server to ensure they always reuse the SSL session. This
works ok, but often leads to bugs. For instance, the monitoring servers don't
always detect errors, because they are always hitting the same nodes, subsets
of users see a problem while others, including us, don't, etc.. Also, it's not
possible to weight the load of different servers while using source hash, so
we'd really like to switch to weighted round robin.

Part of that is supporting an SSL session cache that spans the SSL nodes.
Apache has support for this. Stud has support for this. Nginx does not, so we
were considering switching away or adding it. Adding SPDY into this may change
things. Does it use the same cache as HTTPS? If we switch to something other
than Nginx, will it support SPDY?

Either way, this is actually a more important problem to solve than SPDY,

> > Does it properly support forward secrecy (can we roll the keys? we can't 
> > properly with nginx). Etc. etc. etc.
> As far as I can tell nginx supports forward secrecy. Can you describe the
> issue that you see with key rolling?

It's actually handled by openssl on initialization. So, until you restart nginx
the key isn't actually rotated. This is also a concern with using weighted
round robin load balancing, since we'd need to ensure the rotated key is
rotated across all the nodes as well. Apache keeps the rotated key on the
filesystem (and recommends using shared memory for this), so this is less of a
problem with Apache, but we have no way of handling this with nginx, except for
restarting the servers, which sucks.

Anyway, we can likely ignore forward secrecy for now since it's basically
worthless considering we're very vulnerable to traffic analysis.

You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list

Reply via email to