checkServerIdentity() stopped matching an IPv6 host against a matching
IP-Address SAN. The hostname is now run through domainToASCII() before
the net.isIP() gate, and domainToASCII('::1') === '' (an IPv6 literal is
not a domain), so net.isIP('') is 0, the IP-SAN branch is skipped, and
verification fails with "Cert does not contain a DNS name". IPv4 is
unaffected because dotted-decimal survives domainToASCII().
Match IP hosts against the original hostname instead of the IDNA-
normalized one. net.isIP() rejects non-ASCII input, so there is no IDNA
confusion to guard against for an IP literal; the normalized form is
still used for the DNS-name path.
Fixes: https://github.com/nodejs/node/issues/64144
Signed-off-by: Pascal Garber <pascal@artandcode.studio>
PR-URL: https://github.com/nodejs/node/pull/64145
Reviewed-By: Tim Perry <pimterry@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>
This patch makes the off-thread loading lazy and only done when the
`tls` builtin is actually loaded by the application. Thus if the
application never uses tls, it would not get hit by the extra
off-thread loading overhead. paving the way to enable --use-system-ca
by default.
PR-URL: https://github.com/nodejs/node/pull/59856
Reviewed-By: James M Snell <jasnell@gmail.com>
This API allows dynamically configuring CA certificates that
will be used by the Node.js TLS clients by default.
Once called, the provided certificates will become the default CA
certificate list returned by `tls.getCACertificates('default')` and
used by TLS connections that don't specify their own CA certificates.
This function only affects the current Node.js thread.
PR-URL: https://github.com/nodejs/node/pull/58822
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
To accompany --use-system-ca, this adds a new API that allows
querying various kinds of CA certificates.
- If the first argument `type` is `"default"` or undefined,
it returns the CA certificates that will be used by Node.js
TLS clients by default, which includes the Mozilla CA
if --use-bundled-ca is enabled or --use-openssl-ca is not
enabled, and the system certificates if --use-system-ca
is enabled, and the extra certificates if NODE_EXTRA_CA_CERTS
is used.
- If `type` is `"system"` this returns the system certificates,
regardless of whether --use-system-ca is enabeld or not.
- If `type` is `"bundled"` this is the same as `tls.rootCertificates`
and returns the Mozilla CA certificates.
- If `type` is `"extra"` this returns the certificates parsed
from the path specified by NODE_EXTRA_CA_CERTS.
Drive-by: remove the inaccurate description in `tls.rootCertificates`
about including system certificates, since it in fact does not include
them, and also it is contradicting the previous description about
`tls.rootCertificates` always returning the Mozilla CA store and
staying the same across platforms.
PR-URL: https://github.com/nodejs/node/pull/57107
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>
Previously, Node.js incorrectly accepted uniformResourceIdentifier (URI)
subject alternative names in checkServerIdentity regardless of the
application protocol. This was incorrect even in the most common cases.
For example, RFC 2818 specifies (and RFC 6125 confirms) that HTTP over
TLS only uses dNSName and iPAddress subject alternative names, but not
uniformResourceIdentifier subject alternative names.
Additionally, name constrained certificate authorities might not be
constrained to specific URIs, allowing them to issue certificates for
URIs that specify hosts that they would not be allowed to issue dNSName
certificates for.
Even for application protocols that make use of URI subject alternative
names (such as SIP, see RFC 5922), Node.js did not implement the
required checks correctly, for example, because checkServerIdentity
ignores the URI scheme.
As a side effect, this also fixes an edge case. When a hostname is not
an IP address and no dNSName subject alternative name exists, the
subject's Common Name should be considered even when an iPAddress
subject alternative name exists.
It remains possible for users to pass a custom checkServerIdentity
function to the TLS implementation in order to implement custom identity
verification logic.
This addresses CVE-2021-44531.
CVE-ID: CVE-2021-44531
PR-URL: https://github.com/nodejs-private/node-private/pull/300
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This change introduces JSON-compatible escaping rules for strings that
include X.509 GeneralName components (see RFC 5280). This non-standard
format avoids ambiguities and prevents injection attacks that could
previously lead to X.509 certificates being accepted even though they
were not valid for the target hostname.
These changes affect the format of subject alternative names and the
format of authority information access. The checkServerIdentity function
has been modified to safely handle the new format, eliminating the
possibility of injecting subject alternative names into the verification
logic.
Because each subject alternative name is only encoded as a JSON string
literal if necessary for security purposes, this change will only be
visible in rare cases.
This addresses CVE-2021-44532.
CVE-ID: CVE-2021-44532
PR-URL: https://github.com/nodejs-private/node-private/pull/300
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This encapsulates the Node.js errors more by adding extra properties
to an error inside of the function to create the error message instead
of adding the properties at the call site. That simplifies the usage
of our errors and makes sure the expected properties are always set.
PR-URL: https://github.com/nodejs/node/pull/26752
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
This introduces TLS1.3 support and makes it the default max protocol,
but also supports CLI/NODE_OPTIONS switches to disable it if necessary.
TLS1.3 is a major update to the TLS protocol, with many security
enhancements. It should be preferred over TLS1.2 whenever possible.
TLS1.3 is different enough that even though the OpenSSL APIs are
technically API/ABI compatible, that when TLS1.3 is negotiated, the
timing of protocol records and of callbacks broke assumptions hard-coded
into the 'tls' module.
This change introduces no API incompatibilities when TLS1.2 is
negotiated. It is the intention that it be backported to current and LTS
release lines with the default maximum TLS protocol reset to 'TLSv1.2'.
This will allow users of those lines to explicitly enable TLS1.3 if they
want.
API incompatibilities between TLS1.2 and TLS1.3 are:
- Renegotiation is not supported by TLS1.3 protocol, attempts to call
`.renegotiate()` will always fail.
- Compiling against a system OpenSSL lower than 1.1.1 is no longer
supported (OpenSSL-1.1.0 used to be supported with configure flags).
- Variations of `conn.write('data'); conn.destroy()` have undefined
behaviour according to the streams API. They may or may not send the
'data', and may or may not cause a ERR_STREAM_DESTROYED error to be
emitted. This has always been true, but conditions under which the write
suceeds is slightly but observably different when TLS1.3 is negotiated
vs when TLS1.2 or below is negotiated.
- If TLS1.3 is negotiated, and a server calls `conn.end()` in its
'secureConnection' listener without any data being written, the client
will not receive session tickets (no 'session' events will be emitted,
and `conn.getSession()` will never return a resumable session).
- The return value of `conn.getSession()` API may not return a resumable
session if called right after the handshake. The effect will be that
clients using the legacy `getSession()` API will resume sessions if
TLS1.2 is negotiated, but will do full handshakes if TLS1.3 is
negotiated. See https://github.com/nodejs/node/pull/25831 for more
information.
PR-URL: https://github.com/nodejs/node/pull/26209
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
The existing secureProtocol option only allows setting the allowed
protocol to a specific version, or setting it to "all supported
versions". It also used obscure strings based on OpenSSL C API
functions. Directly setting the min or max is easier to use and explain.
PR-URL: https://github.com/nodejs/node/pull/24405
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
Pascal Garber