> 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
