

The sad state of server-side TLS session resumption implementations - ttaubert
https://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-session-resumption-implementations/

======
ttaubert
Small clarification: As Ryan Sleevi pointed out over Twitter, it may sound a
lot like I'm giving advice and discouraging the use of session tickets. I
don't want to encourage anyone to disable session tickets and make TLS so slow
that they're switching back to HTTP for good. Having TLS without PFS is a lot
better than having no TLS. The post was mainly written to explore options and
show that there are tradeoffs to think about with current setups, especially
if you're interested in going all the way and provide PFS.

------
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...](http://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslsessioncache)
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.

------
skuhn
nginx does have the minimum necessary support to handle shared session ticket
keys. It would be nice if it did more for you out-of-the-box, but I'm more
interested in practical solutions that work today.

You can specify _ssl_session_ticket_key_ multiple times, and the subsequent
declarations are used for decryption only.

It does take some elbow grease to implement the tooling around this, and it's
unlikely that many people have bothered, but they should.

    
    
      1. Generate new key on a master host (store only on tmpfs partition for extra points)
      2. Somehow get it on all of the relevant hosts securely, such as by using lsyncd
      3. Add new key to end of list of ssl_session_ticket directives
      4. Reload all nginxes that answer a particular address
      5. Move new key to top of list
      6. Reload all nginxes that answer a particular address
    

(after I wrote this, I noticed it was pretty similar to Twitter's idea. I
guess great minds think alike.)

