Am 18.03.2016 um 15:01 schrieb Yann Ylavic:
On Fri, Mar 18, 2016 at 2:55 PM, Yann Ylavic <[email protected]> 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

Reply via email to