What is the problem this feature will solve?
Node.js has no support for Encrypted Client Hello (ECH). The node:tls module (and everything built on it, including undici/fetch) always sends the SNI in plaintext, so applications cannot make TLS connections with an encrypted ClientHello the way modern browsers (Firefox, Chrome) already do.
There was a previous tracking issue for this, #31618 ("tls: Encrypted Client Hello (ECH)"), but it was auto-closed by the stale bot in Oct 2022 due to inactivity — not because it was implemented. At that time the feature was explicitly blocked on OpenSSL, per the maintainers:
"ESNI is still in draft ... can't be supported by Node.js until OpenSSL supports it."
Status of the upstream dependency
ECH is now standardized as RFC 9849 (March 2026), and OpenSSL's ECH tracking issue openssl/openssl#7482 was closed as completed on 2026-03-04 (merge openssl/openssl#30086). Per the closing comment:
"ECH support for this RFC will be in OpenSSL 4.0 and is already in the master branch."
So the important nuance: ECH is in OpenSSL master, targeting the 4.0 release — it is not in the 3.5 line that Node currently bundles. This request is therefore not immediately actionable; it is a tracking issue for when Node bundles an OpenSSL that includes ECH (4.0+). Filing it now so the requirement is captured, since the old #31618 is stale-closed.
What is the feature you are proposing to solve the problem?
Once Node bundles an OpenSSL with ECH (4.0+), expose that ECH API through node:tls. Concretely:
- A
tls.connect() option to supply the config material, e.g. echConfigList (a Buffer containing the server's ECHConfigList), mirroring OpenSSL's SSL_ech_set1_echconfig() / SSL_CTX_ech_set1_echconfig().
- A way to surface the ECH outcome after the handshake (accepted / rejected / retry-config), e.g. via
SSL_ech_get1_status(), so callers can distinguish real ECH from GREASE.
- Optionally, resolver integration so the
ECHConfigList from a HTTPS/SVCB DNS RR can be used (browsers fetch it from DNS). Could start with a caller-supplied config and add DNS integration later.
Consumers like undici/fetch would then inherit ECH support.
What alternatives have you considered?
- Shelling out to an ECH-enabled
curl build — requires a custom curl build and loses the native API.
- A native N-API addon calling
SSL_ech_* — Node's bundled OpenSSL (3.5.x) doesn't include ECH, so this needs a rebuilt Node against OpenSSL 4.0/master.
- Driving a headless browser — far too heavy and doesn't measure a clean protocol-level request.
None of these are a substitute for first-class support in node:tls.
Related
What is the problem this feature will solve?
Node.js has no support for Encrypted Client Hello (ECH). The
node:tlsmodule (and everything built on it, includingundici/fetch) always sends the SNI in plaintext, so applications cannot make TLS connections with an encrypted ClientHello the way modern browsers (Firefox, Chrome) already do.There was a previous tracking issue for this, #31618 ("tls: Encrypted Client Hello (ECH)"), but it was auto-closed by the stale bot in Oct 2022 due to inactivity — not because it was implemented. At that time the feature was explicitly blocked on OpenSSL, per the maintainers:
Status of the upstream dependency
ECH is now standardized as RFC 9849 (March 2026), and OpenSSL's ECH tracking issue openssl/openssl#7482 was closed as completed on 2026-03-04 (merge openssl/openssl#30086). Per the closing comment:
So the important nuance: ECH is in OpenSSL master, targeting the 4.0 release — it is not in the 3.5 line that Node currently bundles. This request is therefore not immediately actionable; it is a tracking issue for when Node bundles an OpenSSL that includes ECH (4.0+). Filing it now so the requirement is captured, since the old #31618 is stale-closed.
What is the feature you are proposing to solve the problem?
Once Node bundles an OpenSSL with ECH (4.0+), expose that ECH API through
node:tls. Concretely:tls.connect()option to supply the config material, e.g.echConfigList(aBuffercontaining the server'sECHConfigList), mirroring OpenSSL'sSSL_ech_set1_echconfig()/SSL_CTX_ech_set1_echconfig().SSL_ech_get1_status(), so callers can distinguish real ECH from GREASE.ECHConfigListfrom aHTTPS/SVCBDNS RR can be used (browsers fetch it from DNS). Could start with a caller-supplied config and add DNS integration later.Consumers like
undici/fetchwould then inherit ECH support.What alternatives have you considered?
curlbuild — requires a custom curl build and loses the native API.SSL_ech_*— Node's bundled OpenSSL (3.5.x) doesn't include ECH, so this needs a rebuilt Node against OpenSSL 4.0/master.None of these are a substitute for first-class support in
node:tls.Related