RFC 9849. TLS Encrypted Client Hello

Glad that it's published, I'd been following it since ESNI draft days. Was pretty useful back when I was in India since Jio randomly blocked websites, and cloudflare adopted the ESNI draft on its servers as did Firefox client side which made their SNI based blocking easy to bypass.

There was a period where I think both disabled ESNI support as work was made on ECH, which now is pretty far along. I was even able to setup a forked nginx w/ ECH support to build a client(browser) tester[0].

Hopefully now ECH can get more mainstream in HTTPS servers allowing for some fun configs.

A pretty interesting feature of ECH is that the server does not need to validate the public name (it MAY) , so clients can use public_name's that middleboxes (read: censors) approve to connect to other websites. I'm trying to get this added to the RustTLS client[1], now might be a good time to pick that back up.

[0] https://rfc9849.mywaifu.best:3443/ [1] https://github.com/rustls/rustls/issues/2741

I wrote about ECH a couple of months ago, when the specs were still in draft but already approved for publication. It's a short read, if you're not already familiar with ECH and its history: https://www.feistyduck.com/newsletter/issue_127_encrypted_cl...

In addition to the main RFC 9849, there is also RFC 9848 - "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings": https://datatracker.ietf.org/doc/rfc9848/

There's an example of how it's used in the article.

(Disclosure: I'm a Caddy maintainer), Caddy already supports ECH, leaning on the DNS plugins to automate setting the DNS HTTPS records to wire it up. Here's a lot of technical detail about it https://caddyserver.com/docs/automatic-https#encrypted-clien...

one angle that hasn't come up here yet: ECH basically kills TLS fingerprinting as a bot detection signal

right now tools like Cloudflare Bot Management rely heavily on JA3/JA4 hashes - they fingerprint the ClientHello to identify scrapers vs real browsers. if the ClientHello is encrypted, that whole detection layer collapses. you can still do behavioral analysis and JS challenges, but the pre-HTTP layer that currently catches a huge chunk of naive bots - gone

curious how Cloudflare handles this internally given they're one of the biggest ECH adopters but also one of the biggest bot detection vendors. seems like they're eating their own lunch on this one, or they've already shifted their detection stack to not rely on it as much

One topic I have not seen discussed is why CDNs, one by one, stopped allowing "domain fronting" yet ECH, developed by people working at CDNs, essentially uses a similar tactic, i.e., two hostnames, only one of them actually needed for a successful HTTP request

In truth ECH sends three: Host header + real SNI + dummy SNI

Every time some security related protocol relies on DNS for its magic (looking at you, ACME), I lament the state of DNS providers. They all have different APIs, with different levels of security. Most at least offer some kind of REST API with API tokens for auth, which is relatively easy to set up.

Many of those (not looking at any particular Germans..) however only offer a single API token across all DNS zones, which is awful when you're managing many zones. One compromised API token = hundreds of compromised zones.

Would be nice if more DNS providers offered granular API tokens, at least on a per-zone basis and ideally on a per-record basis within a zone.

Something that puzzles me about ECH:

> In verifying the client-facing server certificate, the client MUST interpret the public name as a DNS-based reference identity [RFC9525]. Clients that incorporate DNS names and IP addresses into the same syntax (e.g. Section 7.4 of [RFC3986] and [WHATWG-IPV4]) MUST reject names that would be interpreted as IPv4 addresses.

Aside from apparently not considering the existence of IPv6, why are IP-based certificates explicitly ruled out? This makes the spec entirely meaningless for small servers and basically requires shifting hosting to shared hosts/massive CDNs to provide any protection against SNI snooping.

Will the adoption of this RFC prevent corporate MITM attacks like Zscaler TLS inspection?

I've written a visual article about TLS ECH, in case anyone doesn't have time to read this RFC: https://growingswe.com/blog/tls-ech

It's an interesting feature, but it's pushing my buttons lately. Specifically on Cloudflare it is on by default, and on the free tier you can't disable it and you need a business plan for it. Which I think is stupid, but never the less it's causing us problems. We are trying some split-dns setup for a company "intranet", and if the site's have be accessed before, the ECH is remembered. So the browser tries and it eventually fails with ECH Error or on Firefox it just hangs like it's loading all the time. And it's so frustrating, because sometimes it works, sometimes it doesn't, you can clear cache and stuff and it still won't work, sometimes it works in Incognito sometimes it doesn't. This is not a real problem, but since we haven't fully switched to the "intranet" and we use some of the WAF features of Cloudflare sometimes it is so frustrating.

TLS Encrypted Client Hello (ECH) standard is another attempt on encrypting plaintext Server Name Indication (SNI). It is very useful for circumventing SNI-based censorship, which is adopted for years by state-backed systems like the Great Firewall (GFW).

The previous attempt of encrypting plaintext SNI is Encrypted Server Name Indication (ESNI), which didn't end well.

This would kill SNI proxies, correct?

Oh snap. Say I'd like to compute some JA4 hashes on my server. I know this can be done as the server has the keys required. But is there a ready made solution that can account for ECH and compute JA4 as a proxy? Please? I saw HAProxy should work and I know that nginx module for JA4 is incomplete, are you please aware of other solutions for self-hosting?

I know this has nothing to do with the RFC, but I wonder what RFC 10000 will be. I'm just hoping for some sort of joke RFC like TCP over Avian Carriers or the Oops I'm A teapot.

I'm okay advertising ECH as a privacy enhancement, it is, but make no mistake, it will not prevent government tracking or censorship. Governments will request platforms to disable ECH or ask for other signals to be reported, and ban those who don't comply. You can't fight political issues solely with technology.

ECH is great from a privacy perspective, but I’m curious how well this will actually work in practice.every time the web encrypts more metadata there’s pushback from middleboxes and network operators.

Will this have an impact on Loadbalancers? Like does one have to do client side load balancing like in gRPC?

If only we had some technology that would relieve us of the need to share IP addresses among multiple servers, this might have been unnecessary.

[dead]

[dead]