On Aug 22, 2014, at 10:35 AM, Manjesh Nilange <manjeshnila...@gmail.com> wrote:
> 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 >>> . >> >>> 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. >> > > Won't traffic_line -x cause other config changes to be picked up as well? I > think that is risky. Well it's intrinsically risky to leave un-applied changes that you are not willing to accept at any time. I would expect any config management (puppet, salt, etc) will run traffic_line -x when it makes any config changes. > And operationally, I'm not sure how maintainable it is > to co-ordinate all servers like this. I dunno, it seems straightforward to me. Rotate the keys, load new ones. The failure mode is that there is a window where SSL sessions can't get resumed, so you'll take a CPU and latency hit for a short time. J
