пн, 9 мар. 2020 г. в 23:59, Willy Tarreau <[email protected]>: > 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. >
maybe it worth separate discussion... there was some discussion on nginx mailing list regarding BoringSSL and TLS tickets (sorry for link to discussion in russian) https://forum.nginx.org/read.php?21,286846 in short, BoringSSL in 2017 has changed its behaviour related to TLS tickets: https://boringssl.googlesource.com/boringssl/+/72912d2 in short, it is ok if you specify TLS ticket key in file, and it simply does not work (i.e. works only for master process) if you do not specify. i.e. each process has its own TLS ticket key. and user has no way to choose web worker process. seems, it might be related to any multi process web server, not only nginx. are there some tests in haproxy to cover such boringssl behaviour ? > > > 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 > >
