7 ms·

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 cloud

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/ https://rfc9849.mywaifu.best:3443/ [1] https://github.com/rustls/rustls/issues/2741 https://github.com/rustls/rustls/issues/2741

ignoramous 7mo ago
> 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 https://news.ycombinator.com/item?id=34232190
- arch-choot 7mo ago
  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 7mo ago
    > 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.
    - ignoramous 7mo ago
      > Such tricks, called "domain fronting" GP said "not setting SNI"... doing TLS handshake with IP certs don't (need to) set SNI?
      - tialaramex 7mo ago
        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.
maxloh 7mo ago
Why didn't the Indian government block traffics based on IP instead? That would make it much harder to bypass.
- arch-choot 7mo ago
  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/ https://blog.cloudflare.com/consequences-of-ip-blocking/
  - ffsm8 7mo ago
    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
  - boondongle 7mo ago
    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.
    - 7mo ago
arowthway 7mo ago
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 7mo ago
  I saw this used to obfuscate spam yesterday! Yay?
- Ms-J 7mo ago
  This is a good feature for getting past blocks. I'm happy that this RFC is published.
ndriscoll 7mo ago
> 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.
- josefx 7mo ago
  > "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 7mo ago
    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 7mo ago
      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.

ignoramous 7mo ago

> 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 https://news.ycombinator.com/item?id=34232190

arch-choot 7mo ago
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 7mo ago
  > 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.
  - ignoramous 7mo ago
    > Such tricks, called "domain fronting" GP said "not setting SNI"... doing TLS handshake with IP certs don't (need to) set SNI?
    - tialaramex 7mo ago
      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.

maxloh 7mo ago

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

arch-choot 7mo ago
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/ https://blog.cloudflare.com/consequences-of-ip-blocking/
- ffsm8 7mo ago
  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
- boondongle 7mo ago
  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.
  - 7mo ago

arowthway 7mo ago

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 7mo ago
I saw this used to obfuscate spam yesterday! Yay?
Ms-J 7mo ago
This is a good feature for getting past blocks. I'm happy that this RFC is published.

ndriscoll 7mo ago

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

josefx 7mo ago
> "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 7mo ago
  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 7mo ago
    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.