4 ms·
According to this tweet, "For TLS 1.2, this enables passive decryption of traffic to/from GnuTLS servers when the client supports session tickets (which is comm
by dbrgn 6y ago
According to this tweet, "For TLS 1.2, this enables passive decryption of traffic to/from GnuTLS servers when the client supports session tickets (which is common)".
https://twitter.com/__agwa/status/1270054738344792070 https://twitter.com/__agwa/status/1270054738344792070
- tialaramex 6y agoRight. Specifically what's going on here is that for TLS 1.2 resumption your client remembers the secret keys it was using last time, but the server doesn't want to keep secret keys for every single client that might re-connect so it has its own secret Session Ticket Encryption Key (STEK) and it sends any client a "ticket" with the server's state for that client's connection in it, encrypted using the STEK. The not at all obvious problem in TLS 1.2 is that the state encapsulated in the ticket will work not only in some hypothetical future TLS resumption (which you might never do) but also the session you are in already now. And that ticket is sent over the wire if resumption is permitted, during session setup, before the symmetric encryption for the TLS channel has switched on. So what that means is that if you know the STEK (which now for affected GnuTLS servers you do) you can read any session you captured in which resumption was allowed, including fresh sessions which were never resumed, and passively decrypt the entire thing. Nothing anybody can do about it.