> On Feb 4, 2015, at 10: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.
IIRC that's what OpenSSL does automatically when session tickets are enabled and you don't provide your own ticket key. > > 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. No. Bin Zeng added ticket key rotation. You don't need a lifetime; just rotate the keys at whatever frequency you desire. > 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. This seems to be of pretty limited value. I think that adding Linux kernel key management support would be more generally useful, but in either case, few people would use this. > Question 4: What is the granularity of session tickets? In ATS, you can set > session tickets on default or on an IP by IP basis. Do most people just set > one ticket for all possible destinations? Or do folks set tickets on each > IP? No suggestion here. Just curious how the feature is used. Currently, you can only set session tickets at the same granularity as ssl_mulicert.config. There is a records.config setting for using a global ticket (which I think makes sense), but that's not implemented. J
