tls: add support for Encrypted Client Hello (ECH) — tracking (OpenSSL 4.0 / master)

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

• Previous (stale-closed) tracking issue: #31618
• Upstream OpenSSL ECH (targeting 4.0 / in master): https://github.com/openssl/openssl/issues/7482

The issue names no Node.js source file or test; begin with the node:tls tls.connect API and the OpenSSL 4.0 ECH APIs once the bundled dependency is available. Done means Node exposes the agreed caller-supplied ECH configuration and handshake outcome, with DNS integration treated according to the final scope.