Re: TLS session ticket key (shared) renewal
Am 23.03.2016 um 00:30 schrieb Paul Querna: On Tue, Mar 22, 2016 at 3:32 PM, Yann Ylavic mailto:[email protected]>> wrote: On Tue, Mar 22, 2016 at 4:18 PM, Paul Querna 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
Re: TLS session ticket key (shared) renewal
On Tue, Mar 22, 2016 at 3:32 PM, Yann Ylavic wrote: > On Tue, Mar 22, 2016 at 4:18 PM, Paul Querna 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.
Re: TLS session ticket key (shared) renewal
On Tue, Mar 22, 2016 at 4:18 PM, Paul Querna 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. 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?
Re: TLS session ticket key (shared) renewal
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. On Fri, Mar 18, 2016 at 6:55 AM, Yann Ylavic wrote: > Currently this can be done by using a (shared) SSLSessionTicketKeyFile > and gracefuly restarting httpd instances, but there is room for > improvements here. > > Thoughts? >
Re: TLS session ticket key (shared) renewal
Am 18.03.2016 um 15:01 schrieb Yann Ylavic: On Fri, Mar 18, 2016 at 2:55 PM, Yann Ylavic wrote: Currently this can be done by using a (shared) SSLSessionTicketKeyFile and gracefuly restarting httpd instances, but there is room for improvements here. Thoughts? For the single httpd instance case at least, I'm thinking of SSLSessionTicketKeyTimeout which could be used for renewing the key(s), without the need for a scheduled restart. The key(s) would have to be stored/sync-ed in a SHM (or slotmem)... Would that mean, that at the points of time of key renewal all old tickets immediately loose their validity? In that case you would have a regular bump in negotation rates. It would be nice, if one older generation of keys would still work for a little time, so some overlap. I haven't checked how to do that though. Any idea about a scheme how to renew the keys between nodes in a farm in a synced way? Finding a common point in time to renew would not be the problem (assuming synced clocks), but how the regenerate keys deterministically starting from one common secret (the SSLSessionTicketKeyFile) without ending with keys which are too weak? Regards, Rainer
Re: TLS session ticket key (shared) renewal
On Fri, Mar 18, 2016 at 5:54 PM, Yann Ylavic wrote: > > Maybe something like the following could work, and maybe also it could > be secure (any contradictory opinion is of course very welcome :) Please s/PDKF2/PBKDF2/g in this previous message, too much unpronounceable letters for me :)
Re: TLS session ticket key (shared) renewal
On 03/18/2016 04:09 PM, Rainer Jung wrote: > Am 18.03.2016 um 15:01 schrieb Yann Ylavic: >> On Fri, Mar 18, 2016 at 2:55 PM, Yann Ylavic wrote: >>> Currently this can be done by using a (shared) SSLSessionTicketKeyFile >>> and gracefuly restarting httpd instances, but there is room for >>> improvements here. >>> >>> Thoughts? >> >> For the single httpd instance case at least, I'm thinking of >> SSLSessionTicketKeyTimeout which could be used for renewing the >> key(s), without the need for a scheduled restart. >> The key(s) would have to be stored/sync-ed in a SHM (or slotmem)... > > Would that mean, that at the points of time of key renewal all old tickets > immediately loose their validity? In that > case you would have a regular bump in negotation rates. It would be nice, if > one older generation of keys would still > work for a little time, so some overlap. I haven't checked how to do that > though. > > Any idea about a scheme how to renew the keys between nodes in a farm in a > synced way? Finding a common point in time to > renew would not be the problem (assuming synced clocks), but how the > regenerate keys deterministically starting from one > common secret (the SSLSessionTicketKeyFile) without ending with keys which > are too weak? My idea would be at high level to leverage approaches that are used for one time passwords here. But I need to admit that I don't know how feasible that is at all and how usable these approaches are for generating a (strong) key. Regards Rüdiger
Re: TLS session ticket key (shared) renewal
On Fri, Mar 18, 2016 at 4:20 PM, Ruediger Pluem wrote: > On 03/18/2016 04:09 PM, Rainer Jung wrote: >> >> Any idea about a scheme how to renew the keys between nodes in a farm in a >> synced way? Finding a common point in time to >> renew would not be the problem (assuming synced clocks), but how the >> regenerate keys deterministically starting from one >> common secret (the SSLSessionTicketKeyFile) without ending with keys which >> are too weak? > > My idea would be at high level to leverage approaches that are used for one > time passwords here. > But I need to admit that I don't know how feasible that is at all and how > usable these approaches are for generating > a (strong) key. Maybe something like the following could work, and maybe also it could be secure (any contradictory opinion is of course very welcome :) Say each instance starts with the same configured passphrase and salt (same too, but random and large enough, say 128bit). At startup we generate a master key (MK) from this passphrase/salt (using PDKF2, maybe with some reasonable #iterations), and we'll use a derived key (DK) for session tickets. To derive the MK into DKs (at startup or when the current DK timeouts), let's again run PDKF2 but now with the current time as salt (and a single iteration). This scheme makes the DK deterministic at any time, hence provided clocks are synchronized, each httpd instance should use the same key. Since session tickets also need a HMAC key, we would do the same for it (from another passphrase and salt). I may be opportunistic about the security of this scheme, though, please experts ring the bell :p Regards, Yann.
Re: TLS session ticket key (shared) renewal
On Fri, Mar 18, 2016 at 2:55 PM, Yann Ylavic wrote: > Currently this can be done by using a (shared) SSLSessionTicketKeyFile > and gracefuly restarting httpd instances, but there is room for > improvements here. > > Thoughts? For the single httpd instance case at least, I'm thinking of SSLSessionTicketKeyTimeout which could be used for renewing the key(s), without the need for a scheduled restart. The key(s) would have to be stored/sync-ed in a SHM (or slotmem)...
