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.
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.
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.
