yeah, the cluster wide ticket reuse is what we need in big site, and here is what we tried: https://cwiki.apache.org/confluence/display/TS/SSLSessionResumption, we planed that maybe a small trick on cluster cache is a quickly solution for that purpose.
FYI > 在 2015年2月5日，上午2:36，Leif Hedstrom <zw...@apache.org> 写道： > >> >> On Feb 4, 2015, at 11:15 AM, Susan Hinrichs >> <shinr...@network-geographics.com> wrote: >> >> As part of integrating in the fix for TS-2480, I'm finally getting my head >> around SSL session tickets and how ATS handles them. >> >> In part of my looking around the web while debugging it seems that there are >> some security concerns with session reuse in general and ticket keys in >> particular. The two major security concerns for ticket keys and PFS were >> * Server deployments don't rotate their ticket keys fast enough >> * Storing sensitive ticket key information on disk gives attackers another >> point of attack >> >> Question 1: Would it be valuable to give people the option in ATS to have >> ATS generate the ticket key information as an alternative to providing the >> ticket key information on the fly. This seems to be the Apache HTTP >> approach. They allow the specification of a file. Otherwise, the server >> will generate a ticket key on process start. This would be a very minimal >> change. I tried it out on my dev build this morning. > > > But that means that if you have 100 boxes behind an SLB VIP, your chance of > getting a ticket session reused is 1% ? That seems weak at best? > >> >> Question 2: Would it be valuable to implement a ticket key lifetime >> parameter? If set and if ATS is generating the ticket keys (see Question >> 1), ATS could regenerate the ticket key once it hit the lifetime. Also >> provide a parameter to specify how long you will allow tickets encrypted >> with the old key, e.g. Set a default of 22 hour key regeneration time with >> a 24 hour use time. >> >> Question 3: Would it be valuable to let plugins hook their own code to run >> during the session_ticket_key_callback? This would allow a deployment to >> override the standard ATS ticket key approach with their own. Potentially >> doing more clever ticket key sharing than just using the file system. Or >> implementing their own key rotation or generation scheme. > > Seems reasonable. > > > I’m somewhat skeptical on the usability in large deployments (e.g. Yahoo), if > the session key is “random” across all boxes in a VIP. And on the flip side, > if there’s a shared seed, then that has the same problem as we have now. How > does HTTPD deal with this? Or they simply don’t ? > > We would have the option of adding something to cluster configuration, to > distribute the session key. But, that’s rarely used, and has some strange > requirements (multicast). With a plugin API, at least someone could implement > some sort of message protocol to share the (newly) generated session keys > with all peers. > > > — Leif - Yongming Zhao 赵永明
