doc: clarify tlsSocket.authorized on resumption#64584
Open
soreavis wants to merge 1 commit into
Open
Conversation
The peer certificate is not verified again when a connection resumes a TLS session. When the original handshake included a client certificate, authorized and authorizationError carry the verification result stored with the session; on TLS 1.3, a client that sent no certificate can resume a session and report authorized as true. Document this and point manual-authorization servers at isSessionReused() and getPeerCertificate(). Fixes: nodejs#35317 Signed-off-by: Julian Soreavis <julian.soreavis@gmail.com>
nodejs-github-bot
added
doc
pimterry
approved these changes
Jul 22, 2026
pimterry
left a comment
pimterry
left a comment
Member
There was a problem hiding this comment.
Text is accurate for the current state AFAICT, and the recommendation is reasonable I think.
I do think we might want to change the actual behaviour to tighten this up, but I'll reopen that discussion in the original issue. Any chance would be semver major and we should document the current state in the meantime anyway.
pimterry
added
the
author ready
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
3 participants
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.
In #35317, @bnoordhuis diagnosed that session resumption cuts out the client-certificate exchange and invited exactly this change: "I do feel the documentation for
socket.authorizedshould mention that caveat… I've added thedoclabel. Pull request welcome!" ThetlsSocket.authorizedsection still describes only the full-handshake behavior.Before writing the text I measured all six scenarios on current
main(TLS 1.2/1.3 × trusted/untrusted/no client cert; deterministic, reproduced with two independent harnesses): when a certificate was presented in the original handshake, the verification result — including any error — is carried with the session on both protocol versions (SSL_get_verify_resultreads the session-stored result;deps/ncrypto/ncrypto.ccverifyPeerCertificate). The one case that still flips is TLS 1.3 with no client certificate: the full handshake reportsauthorized === false, but a resumed connection reportsauthorized === truewithgetPeerCertificate()empty — the deliberate carve-out shared with PSK (TLS1_3_VERSION && SSL_session_reused→X509_V_OK, from #23188). The added paragraph states the carry-over rule, that exception, and the practical check for servers that authorize manually withrejectUnauthorized: false.I used an AI assistant while researching and drafting this change; I've verified the behavior with live repros and against the source myself and take full responsibility for it.
Fixes: #35317