Security issue notifications
If you discover a potential security issue in s2n we ask that you notify
AWS Security via our vulnerability reporting page. Please do not create a public github issue.
Problem:
A s2n-tls server currently sends a new session ticket in a resumed handshake if the STEK used to encrypt the ticket is in decrypt-only mode. This is in the original resumption RFC, however it seems like a bad idea in general, because it allows the original session to live longer. I recommend removing the code that creates a new session ticket in a resumed handshake.
See:
https://datatracker.ietf.org/doc/html/rfc5077#section-3.1
If the server successfully verifies the client's ticket, then it MAY
renew the ticket by including a NewSessionTicket handshake message
after the ServerHello in the abbreviated handshake.
Recommended Solution:
Stop sending session tickets in resumed handshakes in TLS1.2.
Note that we technically could remove some handshakes from our state machine with this change, although that would not be required.
Security issue notifications
If you discover a potential security issue in s2n we ask that you notify
AWS Security via our vulnerability reporting page. Please do not create a public github issue.
Problem:
A s2n-tls server currently sends a new session ticket in a resumed handshake if the STEK used to encrypt the ticket is in decrypt-only mode. This is in the original resumption RFC, however it seems like a bad idea in general, because it allows the original session to live longer. I recommend removing the code that creates a new session ticket in a resumed handshake.
See:
https://datatracker.ietf.org/doc/html/rfc5077#section-3.1
Recommended Solution:
Stop sending session tickets in resumed handshakes in TLS1.2.
Note that we technically could remove some handshakes from our state machine with this change, although that would not be required.