Thanks for the reply! On Thu, Aug 21, 2014 at 7:50 PM, Wei Sun <sun...@yahoo-inc.com.invalid> wrote:
> > > On 8/22/14, 10:06, "Bill Zeng" <billzeng2...@gmail.com> wrote: > > >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. > > Another approach is to use the lifecycle API > (TS_LIFECYCLE_SERVER_SSL_CTX_INITIALIZED_HOOK) and handle any SSL_CTX > related callbacks (e.g. ssl_callback_session_ticket) in a plug-in where > you may spawn a dedicate thread to rotate the keys, this helps to > integrate with specific CKMS that keys are all in memory. > > A separate thread seems like an overkill for this problem. A session ticket key is renewed once for every 12 hours. Most of the time, the thread would be idle. > > > > > >> J > >> > >
