This would kill SNI proxies, correct?
RFC 9849. TLS Encrypted Client Hello
71–80 of 159 posts
Re: RFC 9849. TLS Encrypted Client Hello
#72Earlier quoted context omitted.
> 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
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.
> 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.
Re: RFC 9849. TLS Encrypted Client Hello
#73Earlier quoted context omitted.
They do routing. Even if you're connecting to a non Cloudflare server, the traffic may still be routed through their servers. Why would they want to peek traffic? Most likely for statistics (most frequently visited websites etc).
Can you give an example of a BGP route or traceroute to a site not on Clownflare that was routed through Clownflare?
It depends on the origin and the destination. Their Magic Transit service explicitly allow this, and I assume they have agreements with other AS in case something goes wrong on either side (it often does). You'd have to directly ask them to know specifically but I don't think they would answer since that's proprietary information.
Re: RFC 9849. TLS Encrypted Client Hello
#74Glad 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 se…
Why didn't the Indian government block traffics based on IP instead? That would make it much harder to bypass.
[deleted]
Re: RFC 9849. TLS Encrypted Client Hello
#75Earlier quoted context omitted.
Why didn't the Indian government block traffics based on IP instead? That would make it much harder to bypass.
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 servic…
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.
Re: RFC 9849. TLS Encrypted Client Hello
#76If only we had some technology that would relieve us of the need to share IP addresses among multiple servers, this might have been unnecessary.
If every server has its own IP then the privacy leak comes from merely connecting to it. It makes ECH useless, but that's not the same thing as making it unnecessary.
Re: RFC 9849. TLS Encrypted Client Hello
#77(Disclosure: I'm a Caddy maintainer), Caddy already supports ECH, leaning on the DNS plugins to automate setting the DNS HTTPS records to wire it up. Here's a lot of technical detail about it https://caddyserver.com/docs/automatic-https#encrypted-clien...
Nginx also supports ECH now, since the December release.
Re: RFC 9849. TLS Encrypted Client Hello
#78Glad 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 se…
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.
Re: RFC 9849. TLS Encrypted Client Hello
#79Oh snap. Say I'd like to compute some JA4 hashes on my server. I know this can be done as the server has the keys required. But is there a ready made solution that can account for ECH and compute JA4 as a proxy? Please? I saw HAProxy should work and I know that nginx module for JA4 is incomplete, are you please aware of other solutions for self-hosting?
Re: RFC 9849. TLS Encrypted Client Hello
#80Earlier quoted context omitted.
ECH doesn't benefit you if you're connecting directly to one IP. Middleboxes can track that you're connecting to this IP. ECH prevents tracking through routing layers where your ClientHello might contain foo.example.com or bar.example.com but route via the same IP (Cloudflare). A middlebox can see you are using a cloudflare hosted website, but not know what cloudflare website. There's no benefit encrypting the SNI wi…
THe benefit is that the SNI is not being logged. Resolving an IP to a domain name is pretty hard for a small actor who doesn't have a record of all DNS records.
That's a good point. I was thinking more of a "block this list of wrongthink TLDs" use case, but "list all hostnames accessed by person x" is of course also worth considering.