That’s likely due to iOS/macOS not supporting it in production-default-enabled yet; there’s an experimental opt-in flag at the OS level, but Safari apparently hasn’t (yet) added a dev feature switch for it.
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?
Nginx mainline 1.29.x supports it.
So once you get that and also the openssl version on your system, good to go.
Likely too late for ubuntu 26.04, maybe in debian 14 next year, or of course rolling release distros / containers.
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.
FWIW Nginx 1.30 [1] just released and supports it so most distributions will have support as soon as those responsible for builds and testing builds push it forward.
"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.
It's not that adversaries can directly see the domain name; this doesn't have anything to do with domain fronting. The issue is that ECH doesn't hide the server's IP address, so it's mostly useless for privacy if that IP address uniquely identifies that server. The situation where it helps is if the server shares that IP address with lots of other people, i.e., if it's behind a big cloud CDN that supports ECH (AFAIK that's currently just Cloudflare). But if that's the case, it doesn't matter whether Nginx or whatever other web server you run supports ECH, because your users' TLS negotiations aren't with that server, they're with Cloudflare.
I can't speak for anyone else but I think I can work around that by moving the site around to different VPS nodes from time to time. I get bored with my silly hobby sites all the time and nuke the VM's then fire them up later which gives them a new IP. I don't know what others might do if anything.
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 not quite it. The issue is that there's no other traffic bound to that IP - ECH doesn't buy you any security, because an observer doesn't even need to look at the content of the traffic to know where it's headed.
Maybe it will be more useful for outbound from NGinx or HAProxy to the origin server using ECH so the destination ISP has no idea what sites are on the origin assuming that traffic is not passing over a VPN already.
Anyone who wants to track your users can just follow the IP changes as they occur in real time.
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?
Doesn't matter, I (not OP, but also operating VPS) still want to support this, so the clients can eventually assume all correctly configured servers support it.
TLS (the IETF Working Group not the protocol family named for them) have long experience with the fact that if you specify how B is compatible with A based on how you specified A and ship B what you did won't work because the middleboxes are all cost optimized and don't implement what you specified but instead whatever got the sale for the least investment.
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.
Just be aware any reasonable network will block this.
Russia blocked it for Cloudflare because the outer SNI was obviously just for ECH but that won't stop anyone from using generic or throw-away domains as the outer SNI. As for reasonable I don't quite follow. Only censorious countries or ISP's would do such a thing.
I can foresee Firewall vendors possibly adding a category for known outer-SNI domains used for ECH but at some point that list would be quite cumbersome and may run into the same problems as blocking CDN IP addresses.
You'd say incorrectly, firewalls have an implicit deny rule, so any case ICMP traverses a firewall, someone wanted it to. Obviously large hosting providers tend to find value in ICMP being enabled.
But for example, our firewall at work responds to ICMP but all of the endpoints which aren't meant for public use do not. That is less because ICMP is a problem and more because everything works fine without it and least privilege is good design.
ICMP is also more than just ping, and some parts of ICMP are considered a vulnerability if exposed to the public internet by some scanning services.
That kind of cargo culted tradition is how you end up with weird packet loss and VPNs that flat-out refuse to work.
I could be convinced to block inbound pings. Anything past that and I'd want solid evidence that it wouldn't break anything, with the expectation that it would.
address-mask-request and redirect and timestamp-request for IPv4 might be problematic to allow inbound from who knows where. echo-request might well be rate limited so remote hosts can ping certain servers (but not random client host IPs), but not too many pings per second.
That’s not a meaningful issue here. Either snoop competently or snoop wire traffic, pick one.
In the snooping-mandatory scenario, either you have a mandatory outbound PAC with SSL-terminating proxy that either refuses CONNECT traffic or only allows that which it can root CA mitm, or you have a self-signed root CA mitm’ing all encrypted connections it recognizes. The former will continue functioning just fine with no issues at providing that; the latter will likely already be having issues with certificate-pinned apps and operating system components, not to mention likely being completely unaware of 80/udp, and should be scheduled for replacement by a solution that’s actually effective during your next capital budgeting interval.
A good solution is tackling it on both. At work we have network level firewalls with separate policies for internal and guest networks, and our managed PCs sync a filter policy as well (through primarily for when those devices are not on our network). The network level is more efficient, easier to manage and troubleshoot, and works on appliances, rogue hardware, and other things that happen not to have client management.
Any "reasonable" network just sees a regular Client Hello, the rest is encrypted. They designed it with your very concern in mind to obscure that the ECH even happens.
Eventually these blocks won't be viable when big sites only support ECH. It's a stopgap solution that's delaying the inevitable death of SNI filtering.
This will never happen. Because between enterprise networks and countries with laws, ECH will end up blocked a lot of places.
Big sites care about money more than your privacy, and forcing ECH is bad business.
And sure, kill SNI filtering, most places that block ECH will be happy to require DPI instead, while you're busy shooting yourself in the foot. I don't want to see all of the data you transmit to every web provider over my networks, but if you remove SNI, I really don't have another option.
So, if you are not at minimum inspecting SNI, you are not meaningfully providing security for your network. Where I work we do not really pay attention to what people are doing with their computers (that is an HR problem, not an IT problem), but the prevalence of ransomware almost certainly starts and ends with people not making rational network security decisions, which starts with filtering. We also remove the ads. =)
Enterprises own the device that I'm connected to the network with, I don't see how you can get any more invasive than that.
> countries with laws
1) what countries do national-level SNI filtering, and 2) why are you using a hyptothetical authoritarian, privacy invading state actor as a good reason to keep plaintext SNI?
> Big sites care about money
Yes, and you could say that overbearing, antiquated network operators stop them from making more money with things like SNI filtering.
There is nothing in the open source licensees that prevents charging money, in fact, non-commercial clauses are seen as incompatible with the Debian Free Software Guidelines.
And there is a lot of companies out there that make their money based on open source software, red hat is maybe the biggest and most well known.
I meant in the sense that someone else can redistribute the source for free, not that the company has to do it.
> The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
This doesn't solve the issue that globalism caused. Europe doesn't make DRAM nor has the know-how to quickly bring factories online which usually take 10+ years.
We are tied to American economy and if AI companies start driving prices up not only DRAM but basically everything will become more expensive.
Building a factory is one thing, they can have 50 of them built, but that doesn't mean much if all 50 together amount to like 0.1% of the company's output.
Once those factories scale up to 1-2%, then we can start considering that they've actually built a domestic supply, but that's a whole different goal than simply building the factories. Building factories is trivial. Making them output something is also "trivial". Scaling that up to a meaningful amount is a whole different, much harder goal to accomplish.
Yes, I'm pretty confident you don't know anything about manufacturing at scale.
Say you use a magic wand and build 15 new state-of-the-art factories tomorrow. Who's gonna run them? Does any location in the US have enough qualified workers that can simply take over and produce RAM in them from day 1 with no major fuckups?
No, you need a ton of time to teach thousands of people how to run those 15 factories. To even begin to teach people, you need to have 1 factory up and running. That 1 factory is at first going to be run by some of their existent workforce that they temporarily migrate from South Asia. Only then can they start to teach local populace how to run those factories on their own.
This is why it's much cheaper to simply build an additional one in South Asia than it is to build more than one in a whole new location. South Asia already has a bunch of workers that know what they're doing because they've been doing it for a long time. Build a new factory, promote some of your existent workforce up the chain, fill the lowest positions with fresh graduates that are gonna be equally good every year and you're good to go. It's nowhere near that simple in a brand new location, where even the most optimistic scenario would take longer than a decade to produce a meaningful amount of output.
Not to mention, given recent US immigration enforcement actions at various manufacturing plants, you can't even safely bring in overseas workers to train your domestic workforce...
It looks like it's still a big difference between how the US and EU are responding to the chip supply wars. The US is actually building their own manufacturing capabilities domestically while the EU is apparently doing nothing, which is unfortunate.
There is also https://www.vishay.com/ which expanded several sites in .de, without much fuss, or begging for subsidies. That is neither RAM, HBM, NAND, nor NOR, but nonetheless much needed stuff, for all the electrified cyber.
Infineon is _opening_ its fab plant in Dresden this year which was supported by around 1bn euros from the EU equivalent of the CHIPS Act. They started building this fab in 2023, while TSMC, who started building its fab in the US right after covid just delayed the opening to 2027
The fab that Infineon is building is vastly smaller in scale, and their tech isn't really relevant to this discussion. For instance, it doesn't produce CPU/GPU microchips or DRAM. Also only 300mm wafer technology, which isn't competitive for anything except for some narrow industrial use-cases. Glad to see the EU is doing it, but it's a completely different thing.
Pretty much everyone is on 300 mm wafers for everything now, and has been for a while. Are you perhaps reading this as 300
nm process (which would usually be called 0.3 micron)?
But in the context of what we are talking about it's still true that nobody in the EU is making cutting edge CPU/GPU/DRAM and there are no plans to do so either (including that Infineon fab).
> Currently, 100% of leading-edge DRAM production occurs overseas, primarily in East Asia.[0]
They make DRAM for cars, not computers, in the USA. They've promised they'll bring manufacturing onshore any time soon, which effectively means they'll wait until Trump forgets about it.
Well first of all, the CHIPS Act was not "axed", it is federal law passed by an overwhelming bipartisan majority of the House and Senate. It would take a complete reversal of congress to repeal it and it's still very popular among both parties.
> Well first of all, the CHIPS Act was not "axed", it is federal law passed by an overwhelming bipartisan majority of the House and Senate. It would take a complete reversal of congress to repeal it and it's still very popular among both parties.
DOGE cut basically all staff from the CHIPS Program Office, congress passed the money but Trump is choosing to turn it into a slush-fund the admin spends on industrial policy (such as buying a stake in Intel). Wolfspeed went into bankruptcy in part because the admin delayed CHIPS funding agreed by the previous admin [1] (it's unclear whether they received the grant now that they have left it).
This is news to a lot of Americans! The 2022 CHIPS and Science Act is codified federal law. I think a lot of states (Arizona, Idaho, New York) would be very interested to learn that the funding for the infrastructure that they are already building has somehow gone poof.
Intel is now partially government owned(10%), they got rid of some of the milestones. The current administration has been extremely poor about communicating changes as well as constantly yanking funding (or threatening to) for projects - the chances of funding going poof are higher than ever.
American companies are driving global economy insane. Currently the American political administration sides with the AI companies since it gives the inspiration that the economy is doing well. If things start to go side ways, the US government can put pressure on its local companies like Micron to supply other fields.
Europe doesn't have local manufacturers. So it cannot exert control over the manufacturers to keep its internal / strategic market sane. All European hardware manufacturers have to put up with and compete in irrationality inflated prices.
However, the US government has / can have control over Micron's production. They are headquartered in the US. They have the intellectual property and know-how to erect a vertically integrated supply chain. Europe doesn't have this strategic investment.
The newfound desire to move away from American cloud providers isn’t related to pricing, it’s about the perception of growing instability within the American government, the perception of deteriorating freedom of speech, and the perception of an increasingly non-neutral business environment.
E.g., if I’m running a business in the US and I don’t kiss Trump’s ring (and pay bribes), if he becomes dictator for life in 2028, all bets are off for my business.
Both the EU and USA import the majority of their computer equipment, and the USA is placing heavy and unpredictable tariffs on those goods. It’s hard to argue that a business should bet that data centers will be cheaper in the US than in the EU if Trump is the last democratically elected president.
The most stable places to do business in 2026 are probably the EU and China.
reply