Hi Bin,
Thanks for the comments. Some additional questions and comments inline.
On 2/4/2015 1:21 PM, Bin Zeng wrote:
Hi Susan,
This is Bin. I wrote the initial code for SSL ticket key rotation which was
recently committed.
See TS-3301 and TS-3309. Disclaimer: I am still relatively new to ATS. My
understanding is
limited.
* Before the patch, there was no way to rotate ticket keys in flight. In order
to do that, you had to
put a new key in the ticket key file and then do a ATS restart. Now, you can
push a new key to
the ticket key file and do a hot update with "traffic_line -x". Definitely, ATS
server deployments
did not rotate ticket keys frequently enough. I did some survey into other
vendors. Google rotates
their ticket keys about every 100800 seconds (28 hours), Twitter every 129600
seconds (36 hours).
Facebook rotates their ticket keys every 86000 seconds (about 24 hours).
* Storing the ticket keys on a persistent disk is not optimal in the point view
of security. The keys
can be stored in ATS memory, a ram file system, or a persistent file system
(disk). A ram file system
is similar to a persistent disk from the view of ATS, except that it is only
stored in memory (it cannot
even be swapped to disk by the OS). Storing the keys in a file system has the
benefits of keeping the
keys across ATS restarts. It would lose all the keys if they were stored in ATS
memory.
Question 1: it is somewhat valuable to give people the option to have ATS
generate ticket keys.
The concern is that if you have many ATS boxes and do not have sticky routing,
a request can be
routed to a different ATS instance the next time and the SSL session would not
be able to be resumed
because every ATS generates its own ticket keys. That said, if we can syn all
the ticket keys among
ATS instances conveniently, it would make more sense.
Syncing keys sounds like clustering, and many folks probably don't want
to go there. I think auto-generating keys and offering a simple
lifetime enforcement would only apply to smaller installations.
Question 2: If I understand correctly, ATS/OpenSSL uses
proxy.config.ssl.session.cache.timeout as the
lifetime for a session ticket. The current implementation lets the
administrator control the ticket key lifetime
through "traffic_line -x". For example, if you decide to rotate the ticket key,
you can generate a new ticket key
and push it to the head of ticket key file. You can remove an old key from the
tail of the file to retire it completely.
The current implementation uses the first key in the ticket key file to encrypt
session tickets and all the ticket keys
to decrypt session tickets. If you would like to retire a key completely, you
remove it from the file and then do
a "traffic_line -x".
Thanks for pointer to proxy.config.ssl.session.cache.timeout. Wasn't
aware of that one. That sets the lifetime of the SSL session itself.
Not the lifetime of the ticket key. One ticket key could be used to
state of multiple sessions to create session tickets.
Question 3: I am not sure how many plugin writers will use this. Based on my
own experience, they seldom
touch SSL/TLS stuff.
Yes, that seems to be the consensus so far. Sounds like the file API
that you have now is the good point for integration.
Bin
________________________________________
From: Susan Hinrichs [shinr...@network-geographics.com]
Sent: Wednesday, February 04, 2015 10:15 AM
To: dev@trafficserver.apache.org
Subject: Question about SSL Session Ticket Use Cases and request for opinions
on expansions
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.
