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 <[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?
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
