I was reading an article written by Adam Langley and he says:
"You also need to be aware of Session Tickets in order to implement
forward secrecy correctly. There are two ways to resume a TLS
connection: either the server chooses a random number and both sides
store the session information, of the server can encrypt the session
information with a secret, local key and send that to the client. The
former is called Session IDs and the latter is called Session Tickets.
But Session Tickets are transmitted over the wire and so the server’s
Session Ticket encryption key is capable of decrypting past connections.
Most servers will generate a random Session Ticket key at startup unless
otherwise configured, but you should check."
On Thu, Aug 09, 2012 at 02:37:36PM -0400, eiji-gravion wrote:
But Session Tickets are transmitted over the wire and so the server’s
Session Ticket encryption key is capable of decrypting past connections.
Most servers will generate a random Session Ticket key at startup unless
otherwise configured, but you should check."
So my question is, how does nginx handle this?
As per OpenSSL default - as long as session tickets are supported
by OpenSSL version you use, random key for session tickets will be
generated automatically on nginx startup.
On Tue, Sep 18, 2012 at 04:34:30AM -0400, eiji-gravion wrote:
Still curious about this, it would be nice to have a way to rotate these
keys without having to restart the server.
Looking though OpenSSL code suggests keys are generated on SSL_CTX
creation (at least as of OpenSSL 1.0.1c, see SSL_CTX_new() in
ssl/ssl_lib.c), that is, they are rotated by nginx configuration
reload.
On Fri, Sep 21, 2012 at 05:22:14PM -0400, eiji-gravion wrote:
Looking though OpenSSL code suggests keys are generated on SSL_CTX
this without a total config reload? Perhaps even a user-defined rotation
time in minutes?
This is something you may suggest to OpenSSL folks, as nginx
doesn’t do anything here. What we are talking about is OpenSSL’s
default behaviour, without a single line of code on nginx side.
This seems like a pretty important thing to have, most people who are
running DH/ECDHE ciphersuites probably don’t even realize that they aren’t
really getting forward secrecy…
This depends on how do you define “forward secrecy”.
Certainly it won’t be possible to decrypt past communications on
private key compromise, that is - secure destruction of disks with
old private keys isn’t needed.
The bad thing which may happen with session tickets is a running
server takeover. This would theoretically allow to extract
current session ticket key from server’s memory and decrypt past
sessions which used session tickets encrypted with the current
key. But this is quite a different from no forward secrecy at
all, as the key in question is more or less short-lived anyway.
It would be fine to have more control on the key lifetime instead
of relying on new key generation on server startup/configuration
reload. But someone has to actually implement this.
It just seems kind of hackish to need a cronjob set to do a
configuration
reload to rotate these keys.
Would it be possible to have some type of configuration option that does
this without a total config reload? Perhaps even a user-defined rotation
time in minutes?
This seems like a pretty important thing to have, most people who are
running DH/ECDHE ciphersuites probably don’t even realize that they
aren’t
really getting forward secrecy…