[arch-choot]

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

[arowthway]

The server can also advertise a public name that doesn't match any domain it has a TLS certificate for, like example.com or nsa.gov.

I'm not 100% sure it's allowed in the specs, but it works in Chrome.

As I understand it, without this feature it would be pretty useless for small website owners, since they would need to register a separate domain for their ECH public name, which censors could just block.

[shae]

I saw this used to obfuscate spam yesterday! Yay?

[Ms-J]

This is a good feature for getting past blocks.

I'm happy that this RFC is published.

[ignoramous]

> Was pretty useful back when I was in India since Jio randomly blocked websites

With Jio, you don't really need ECH at all. The blocks are mostly rudimentary and bypassed with encrypted DNS (DoH / DoT / DNSCrypt) and Firefox (which fragments the TLS ClientHello packets into two).

Also: https://news.ycombinator.com/item?id=34232190

[arch-choot]

Should've added this was back in like 2018 or so. Setting up DoH was harder than enabling SNI, and from my testing back then they were hard filtering on SNI (e.g. I used OpenSSL CLI to set the SNI to `pornhub.com` and connect to "known good" IPs, it'd still get reset).

Funnily enough, not setting the SNI and connecting the the origin IP, and then requesting the page worked fine.

[tialaramex]

> Funnily enough, not setting the SNI and connecting the the origin IP, and then requesting the page worked fine.

Such tricks, called "domain fronting" are why ECH exists. The problem is that although domain fronting is effective for the client it's a significant headache for the provider. Big providers involved, such as Cloudflare have always insisted that they want to provide this sort of censorship resisting capability but they don't want to authorize domain fronting because it's a headache for them technically.

Let me explain the headache with an example. Say I'm Grand Corp, a French company with 25 million web sites including both cats-are-great.example and fuck-trump.example. Users discover that although the US government has used Emergency Powers to prohibit access to fuck-trump.example, using domain fronting they can connect to cats-are-great.example and request fuck-trump.example pages anyway and the US government's blocking rules can't stop them.

What they don't know is that I, Grand Corp had been sharding sites 25 ways, so there was only 1-in-25 chance that this worked - it so happened cats-are-great and fuck-trump were in the same shard, On Thursday during routine software upgrade we happen to switch to 32-way sharding and suddenly it stops working - users are outraged, are the French surrendering to Donald Trump?

Or, maybe as a fallback mechanism the other 31 servers can loop back around to fetch your fuck-trump.example pages from the server where they live, but in doing so they double the effective system load. So now my operational costs at Grand Corp for fuck-trump.example doubled because clients were fronting. Ouch.

[arch-choot]

Could you clarify a bit more what you mean by "Domain Fronting is why ECH exists"?

Because even with ECH, you (TLS client) can set any public_name you want, but the innerSNI can be something else.

Or is that what you mean; since the providers can "ignore" the OuterSNI, they can rely on the InnerSNI to still route traffic?

[tialaramex]

Yes, you've basically got it, the customers for fuck-trump.example just write your chosen value in OuterSNI and fuck-trump.example in the InnerSNI, which is encrypted and you do the (very cheap on modern hardware) decryption and route fuck-trump.example. In practice it might work (but isn't guaranteed to) to write something else in OuterSNI like whitehouse.gov rather than the value chosen by the operator.

It's apparent from other responses that most people didn't understand that we're not talking about a weird new feature which might work if people implement it. This is the published document explaining how it works, but the reality is that it's widely deployed today. This is already how it's working today, if you tell people first they raise all sorts of objections and insist it's unworkable, so, we didn't tell them first we just did it. Here's a relevant quote:

"Dan, I'm not a Republic serial villain. Do you seriously think I'd explain my master-stroke if there remained the slightest chance of you affecting its outcome? I did it thirty-five minutes ago" -- Watchmen, by Alan Moore.

[ignoramous]

> Such tricks, called "domain fronting"

GP said "not setting SNI"... doing TLS handshake with IP certs don't (need to) set SNI?

[tialaramex]

That's true, usually with domain fronting you provide the (wrong) SNI. But the same strategy is happening here, you were supposed to provide SNI and you didn't to avoid some potential censorship but it's a headache for the provider

They won't have received a certificate for the IP as a name, it's relatively unusual to have those, the main users are things like DoH and DoT servers since their clients may not know the name of the server... historically if you connect to a TLS server without SNI it just picks a name and presents a certificate for that name - if there's a single name for the machine that definitely works, and if not well - domain fronting.

TLS 1.3 even specifies that you must always do SNI and shouldn't expect such tricks to work, because it's such a headache.

[arch-choot]

An example for the hub:

``` echo -e "GET / HTTP/1.1\r\nHost: www.pornhub.com\r\nConnection: close\r\n\r\n" | openssl s_client -connect 66.254.114.41:443 -quiet ```

This works for most ISPs in India, but if you set the SNI it'll get a TCP reset

[maxloh]

Why didn't the Indian government block traffics based on IP instead? That would make it much harder to bypass.

[arch-choot]

If i'm not mistaken its because IPs are actually much easier to rotate than domains.

E.g. all the users will remember `example.com` , underlying it doesn't matter what IP it resolves to. If the IP gets "burned" , then the providers can rotate to a new IP (if their provider allows).

Vs. telling your users to use a new domain `example.org` , fake websites etc.

Also sensible ISPs usually don't block IPs since for services behind a CDN it could lead to other websites being blocked, though of course sometimes this is ignored. See also: https://blog.cloudflare.com/consequences-of-ip-blocking/

[boondongle]

I wouldn't say you're mistaken, but it's a simplification. In the network world, the capability exists to restrict what BGP advertisements are accepted via RPKI/a peer. Internet providers usually don't because the premium is placed on uptime/connectivity.

If tomorrow, everyone said "we don't want IP's from Frankfurt showing up somewhere in Dubai", you'd have a massive technical problem and rearranging to start with but once that was sorted you could geo-lock. IANA and Network providers simply haven't been doing that.

The reason it doesn't happen is Devs/Stakeholders want uptime from ISPs/Networks and not something they can't abstract. Basically its just a status quo much like the entire internet reverse-proxying through CDNs is a status quo. It wasn't always like that, and it may not always be like that in the future - just depends which way the winds blow over time.

[sgjohnson]

> we don't want IP's from Frankfurt showing up somewhere in Dubai

what do you mean, IPs from Frankfurt?

IP addresses are just IP addresses, they know no geographical boundaries. In RIR DBs you can geolocate them to wherever you want. Which is the entire reason why Geo IP DBs even exist - they triangulate.

[icehawk]

> "we don't want IP's from Frankfurt showing up somewhere in Dubai"

From a network perspective statements like that make no sense. IP addresses don't have any sort of physicality,

[pocksuppet]

They have registration data. Someone could declare they don't want IPs registered to companies from Frankfurt with geofeeds in Frankfurt to be advertised in Dubai.

[sgjohnson]

It’s not how any of it works.

How do you determine to whom an IP is even registered to? They get sub-leased all the time.

The best you can do is check who has administrative control over the prefixes RIR info, but that doesn’t mean that anyone with control is the factual user of the IPs.

You could check the IRR for the ASN and base it on that, but still.

There's also no way to actually know _where_ an IP actually originates from. Only its AS path.

The DFZ contains all prefixes announced everywhere, for the internet is completely decentralized.

[ffsm8]

That's why you have a strictly legal domain that enables a convoluted redirect with plausible deniability (not 302)

It'll still eventually stick, but a lot slower

[ndriscoll]

> 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.

Note that it is exactly this type of thing that makes age verification laws reasonable. You're making it technically impossible for even sophisticated parents to censor things without a non-solution like "don't let kids use a computer until they're 18", so naturally the remaining solution is a legal one to put liability on service operators.

You're still ultimately going to get the censorship when the law catches up in whatever jurisdiction, but you'll also provide opacity for malware (e.g. ad and tracking software) to do its thing.

[AgentK20]

How does ECH make it impossible for parents to control their children's access to computers? Sure they can't block sites at the router level, just like your ISP won't be able to block things at the ISP level, but you (the parent) have physical access to the devices in question, and can install client-side software to filter access to the internet.

The only thing this makes impossible is the laziest, and easiest to bypass method of filtering the internet.

[EvanAnderson]

Because there are network operators who have mal-intent increasingly no network operators are permitted to exercise network-level control. A parent who wants to filter the network access in their house is the same as a despotic regime practicing surveillance and censorship on their citizens.

Given that it's pretty much the norm that consumer embedded devices don't respect the owner's wishes network level filtering is the best thing a device owner can do on their own network.

It's a mess.

I'd like to see consumer regulation to force manufacturers to allow owners complete control over their devices. Then we could have client side filtering on the devices we own.

I can't imagine that will happen. I suspect what we'll see, instead, is regulation that further removes owner control of their devices in favor of baking ideas like age or identity verification directly into embedded devices.

Then they'll come for the unrestricted general purpose computers.

[JoshTriplett]

If you have a device you don't trust, don't allow it on your network, or have an isolated network for such devices. Meanwhile, devices are right to not allow MITMing their traffic and to treat that as a security hole, even if a very tiny fraction of their users might want to MITM it to try to do adblocking on a device they don't trust or fully control, rather than to exploit the device and turn it into a botnet.

Along similar lines, a security hole you can use for jailbreaking is also a security hole that could potentially be exploited by malware. As cute as things like "visit this webpage and it'll jailbreak your iPhone" were, it's good that that doesn't work anymore, because that is also a malware vector.

I'd like to see more devices being sold that give the user control, like the newly announced GrapheneOS phones for instance. I look forward to seeing how those are received.

[EvanAnderson]

> If you have a device you don't trust, don't allow it on your network...

That's what I do. That means large swaths of potentially interesting "smart" devices are unavailable to me (since they won't work without Internet access and I'm unable to inspect their traffic). I'm not too heartbroken about it, but it does make me a little sad that I don't get to use some of this "we're living in the future" tech.

> ...devices are right to not allow MITMing their traffic and to treat that as a security hole...

> ...a security hole you can use for jailbreaking is also a security hole that could potentially be exploited by malware...

Yes. Complete agreement. Devices are right not to allow unauthorized parties to MiTM their traffic, tinker w/ their innards, etc. I would never suggest otherwise.

Owners, with physical access, should be permitted to MITM the traffic, tinker with the innards, etc. They're authorized parties.

Device manufacturers should compelled by regulation to allow device owners, with physical access, to examine and manipulate the device internals. I'm thinking of the "developer mode" physical switches on Chromebook devices. If I own it I should have the same access to the device the manufacturer does.

If a manufacturer's business / security model isn't compatible with this regulation the manufacturer should be required to deal with any e-waste concerns and it should clearly be marketed as a rental and not a sale.

None of this will ever happen. I know I'm tiling at windmills. The tech world will continue to get more locked-down, the public will lose unfettered access to general purpose computers, and the personal computer revolution will become a distant memory. We already lost and could never really win because "normies" don't care about this stuff.

[JoshTriplett]

> If a manufacturer's business / security model isn't compatible with this regulation the manufacturer should be required to deal with any e-waste concerns and it should clearly be marketed as a rental and not a sale.

I would be generally in favor of this. I don't like the idea of forbidding building a device that's locked down; there are potential use cases for such a thing. I do like the idea of saying "either allow tinkering or you are subject to numerous other things, like warranty / liability laws".

[ndriscoll]

Network segmentation does nothing for the types of attacks these devices perform (e.g. content recognition for upload to their tracking servers, tracking how you navigate their UI, ad delivery). I'm not worried about them spreading worms on my network. The problem is their propensity to exfiltrate data or relay propaganda. The solution to that is a legal one, or barring that, traffic filtering.

[JoshTriplett]

That was my motivation for the "or" (don't allow it on your network, or put it on an isolated network); it depends on your threat model and what the device could do. Some devices (like "smart" TVs) shouldn't have network access at all.

[ndriscoll]

"Sure, you can use my wifi while you're over. Just enroll in MDM real quick".

As brought up in another thread on the topic, you have things like web browsers embedded in the Spotify app that will happily ignore your policy if you're not doing external filtering.

[AgentK20]

Fair point.

I guess it (network-level filtering) just feels like a dragnet solution that reduces privacy and security for the population at large, when a more targeted and cohesive solution like client-side filtering, having all apps that use web browsers funnel into an OS-level check, etc would accomplish the same goals with improved security.

[ndriscoll]

I think the population at large generally needs to get over their hangups (actually, maybe they have, and it's just techies). No one in a first world country cares if you visit pornhub just like no one cares if you go to amazon. Your ISP has had the ability to see this since the beginning of the web. It does not matter, but we can also have privacy laws restricting their (and everyone else like application/service vendors) ability to record and share that information. If you really want, you can hide it with a VPN or Tor. As long as not everything is opaque, it's easy to block that traffic if you'd like (so e.g. kids can't use it). In a first world country, this works fine since actually no one cares if you're hiding something, so you don't need to blend in. At a societal level, opaque traffic is allowed.

You could have cooperation from everyone to hook into some system (California's solution), which I expect will be a cover for more "we need to block unverified software", or you could allow basic centralized filtering as we've had, and ideally compel commercial OS vendors to make it easy to root and MitM their devices for more effective security.

[iamnothere]

Yes well some of us live in first world countries that are at risk of declining into third world status, where some states DO actually care what sites you visit and would jump at the chance to further restrict traffic.

Rather than “get over” it I think we need to fight. You seem to insist that monitoring/control is a done deal and we only need to argue about the form it takes, but this is not correct. Centralized monitoring/control can be resisted and broken through a combination of political and technical means. While you may not want this, I do. (And many others are being swayed back in my direction as they start to feel the effects of service enshittification, censorship under the guise of “fighting misinformation”, and media consolidation.)

[Bjartr]

There's nothing technical stopping device manufacturers from making this easy for parents to do. They choose not to.

[hnav]

A lot of endpoint protection products rely on SNI sniffing. E.g. Apple's network extensions filters look at TLS handshakes.

[afiori]

Then they would drop the connection with esni

[bnjms]

This is exactly reverse of the right idea. If parents need to censor things the solutions are the same as corpos are going to. Put the censors at the device or “mitm” the connection, either actually with a proxy, or maybe with a browser and curated apps - which is again on the device.

[ndriscoll]

This brings us back to "sure you can use my guest wifi, just install my root CA/enroll in MDM".

I do agree though that it should be illegal for device manufacturers or application developers to use encryption that the device owner cannot MitM. The owner should always be able to install their own CA and all applications should be required to respect it.

[pocksuppet]

Why would you want to censor based on network? You don't want to censor based on network, you want to censor based on device. If your 8yo kid is blocked from pornhub, that doesn't mean everyone on your network is blocked from pornhub, and you having the ability to even know if someone on your network is browsing pornhub is a security risk.

[ndriscoll]

Because consumer devices are barely if at all capable of even setting policy, are basically incapable of enforcing it, and are generally adversarial. It's also easy to apply different policies to different clients at the network level.

[pocksuppet]

The new California and Colorado laws force consumer devices to be capable of setting and enforcing policy.

[josefx]

> "don't let kids use a computer until they're 18"

Ideally you would lock them up in a padded room until then. There is a significant amount of shared real world space that isn't supervised and doesn't require any age verification to enter either.

[ndriscoll]

Notably, explicitly adult spaces like bars and porn shops are not among them, and a significant amount of virtual space would also not require age verification for the same reason.

[tialaramex]

Rules vary. In Britain it was completely normal for say 15-year old me to be in a bar - it was illegal to buy booze but not a problem to be there. But when I travelled to Austin aged 19 I couldn't meet adult members of my team in the hotel bar because I wasn't old enough even though by then I was legal to drink, to marry, to go to war and so on in my own country.

A little while after that, back in the UK, I drove my young cousin to the seaside. I didn't carry ID - I don't drink and you're not required to carry ID to drive here† so it was never necessary back then, but she did, so I try to buy her booze, they demand ID, I do not have any ID so I can't buy it even though I'm old enough to drink. So, she just orders her own booze, she's under age but they don't ask because she's pretty.

† The law here says police are allowed to ask to see a driving license if you're in charge of a vehicle on a public road, but, since you aren't required to carry it they can require you to attend a police station and show documents within a few days. In practice in 2026 police have network access and so they can very easily go from "Jim Smith, NW1A 4DQ" to a photo and confirmation that you're licensed to drive a bus or whatever if you are co-operative.

[Hizonner]

Like what? The AV maniacs apparently want to apply it to any and all "spaces" where you might actually communicate with anybody.

[kstrauser]

My right to access free information, and my global neighbor’s right to read unofficial information without being jailed or killed for it, outweighs your right to let your right use the Internet without supervision.

[ndriscoll]

Sure, and if we want to prioritize your ability to do so despite living in an authoritarian hellhole, those of us in countries that respect their citizens rights will have to put these verification systems in place. It just needs to be understood by technologists building this stuff that this is the tradeoff they're making.

And it's likely a temporary win there until the authoritarian regimes mandate local monitoring software and send you to the gulag if they detect opaque traffic.

[kstrauser]

Ironically, or perhaps not, I think we’re both posting from the US. I am.