https://bugzilla.wikimedia.org/show_bug.cgi?id=33890
--- Comment #22 from Ryan Lane <rlan...@gmail.com> --- (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, currently. > > 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
