Hi James, Thanks for the reply!
On Thu, Aug 21, 2014 at 4:37 PM, James Peach <jpe...@apache.org> wrote: > 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 > >. > Compatibility is important. > > 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. > traffic_line -x might work. It does not seem like an efficient approach. You need to do that on every box. I would like to push a new key to ATS's and they suck in the new key periodically without intervention. We can add a new configuration option to records.config and checks for key update only once every 12 hours. > J >
