[pquerna]

Hi, Apache developer here, kinda a request for feedback on how we can improve the situation:

How would people feel about automatic key rotation that required time synchronization across a cluster?

Eg, on all your webservers, you have something like this:

    SSLSessionTicketKeyFile  /var/lib/apache2/session-ticket.key
    SSLSessionTicketRotation 1hour

Internally apache would calculate `HMAC(1hour-time, $key)`, and use that for the current hour (and allow the previous hour) for session ticket signing?

If you don't specify the TicketKeyFile, it would just randomly-regenerate a key every hour.

This is not perfect. It has issues. Like if your key is leaked when using a TicketKeyFile, calculating the session ticket secret for a given time is trivial.

[btilly]

You can get rid of the need for close time synchronization by having it accept 3 possible values: next hour, this hour, last hour. Then there is no problem if one is a minute ahead of another.

Furthermore the idea of issuing one key and accepting multiple others should be allowed in the TicketKeyFile. As should picking up changes in the TicketKeyFile on the fly. And now key rotation is something people can set up for themselves on any schedule that they want, in any way that they want.

But a better solution for the article's problems is to combine the two approaches. Have the server save session ID/key. Now information about the key used by one session does not help you get into another one. And access to the cache on the server cannot be used to read the contents of any session.

As an aside, I am somewhat disappointed that the documentation in 2014 for http://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslsessi... recommends a solution that would force you to run your site on one server. I have been using Apache off and on since the late 90s. Other than development machines, I haven't seen an Apache site that wasn't load balanced.