ср, 11 мар. 2020 г. в 04:09, Björn Jacke <[email protected]>: > 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
major players of a big picture are 0RTT and session tickets. indeed, if you wish to fight replay attack, you cannot use 0RTT (also, you are supposed to maintain keys rotation). as for keys rotation, for unfamiliar people it is not clear why haproxy itself does not provide such rotation. at least, it should be better documented. > > > 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. > > I guess most people do not realise that. > 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. > key rotation when happens trigger a lot of client renegotiation. and it is observable on haproxy reload, there are huge CPU spikes. I think most people do not realise why those spikes happen. > > Björn > >
