opinions about Session tickets

Lukas Tribus luky-37 at hotmail.com
Tue Apr 12 09:17:30 UTC 2016


> I found these two opinions. They suggest to disable session tickets.
> - https://www.farsightsecurity.com/Blog/20151202-thall-hardening-dh-and-ecc/
> -
> https://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-session-resumption-implementations/
> what do others think about that?

Well, it depends:

By default, unless you specify a tls ticket file (ssl_session_ticket_key),
a new key is generated when nginx is restarted, and the key is never written
to disk.

So for the session to get compromised, the attacker has to be able to
extract the key from the servers memory, which will compromise all sessions
using this ticket key.

However, when the attacker has access to the memory the ticket key is stored,
he probably can access the shared memory containg the session cache as well,
which will compromise those session (not using tls tickets) too - the
difference is that it will only compromise the sessions that are in the
cache, while the ticket key can decrypt all sessions encrypted with it.

I would say restart nginx once a day via cronjob to cycle the tls ticket
key. Disabling tls tickets can be another workaround, yes, but all this is
only relevant when the attacker gains access to your memory, which will
reveal session cache and private key as well.

If you have more than one server, you probably want to distribute and
rotate the ticket key on all servers, in that case generate the tls
ticket key in a central location and distribute it to all servers, never
touching a permanent storage (don't save to disk, use something like



More information about the nginx mailing list