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. 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". Question 3: I am not sure how many plugin writers will use this. Based on my own experience, they seldom touch SSL/TLS stuff. 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.
