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.
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.
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.
Funnily enough, not setting the SNI and connecting the the origin IP, and then requesting the page worked fine.