proper setup for forward secrecy

Maxim Dounin mdounin at
Mon Sep 24 14:41:51 UTC 2012


On Fri, Sep 21, 2012 at 05:22:14PM -0400, eiji-gravion wrote:

> Maxim Dounin Wrote:
> -------------------------------------------------------
> > Hello!
> > 
> > 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.
> Is this all that can be done?
> 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 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.

Maxim Dounin

More information about the nginx mailing list