5 ms·
Different versions of TLS should not interact with each other. There are too many behavioral permutations to audit.
by davidhyde 6y ago
Different versions of TLS should not interact with each other. There are too many behavioral permutations to audit.
- Ayesh 6y agoThey don't. It's always the same version server and client negotiate. The vulnerability is in the way session tickets are encrypted (or rather the lack of it), which is present in both versions, but in different formats; for example in TLS 1.3, the session ticket is sent _after_ change cipher command. It's vulnerable in 1.2 and 1.3 because the way session ticket is encrypted. GnuTLS used effectively an all-zero key until it's rotated in the next tick.
- davidhyde 6y agoThanks, I must have misread the post: > "The issue applies to TLS 1.3, when using TLS 1.2 resumption fails as expected. Because the ticket can be used for resumption without knowledge of the master key I assume (but haven't tested yet) that it can also be used for passive decryption of early data." I assumed that the server was using a ticket generated using TLS 1.2 to somehow resume a TLS 1.3 connection.
- agwa 6y agoThe bug report downplays the severity of the problem. This comment comes the closest to explaining the severity: > ticket encryption key and decryption key are all-zero [...] in TLS 1.2, it may allow attackers to recover the previous conversations https://gitlab.com/gnutls/gnutls/-/issues/1011#note_353830633 https://gitlab.com/gnutls/gnutls/-/issues/1011#note_35383063...