On 2/4/2015 12:36 PM, Leif Hedstrom wrote:
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?
Agreed, generating on the fly is not a solution for large deployments
that are sharing sessions. But for small deployments or people just
evaluating, this seems like a friendlier, more secure stance.
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 ?
As far a I can tell Httpd gives you the file option, and it is up to you
to update files as necessary.
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.
I think the plugin would allow for some good experimentation. There is
always the possibility of folding a solution back into the core.
— Leif
