On Fri, Aug 22, 2014 at 12:14 PM, James Peach <jpe...@apache.org> wrote:
> 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. > It is not really a change to the configuration files. The contents in the ticket key file are changed, of which the file name stays the same. When you run traffic_line -x, the configuration files get parsed but the ticket keys do not get loaded again. > > 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. > The failure mode is not something I am worried about. We have multiple keys in rotation. Session tickets decrypted with old keys will get encrypted with the most recent one. > > J > >
