On 2/4/2015 12:57 PM, James Peach wrote:
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.
Hmm, didn't realize that OpenSSL does this. But just gave it a try,
and you are correct. It looks like the only way to stop openssl from
doing this in ATS is to explicitly set ssl_ticket_enable=0 in the
ssl_multicert.config. But I'm perhaps missing the global disable setting.
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.
I think this would only be valuable if tickets were auto generated. And
that would only be beneficial for single proxy installations. While that
is not valid for large deployments, that would be valid for many ISP
deployments.
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.
If you had a plugin interface, people could implement their own
interface to the Linux kernel key management, or memcached or whatever.
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.
Oh, I forgot in the course of my messing around, I added a test in the
session ticket callback to look at the default entry if there was
nothing for the specific IP in ssl_multicert.config.
Do most people use the same ticket file for all destinations? Or is it
desirable to use different ticket files for different destinations?
J
