On Wed, Mar 11, 2020 at 12:06:45AM +0100, Björn Jacke wrote: > 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"
This paper is talking about 0-RTT which is *not* enabled by default, which you have to enable using the "0rtt" bind keyword, and which is only applied to idempotent requests. And it's not on our side to decide about session cache vs tickets, it depends on the client and TLS version. Requests that come in SSLv3 to TLSv1.1 involve the session cache while TLSv1.2 involve tickets. Willy
