Am 23.03.2016 um 00:30 schrieb Paul Querna:
On Tue, Mar 22, 2016 at 3:32 PM, Yann Ylavic <[email protected] <mailto:[email protected]>> wrote: On Tue, Mar 22, 2016 at 4:18 PM, Paul Querna <[email protected] <mailto:[email protected]>> wrote: > My thought was to add support for either multiple files, or multiple values > in the existing `SSLSessionTicketKeyFile`. Then add support to decrypt from > any of the known keys, and have a setting (or the first loaded key) would be > used to encrypt all new keys. This would allow for rotation in a reasonable > manner. That's indeed a great improvement on what we have now, and actually looks like you first introduced it in r1200040 :) Why was it not kept that way? We'll still need a (graceful) restart to renew the keys, though. (unix mpms) Having the a process (mpm_register_timed_callback? other hooks?) re-read the file periodically or on change, and set them set it in a slot mem is reasonable, but not the behavior of almost any other file reference in httpd... so the pattern of graceful is how most things work, I can't figure out why session tickets are worth an exception to this pattern? Also, it seems there is interest in sharing the keys accross different instances/machines, is a file (unless on something like an NFS mount) an option here? Most large scale deployments have configuration management or other techniques to synchronize secret values across many machines; I don't think we should go overboard in building a network transport for session ticket secrets.
Yann had the interesting idea to use a key derivation scheme like PBKDF2 to create a sequence of keys, key renewal triggered e.g. as suggested by Rüdiger time-based. Such a scheme would only need to distribute the initial key file between farm nodes, but not an update to the file e.g. once a day. I like that idea, although I can't really judge on the safeness of the derived keys. Such a key derivation scheme (there are also others, Wikipedia refers to Argon2) seems not to be exotic.
Regards, Rainer
