Thanks for the feedback. The implementation is not as complex as it sounds. It's only a few lines of code and requires adding one configuration option to SSL config, which is the number of keys in rotation. Even that can be obviated.
On Tue, Aug 26, 2014 at 3:53 PM, James Peach <jpe...@apache.org> wrote: > On Aug 25, 2014, at 1:21 PM, Bill Zeng <billzeng2...@gmail.com> wrote: > > > Thanks for the comments. We can stick to the current byte-blob ticket key > > format. I would like to extend it a little to store multiple ticket keys > > for rotation. A new key is generated and appended to the ticket key file > > while the oldest one (at the beginning of the file) gets removed (assume > we > > have more than one keys in rotation). Multiple keys are kept in the > ticket > > key file for the convenience of deployment. Sessions encrypted with older > > keys can still be resumed after an ATS restart. It seems that > > SSL_CTX_set_tlsext_ticket_key_cb callback is helpful for this situation. > > Every time a ticket key is presented, we try to decrypt it with one of > the > > ticket keys in rotation, and if it succeeds, we always encrypt it with > the > > most recent ticket key. The callback checks whether the ticket key file > has > > changed once every rotation cycle, say 12 hours. > > Sorry, this still seems like more complexity than it's worth. I'd just > push the new keys and let connections renegotiate. SSL config is already > complicated enough. > > > On Fri, Aug 22, 2014 at 1:44 PM, Bill Zeng <billzeng2...@gmail.com> > wrote: > > > >> > >> > >> > >> 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 > >>> > >>> > >> > >
