The sad state of server-side TLS session resumption implementations

The sad state of server-side TLS session resumption implementations(timtaubert.de)

28 points by ttaubert 11 years ago | 4 comments

ttaubert 11 years ago |

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 11 years ago |

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 11 years ago | |

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.

skuhn 11 years ago |

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.)

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