On Fri, 30 Sep 2011, Rainer Jung wrote:
Thanks for the info. That would definitely be a nice feature. Would it
be safe to use a statically defined key? Only as long as the config file
is safe?
As I understand it, knowledge of the session ticket key allows to
decrypt all connections that use session tickets with this key. I
think this is true even if the tls cipher itself guarantees forward
security (like DHE). If this is correct, the option certainly needs
some warnings in the documentation.
Also, I think the config file is the wrong place for the key. Just think
of mod_info, which would display the key in the configuration. And I am
also against generating the key from some ASCII password that likely has
less entropy than the 48 bytes used for the key.
What about specifying a file that contains the base64 encoded key? If
the file does not exist, httpd could create it with a random value and
the correct permissions. The admin would then just need to start httpd on
one server and copy the created file to the other servers.
Or we could just document how to create it. Under Unix, it's a one-
liner:
(umask 077; dd if=/dev/random bs=48 count=1|
openssl base64 > filename.key)
Other nice to have things may be:
Support for storing the ticket key in encrypted form and querying the
passphrase with SSLPassPhraseDialog.
Automatic key rollover. The first idea for this I could come up with would
be would be the following: Store the key together with a timestamp and
replace the key with some hash of the key at fixed intervals (like every
day). Then the key could be used to decrypt ssl sessions of the current
day and of the future, but it would not allow to decrypt sessions that
used an older ticket key. Well, at least if the old key is overwritten on
disk, too.
