None of these constants have any effect in recent OpenSSL versions, not
even in Node.js release lines that still use OpenSSL 1.1.1.
It is likely rare that these options are still used (intentionally), and
removing them is unlikely to break any existing applications. These
constants can only be passed to the secureOptions option of
tls.createSecureContext() and related APIs, and a value of undefined
will be ignored. Similarly, if a bitwise combination of multiple options
is used, undefined constants will not change the behavior because
(a | undefined | b) === (a | b) for (small) integers a and b.
Refs: https://github.com/nodejs/node/pull/46954
Refs: https://github.com/nodejs/node/pull/47066
PR-URL: https://github.com/nodejs/node/pull/47073
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
This constant was likely introduced for feature detection, but it has
been pointless for a long time.
1. I am not aware of any possible Node.js build configuration (on any
recent/supported release line) that would have crypto.constants but
not crypto.constants.ALPN_ENABLED.
2. There is no evidence of this constant being used for feature
detection in the ecosystem. In fact, both internal and external type
definitions for crypto.constants simply assume that the constant
exists.
3. There is no good reason for any modern TLS stack to not support ALPN.
It looks like ALPN might have been optional in much earlier versions
of OpenSSL, but all recent versions of OpenSSL unconditionally
support ALPN as far as I can tell.
Refs: https://github.com/nodejs/node/pull/46956
PR-URL: https://github.com/nodejs/node/pull/47028
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Yagiz Nizipli
Tobias Nießen
Mestery