On 09.03.20 20:37, Lukas Tribus wrote: >> 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/ > Nothing about this is a MITM attack. The point in the article is that > when the ticket-key is compromised, captured traffic can be passively > decrypted (which is what broken PFS means, as explained by the Apache > docs).
take also this article, which clearly states that session tickets are vulnerable to replay attacks (which are a kind of MITM): https://eprint.iacr.org/2019/228.pdf That paper also says in clear words: "The standard techniques to achieve [session resumption] are Session Caches or, alternatively, Session Tickets. The former provides forward security and resistance against replay attacks, but requires a large amount of server-side storage. The latter requires negligible storage, but provides no forward security and is known to be vulnerable to replay attacks" I have to admit that I was also not aware that haproxy does not rotate keys by itself. As writtenhere before I also think that session tickets should really be disabled by default and the documentation should point out the risks and possible attacks. imho simple tls session caching should be enough for "older" TLS>=1.2 clients for security reasons and address the performance concerns. A secure setting should be a default at this point. If users prefer more (but less secure) performance improvement features, which even require additional work to make it less insecure (key rotation), than this should have to be enabled manually only I think. Key rotation, if enabled, should ideally not be a matter of manual action by the administrator but key rotation should happen automatically after a reasonable amount of time. A note in the documentation on the no-tls-tickets about this is just not enough, especially if session tickets stay enabled by default. Björn
