What if he wanted to use it for requesting blog.cloudflare.com
;; ANSWER SECTION:
blog.cloudflare.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.18.28.7,104.18.29.7 ipv6hint=2606:4700::6812:1c07,2606:4700::6812:1d07
For example,
;; ANSWER SECTION:
test.defo.ie. 300 IN HTTPS 1 . ech="AEb+DQBCqQAgACBlm7cfDx/gKuUAwRTe+Y9MExbIyuLpLcgTORIdi69uewAEAAEAAQATcHVibGljLnRlc3QuZGVmby5pZQAA"
;; ANSWER SECTION:
cloudflare-ech.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.18.10.118,104.18.11.118 ech="AEX+DQBBpQAgACB/RU5hAC5mXe3uOZtNY58Bc8UU1cd4QBxQzqirMlWZeQAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA=" ipv6hint=2606:4700::6812:a76,2606:4700::6812:b76
But ECH has never been consistently enabled for the general public beyond a small number of test sites that are only for testing ECH
https://developer.apple.com/documentation/security/sec_proto...
Presumably anyone besides Safari can opt-in to that testing today, but I wouldn’t ship it worldwide and expect nice outcomes until (I suspect) after this fall’s 27 releases. Maybe someone could PR the WebKit team to add that feature flag in the meantime?
But, in a personal/single website server, ech does not really add privacy, adversaries can still observe the IP metadata and compare what's hosted there. The real benefits are on huge cloud hosting platforms.
"Nginx 1.30 incorporates all of the changes from the Nginx 1.29.x mainline branch to provide a lot of new functionality like Multipath TCP (MPTCP)."
"Nginx 1.30 also adds HTTP/2 to backend and Encrypted Client Hello (ECH), sticky sessions support for upstreams, and the default proxy HTTP version being set to HTTP/1.1 with Keep-Alive enabled."
But, in a personal/single website server, ech does not really add privacy, adversaries can still observe the IP metadata and compare what's hosted there
I don't quite follow. I have dozens of throw-away silly hobby domains. I can use any of them as the outer-SNI. How is someone observing the traffic going to know the inner-SNI domain unless someone builds a massive database of all known inner+outer combinations which can be changed on a whim? ECH requires DOH so unless the ISP has tricked the user into using their DOH end-point they can't see the HTTPS resource record.
If I had a long running site I could do the same thing by having multiple font-end caching nodes using HAProxy or NGinx that come and go but I acknowledge others may not have the time to do that and most probably would not.
That's cool. I only make my own mini-CDN's.
There is always the option to put sites on a .onion domain but I don't host anything nearly exciting or controversial enough. For text that's probably a good option. I don't know if Tor is fast enough for binary or streaming sites yet. No idea how many here even know how to access a .onion site.
I will test out your theory and see if anyone bothers to track my IP addresses and does anything with them. I probably need to come up with something edgy that people would want to block. Idea's for something edgy?
So e.g. they'd work for exactly the way you use say TLS 1.0 in the Netscape 4 web browser which was popular when the middlebox was first marketed, or maybe they cope with exactly the features used in Safari but since Safari never sets this bit flag here they reject all connections with that flag.
What TLS learned is summarized as "have one joint and keep it well oiled" and they invented a technique to provide that oiling for one working joint in TLS, GREASE, Generate Random Extensions And Sustain Extensibility. The idea of GREASE is, if a popular client (say, the Chrome web browser) just insists on uttering random nonsense extensions then to survive in the world where that happens you must not freak out when there are extensions you do not understand. If your middlebox firmware freaks out when seeing this happen, your customers say "This middlebox I bought last week is broken, I want my money back" so you have to spend a few cents more to never do that.
But, since random nonsense is now OK, we can ship a new feature and the middleboxes won't freak out, so long as our feature looks similar enough to GREASE.
ECH achieves the same idea, when a participating client connects to a server which does not support ECH as far as it knows, it acts exactly the same as it would for ECH except, since it has neither a "real" name to hide nor a key to encrypt that name it fills the space where those would fit with random gibberish. As a server, you get this ECH extension you don't understand, and it is filled with random gibberish you also don't understand, this seems fine because you didn't understand any of it (or maybe you've switched it off, either way it's not relevant to you).
But for a middlebox this ensures they can't tell whether you're doing ECH. So, either they reject every client which could do ECH, which again that's how you get a bunch of angry customers, or, they accept such clients and so ECH works.