On Mon, Mar 09, 2020 at 07:18:23PM +0100, Björn Jacke wrote: > On 2020-03-09 at 17:44 +0100 Lukas Tribus sent off: > > Perhaps we can relax the wording a bit here and describe the actual > > technical issue along with some recommendations. Apache for example > > documents [1]: > > I think the wording from the patch is still quite relaxed :). One of the best > summaries describing the session ticket flaws, which I recommend is this: > https://blog.filippo.io/we-need-to-talk-about-session-tickets/
So as explained in the article above, all of this is only a problem if keys are *never* rotated. New keys are used every time the process is reloaded, and those using distributed deployments update them via the "set ssl tls-key" command on the CLI which purposely supports old and new key in order to maintain a distributed state synchronized yet up to date. > I would disable session tickets by default in haproxy. Given that most > clients support TLS 1.3 already this change would not even slow down many > clients. The problem is not as much the client slowing down as killing the servers by the excess of handshakes caused by the minority of remaining clients, because with this the service easily becomes totally unavailable for everyone depending on the population of clients. Not everyone has a lot of up-to-date browsers in their clients, and a number of deployments actually never see a browser at all. Willy
