Say (an encrypted) hello to a more private internet.

Sort of. They can still see which IP address you're connecting to, which by itself or in combination with some minor traffic analysis is quite often enough to identify which website you've visited. Perhaps it isn't if the website puts absolutely everything through a giant CDN like Cloudflare, but in that case it's Cloudflare which gets to see all the sites you visit which isn't a whole lot better than the status quo.

Still, it's a little less information given away at least some of the time. Better to do it than not do it.

Yes and no. If your isp is still providing unencrypted DNS for you, then they can still see the domain name you're visiting.

That's how I understood it. With regular https your doing on those websites is already encrypted, but your ISP or whoever sits in between can still se which sites you're visiting. As far as I understand this standard would encrypt this step too.

Usually with these kind of engine-features, the rollout is simultaneous on desktop and Android.

And it says it's rolling out with version 118 here: https://support.mozilla.org/en-US/kb/understand-encrypted-client-hello

It's been a couple years since I was involved with ECH, but the implementations at the time were:

The one by the draft's authors in golang (Cloudflare). This is the actual test server. It uses Cloudflare's fork of golang with an enhanced crypto library. https://gist.github.com/cjpatton/da8814704b8daa48cb6c16eafdb8e402

BoringSSL used for chrome. There are nginx builds with BoringSSL, but I don't know if the setting are exposed.

https://boringssl.googlesource.com/boringssl/+/refs/heads/master/ssl/encrypted_client_hello.cc

WolfSSL which I never got around to playing with.

https://www.wolfssl.com/encrypted-client-hello-ech-now-supported-wolfssl/

NSS which is Mozilla's TLS library. There is a test server buried in there some place for unit testing.

https://firefox-source-docs.mozilla.org/security/nss/index.html

With that, you ALSO need a DNS server that supports DNS over HTTP (DoH) and HTTPS service binding records (https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/).

Bind9 had branches for both and I was able merge the two to satisfy that requirement.

When connecting to such a server, you MUST NOT use a DNS resolver hosted by any origination along the path from client to server as they can correlate the host from the DNS request with your encrypted client hello. You can actually man-in-the-middle ECH to decrypt the client hello by overriding the hosts record when controlling the DNS resolver. My project was testing this for parental controls.

Keep in mind, ECH really only benefits users connecting to a CDN. That is, when multiple services are behind the same IP. It masks which host the user is going to for any hop between the client and server.

Any data mining company worth their evils will have an IP to DNS index to figure out the host when only one is behind an IP.

This marginally gives some privacy to users. It hides the host from your ISP. It REALLY benefits browser companies and CDN hosts. What hosts a user is visiting now becomes exclusive data for those companies thereby driving up the value of the data. Assuming you aren't being stupid with your addons.

I think it requires you shut your pihole. Um. sorry. Ill let myself out.

It sounds like you'll have to set your Pihole as the DNS server in Firefox's settings, and then maybe from there it'll work itself out? Or maybe the Pihole documentation will be updated in the next few days with some instructions on enabling this. I'm unsure myself to be honest.

I don't think so, that'd be straight up impossible unless you're behind a VPN. Your ISP can see every connection made between you and any other server, but a VPN uses encrypted payloads between their servers and you, and they make the requests using their servers, and pass the results to you. That way, your ISP only sees that you're using a VPN, but can't see anything else.

As far as I understand it, ECH uses DoH (DNS Over HTTPS) to encrypt the domain name of your connections, but a direct IP address is always required, and most of the times, it's enough to determine the website, as the ISPs can locate just about anything easily. However, the ISP won't be able to (easily) know anything else about the connection, which remains unbroken between you and the server you're connecting with.

But still a very good feature nonetheless.

It's being worked on. https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni