Previously if you used TLS 1.3 and the server requested a client cert,
but the client didn't send one, and you used rejectUnauthorized:false
the resumed session would report authorized=true. This doesn't match TLS
1.2 behaviour or make any sense, and was purely an artifact of our
internal logic for handling TLS 1.3 resumption details. We now correctly
report the authorization state and/or error from the original connection
in all cases, with a matrix test that fully checks the invariant:
authorized state after resume should always match the initial state.
Signed-off-by: Tim Perry <pimterry@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/64677
Reviewed-By: James M Snell <jasnell@gmail.com>
This existed for 'resumeSession', which needed to do an async lookup
though SSL_CTX_sess_set_get_cb is sync-only. Nowadays both OpenSSL &
BoringSSL have an early ClientHello callback for suspend/resume to
handle this properly, so it was redundant, in addition to being
complicated and generally a bit fragile & scary.
This PR switches to use the modern OpenSSL/BoringSSL mechanisms for this
and drops the client hello parser & related infrastructure completely.
In addition, there's a new test here, covering a fixed bug: the hello
parser silently dropped fragmented hellos, which we now do handle
correctly.
Signed-off-by: Tim Perry <pimterry@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/64827
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
This changes enables compression within OpenSSL *without* enabling
record compression, so this only affects compression of certificates
delivered within the TLS handshake. This certificate compression remains
disabled by default for now, but becomes available via the new
certificateCompression option in TLS context APIs.
Enabling this shrinks handshakes significantly, and also reduces
fingerprintability of Node.js client handshakes, as these are enabled in
all modern browsers by default.
Signed-off-by: Tim Perry <pimterry@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/62217
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
The regex constructed by server.addContext() lacked the case-insensitive
flag, causing uppercase or mixed-case SNI hostnames from ClientHello to
miss their intended context and fall back to the default context. This
violates RFC 6066 Section 3, which states that DNS hostnames are
case-insensitive. In mTLS configurations with per-tenant contexts, this
allowed bypassing client certificate authorization by simply
uppercasing the SNI hostname.
Add the 'i' flag to the RegExp in addContext() so that SNI matching
is case-insensitive.
PR-URL: https://github.com/nodejs-private/node-private/pull/857
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
CVE-ID: CVE-2026-48928
Refs: https://hackerone.com/reports/3656869
Map BoringSSL's native renegotiation failure to
ERR_TLS_RENEGOTIATION_UNSUPPORTED when TLSSocket#renegotiate() is
called. This avoids exposing an implementation-specific OpenSSL error
when the TLS backend does not support caller-initiated renegotiation.
Signed-off-by: Filip Skokan <panva.ip@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/63161
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Wrap the owner._SNICallback() invocation in loadSNI() with try/catch
to route exceptions through owner.destroy() instead of letting them
become uncaught exceptions. This completes the fix from CVE-2026-21637
which added try/catch protection to callALPNCallback,
onPskServerCallback, and onPskClientCallback but missed loadSNI().
Without this fix, a remote unauthenticated attacker can crash any
Node.js TLS server whose SNICallback may throw on unexpected input
by sending a single TLS ClientHello with a crafted server_name value.
Fixes: https://hackerone.com/reports/3556769
Refs: https://hackerone.com/reports/3473882
CVE-ID: CVE-2026-21637
PR-URL: https://github.com/nodejs-private/node-private/pull/819
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2026-21637
`tls.connect()` silently ignores `keepAlive`, `keepAliveInitialDelay`,
and `noDelay` options. The documentation states it accepts any
`socket.connect()` option, and `net.createConnection()` with the same
options works correctly.
Forward the options through both code paths so `net.Socket`'s
constructor stores them on the internal symbols (`kSetNoDelay`,
`kSetKeepAlive`, `kSetKeepAliveInitialDelay`), which `afterConnect()`
then applies to the handle.
Fixes: https://github.com/nodejs/node/issues/62003
PR-URL: https://github.com/nodejs/node/pull/62004
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: René <contact.9a5d6388@renegade334.me.uk>
This commit exposes the `X509_V_FLAG_PARTIAL_CHAIN` OpenSSL flag to
users. This is behavior that has been requested repeatedly in the
Github issues, and allows aligning behavior with other TLS libraries
and commonly used applications (e.g. `curl`).
As a drive-by, simplify the `SecureContext` source by deduplicating
call sites at which a new custom certificate store was created for the
`secureContext` in question.
Fixes: https://github.com/nodejs/node/issues/36453
PR-URL: https://github.com/nodejs/node/pull/54790
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
For historical reasons, the second argument of SSL_CTX_set_timeout is a
signed integer, and Node.js has so far passed arbitrary (signed) int32_t
values. However, new versions of OpenSSL have changed the handling of
negative values inside SSL_CTX_set_timeout, and we should shield users
of Node.js from both the old and the new behavior. Hence, reject any
negative values by throwing an error from within createSecureContext.
Refs: https://github.com/openssl/openssl/pull/19082
PR-URL: https://github.com/nodejs/node/pull/53002
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Tim Perry <pimterry@gmail.com>
Node.js has so far only supported user-defined DHE parameters and even
recommended generating custom parameters. This change lets users set the
dhparam option to 'auto' instead, in which case DHE parameters of
sufficient strength are selected automatically (from a small set of
well-known parameters). This has been recommended by OpenSSL for quite a
while, and it makes it much easier for Node.js TLS servers to properly
support DHE-based perfect forward secrecy.
This also updates the documentation to prioritize ECDHE over DHE, mostly
because the former tends to be more efficient and is enabled by default.
PR-URL: https://github.com/nodejs/node/pull/46978
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
In the manual page, there is a statement that ciphersuites contain
explicit default settings - all TLS 1.3 ciphersuites enabled.
In node, we assume that an empty setting mean no ciphersuites and
we disable TLS 1.3. A correct approach to disabling TLS 1.3 is to
disable TLS 1.3 and by not override the default ciphersuits
with an empty string.
So, only override OpenSSL's TLS 1.3 ciphersuites with an explicit
list of ciphers. If none are acceptable, the correct approach is
to disable TLS 1.3 instead elsewhere.
Fixes: https://github.com/nodejs/node/issues/43419
PR-URL: https://github.com/nodejs/node/pull/43427
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: James M Snell <jasnell@gmail.com>
The internal use of tls.parseCertString was removed in
a336444c7f. The function does not handle
multi-value RDNs correctly, leading to incorrect representations and
security concerns.
This change is breaking in two ways: tls.parseCertString is removed
(but has been runtime-deprecated since Node.js 9) and
_tls_common.translatePeerCertificate does not translate the `subject`
and `issuer` properties anymore.
This change also removes the recommendation to use querystring.parse
instead, which is similarly dangerous.
PR-URL: https://github.com/nodejs/node/pull/41479
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Tim Perry