TLS 1.3 server: don't send NewSessionTicket (session resumption is not implemented)#403
Open
EdouardMALOT wants to merge 1 commit into
Open
Conversation
…orted) _nx_secure_tls_1_3_server_handshake.c sent a NewSessionTicket after every Client Finished, advertising session resumption to the client. But _nx_secure_tls_process_clienthello_psk_extension explicitly rejects any PSK with age != 0 (i.e. every real resumption attempt) with NX_SECURE_TLS_BAD_CLIENTHELLO_PSK_EXTENSION — the existing implementation only supports external PSKs. Net effect on clients that act on the advertised ticket (Java JSSE in particular): every other handshake fails. Conn N succeeds + caches the ticket; conn N+1 replays the ticket → server sends Alert(internal_error) → JSSE invalidates the cache; conn N+2 succeeds; loop. Fix: skip the NewSessionTicket send. The PSK consumer code stays as-is so any future external-PSK use case is unaffected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The TLS 1.3 server sends a
NewSessionTicketafter every completed handshake, but session resumption is not implemented: the server can never honor the ticket it just issued.What
_nx_secure_tls_send_newsessionticket()actually sends:ticket_lifetime = 604800(the RFC maximum, 7 days), a randomticket_age_add, and the hardcoded string"NewSessionTicket"as ticket identity. No server-side state is created. The ticket is a stub.What happens when a client caches that ticket and offers it on its next connection depends on the build:
NX_SECURE_ENABLE_PSK_CIPHERSUITES:_nx_secure_tls_process_clienthello_psk_extension()rejects any PSK identity with a non-zero obfuscated age (/* Only support external PSKs (no session resumption). */) withNX_SECURE_TLS_BAD_CLIENTHELLO_PSK_EXTENSIONand a fatal alert. Sinceticket_age_addis random, a replayed ticket's obfuscated age is never zero in practice. Observed in the field with Java (JSSE) clients: every other connection fails. Connection N succeeds and caches the ticket, connection N+1 replays it and is aborted, JSSE drops the cached ticket, connection N+2 succeeds, and so on.pre_shared_keyextension is ignored and the handshake completes as a full handshake. No failure, but every TLS 1.3 client is handed a 7-day stub ticket it will cache and uselessly replay on every connection.Changes
nx_secure/src/nx_secure_tls_1_3_server_handshake.c— do not sendNewSessionTicketafter the client Finished. The message is optional per RFC 8446 §4.6.1 ("the server MAY send"); not advertising resumption is the correct behavior as long as it is not implemented._nx_secure_tls_send_newsessionticket()has no state side effects (it only writes the packet), so nothing downstream is affected; the function is kept for the day resumption support lands. The PSK extension handler is untouched, so external PSKs (age == 0) keep working. Incidentally, the removed block also contained an unchecked status (_nx_secure_tls_send_newsessionticket()'s return value was overwritten by the next call).Possible follow-up, out of scope here: per RFC 8446 §4.2.11, a server that does not accept an offered PSK identity should skip it and fall back to a full handshake rather than abort. That would harden the handler against resumption offers from any peer.
Test plan
NX_SECURE_ENABLE_PSK_CIPHERSUITES, Java (JSSE) client making repeated connections: previously every other handshake failed with a fatal alert, now all connections succeed