On Aug 21, 2014, at 3:56 PM, Bill Zeng <billzeng2...@gmail.com> wrote:
> Hi all, > > I am new to ATS and my understanding of ATS is limited. I am working on a > project to enable session resumption using session tickets. Session tickets > are encrypted with session ticket keys which need to be rotated for > security. Currently, one session ticket key file (only one key is used) is > specified by the ticket_key_name option and used for the entire time. > > I would like to propose to rotate the session ticket key periodically, say, > once every 12 hours. A new session ticket key is generated by a key server, > and distributed to ATS's. Note that locally generated keys cannot be shared > among multiple ATS's on different boxes easily. An ATS needs to load new > keys into memory every 12 hours. In order to smooth the key transition > process, multiple keys can be in use at the same time. That is, when a new > key is generated, the older can be used for a while before it gets retired. > These keys can be stored in multiple files, but it is neat to store them in > just one file. > > A session ticket key contains three 16-byte fields: key name, AES key, and > HMAC key. Right now, they are stored as an opaque 48-byte blob. A 48-byte > blob works for the simple case with just one session ticket key. But it can > be inconvenient for multiple keys with different versions. We use the same ticket key format as httpd <http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslsessionticketkeyfile>. > I would like to > propose to use JSON as the format for session ticket keys. We can store > rich metadata such as the version, lifetime etc. in JSON. Each key can also > have a lifetime associated with it. JSON is also human-readable and > inter-operable with other tools. A simple JSON parser is needed to parse > the session ticket keys. > > Here is Twitter's approach to this problem: > https://blog.twitter.com/2013/forward-secrecy-at-twitter You can implement a scheme similar to that described in the Twitter post with some external tooling. Keep the tickets on a RAM disk (or a FUSE filesystem helper), and reload the SSL config (touch ssl_multicert.config && traffic_line -x) once the new version is in place everywhere. I guess that you could use something like etcd to co-ordinate the process. J
