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. > > >> J >>
