If a site has N haproxy hosts, how should new ticket-keys be distributed (and processes reloaded) and avoid the race condition of some hosts using the new keys before those keys are on all hosts?
Seems that not all hosts would be updated at exactly the same time and that until all hosts are updated, that any requests with new ticket-keys that are routed to not-yet-updated hosts will force another full handshake. Seems like a "use after time" would be needed so that all hosts could start using the new ticket-keys only after some time when they all have all of the keys needed. -Bryan On Wed, Feb 25, 2015 at 10:49 AM, Pavlos Parissis <[email protected] > wrote: > On 25/02/2015 12:10 μμ, Lukas Tribus wrote: > >> -- Use stats socket to update the list without reload > >> > >> -- Update Session state at disconnection log schema to include > >> something useful in case server receives a ticket which was encrypted > with key > >> that is not anymore in the list. Debugging SSL problems is a nightmare > >> by definition and having a lot of debug information is very much > appreciated > >> by sysadmins > > > > If the ticket is not in the list, it will simply fall back to a full > handshake, not > > abort the handshake, so there is no error in that case. Generic SSL/TLS > resumption > > counter should correctly account for those tings already. > > > > > > Error was the wrong word here as RFC 5077 clearly states it as a > situation from which both ends can recovery without causing an error. > But, you want to avoid the fall-back mechanism as much as possible as it > defeats the purpose of TLS session resumption, which is a faster user > experience over HTTPS. Thus, you need have a clear way to identify the > volume of the traffic which is effected by this. > I mentioned about session state at disconnection log schema as way to > pass clear information to operator that your key rotation is degrading > user experience > > I guess the generic counter you mentioned could do the trick here. > > >> -- Possible use peer logic to sync the list to others, tricky but it is > >> required when you have several LBs, alternatively users can deploy the > logic > >> that twitter has used > > > > That doesn't make much sense for externally provided tls keys, you > > may as well use the external interface on all instances. > > > > Correct. I only mentioned as an easy way for users that don't have the > external interface to facilitate this. > > > This would make more sense for SSL session ids, they are currently shared > > between processes, but not between different haproxy instances (stud for > > example can do this iirc). > > > > > > > > Lukas > > > > > > > > Thanks getting back to me, > > Once again thanks to the people who work on this. > > I guess someone has to inform few bloggers about this in order to update > their blog spot where they mention that you can't implement a proper TLS > session resumption with HAProxy:-) > > Cheers, > Pavlos > > > > >
