On Tue, Mar 22, 2016 at 3:32 PM, Yann Ylavic <[email protected]> wrote:
> On Tue, Mar 22, 2016 at 4:18 PM, Paul Querna <[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.
