TLS Encrypted Client Hello (ECH) with `tls-alpn-01` ACME challenges?

[impurify]

Does Let’s Encrypt support TLS Encrypted Client Hello (ECH, formerly known as ESNI) with tls-alpn-01 ACME challenges? DuckDuckGoOnion searches site:community.letsencrypt.org "ech" and site:letsencrypt.org "ech" returned no results; Discourse forum search too-“helpfully” returned results for “echo”.

I’m currently hurrying to set up my new websites before the 2025-01-25 deadline to get beautiful OCSP Must-Staple certificates. (That will be the subject of another thread...) I carefully selected a webserver that supports OCSP stapling with draconian Must-Staple enforcement (I read the code, and it refuses to serve Must-Staple certificates without a valid staple!), TLS ECH, and support for BoringSSL with both draft and standard post-quantum KEX. (No, not anything written in Go.) To stand against censorship and to protect reader privacy, I tentatively intend to make most of my sites ECH-only straight from the start; my only hesitation is that it will currently block all Tor Browser users. Then, I realized that Let’s Encrypt may not support ECH with tls-alpn-01. Does it?

If it does, then please consider this a “feature request” for documentation. If not, then...

Let’s encrypt our client hellos! IIUC, here are the necessary steps for Let’s Encrypt:

1. When the DNS lookup for the domain is made, lookup and parse HTTPS Resource Records (RR type 65) in accord with RFC 9460: “Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)”.

2. If an ECH key is found, use it to encrypt the validation hello.

BoringSSL with its “live at the head” policy supports ECH. For OpenSSL support, see the DEfO project and the ECH feature branch. I don’t know of any other SSL/TLS libraries with current support for ECH.

dns-01 challenges are a fallback unless/until Let’s Encrypt supports ECH, but it would be disappointing to use that after I selected a webserver partly based on tls-alpn-01 support.

I haven’t yet tested how my webserver’s early ECH support interacts with its tls-alpn-01 support, but I’ve already been otherwise patching the TLS code and can probably fix it if it breaks.

I also have no idea what the proper workflow is for setting up a bunch of sites from scratch this way. I suppose that I first need to obtain a TLS certificate for the site shown in the outer ClientHello, and then set up the ECH-protected sites. Live and learn!

[rmbolger]

I don't have anything useful to contribute. I just wanted to say I'm happy there are folks with the time and patience to push and test the bleeding edge of this stuff. You're helping make us all more secure and I thank you.

[orangepizza]

RFC8737

The ACME server initiates a TLS connection to the chosen IP address. This connection MUST use TCP port 443. The ACME server MUST provide an ALPN extension with the single protocol name "acme-tls/1" and an SNI extension containing only the domain name being validated during the TLS handshake.

Don't think CA can put something else in outer SNI extension while keep following defined process.

[Nummer378]

I think that LE's TLS implementation for tls-alpn-01 is TLS from golang's crypto/tls package, so client-side ECH support is depending on golang supporting it. Golang did add support for client-side ECH last year, with initial support landing in Go 1.23. However, it looks like enabling this requires the library user (e.g. boulder) to bring-your-own logic to fetch the ECH keys. From a search in boulder, the TLS code used for TLS-ALPN-01 is a very ordinary crypto/tls connection that has no ECH logic.

So in short, the likely answer is no.

[mcpherrinm]

Let's Encrypt doesn't support ECH at this time, but we're looking at it for the future. It isn't likely to ship in the next few months at least.

[mholt]

@impurify

(No, not anything written in Go.)

Wait until February.