In particular, in the era before SNI support was widespread, your bulk host would charge extra to give you a dedicated IP address so that your HTTPS site worked. It's still an option at some bulk hosts today, you can have free HTTPS that works fine in every browser anybody actually uses or you can pay a few bucks extra so that it also works with the archaic system that one customer never updates.
With cloudfront it's not just one IP, it's potentially one at every edge node. But yeah, every time I see that pricing I get a little chuckle because it's so obviously deterrent pricing - it's not how much the IP address costs, it's the minimum amount Amazon wants for dealing with your bullshit.
Beyond that, it was absolutely essential to decouple address from identity in order to move the vast majority of sites and services on the Internet to TLS.
Somehow I’ve avoided gaining an understanding of the details of the SNI protocol, so i can’t comment on its quality, but the achievement it has enabled is fairly profound.
When a client connects to a TLS server it may (must in TLS 1.3 if it knows the name of the service) send a field labelled Server Name Indication that gives a name it intended to reach.
The SNI specification explains one type of name, a Fully Qualified Domain Name e.g. "news.ycombinator.com" (notice not "news.ycombinator.com." if you understand why that might matter) but leaves open the possibility that others could exist. They don't and in practice you likely couldn't add new ones now.
The server should look at this name & use it to decide what the client intended. For example if you're a bulk hosting site you might have fifty customers on a single physical machine and you can match the SNI name against the list of customer sites on that machine, then use this to present the appropriate certificates and use the right keys so the connection works and is trusted by the client for that name.
For HTTPS the server should further reason that if the SNI says news.ycombinator.com but then an HTTP/1.1 Host header says some.other.example that's nonsense and deserves an error. Likewise it should reason that if you send SNI for this.does.not.exist.example and it has no records of a this.does.not.exist.example site, it should just give you the TLS error saying it doesn't recognise the name and never get to HTTP at all.
In practice several popular web server programs (e.g. Apache) treat these two stages as entirely unrelated problems, so you can connect to a bulk host, use SNI to say you want corpA.example, and then in HTTP/1.1 ask for corpB.example and it's common that the web server will give you the corpB.example web site, but served with the corpA.example certificates and encryption... if you send SNI for this.does.not.exist.example you may get a randomly chosen or alphabetically first certificate and then an HTTP 404 error...
The more modern ALPN is similar but for protocols instead of names, this lets clients specify which "next" protocols they want to speak on top of TLS. So for example "h2" means you'd like to use HTTP/2 instead of HTTP/1.1 to talk to a web server. The server can reply to ALPN by specifying which of the list you offered it agrees to e.g. it can say it only speaks HTTP/1.1 -- or it can ignore your request entirely.
> Somehow I’ve avoided gaining an understanding of the details of the SNI protocol
You put the requested hostname (e.g. example.com) into the Client Hello message in cleartext so that the server knows which SSL site to direct you to / which SSL cert to give you. And the server has a config that matches up server certs with hostnames (and a default server cert) to return.
That's it. It's why people want to encrypt the client hello message, because that leaks info.
Under IPv6 the original pressure for "virtual hosts" and eventually SNI wouldn't necessarily have existed because there are plenty of addresses.
However I suspect that by now somebody would have spotted that we're smuggling the thing we actually wanted to convey via the IPv6 address. some.specialised.thing.example resolves to an address with a particular combination of low 64-bits which are then de-coded by server software listening on that entire subnet as some.specialised.thing.example. And somebody would have proposed just actually transmitting the text across the wire instead.
So I expect that today SNI would exist or at least, the exact same discussion that led to eSNI and today ECH would have happened for other reasons in the world where everybody has IPv6 and the fix for that would be under development.
If you have plentiful IPv6 addresses the privacy aspect still matters, but maybe it gets pushed out further and we're only talking about it now rather than earlier.
Yes there is still a 1-1 mapping from IPv6 to domain, but that mapping is pushed back into the DNS layer where it belongs instead of being smuggled (poorly) through TLS. DNS isn't perfect for privacy either, but at least there's a chance that it can be solved with DoH / private dns servers / etc, instead of the only solution (eSNI) requiring everyone voluntarily signing up to a giant mitm called "cloudflare".
The problem with just solving DNS privacy is that Winnie doesn't care whether you "privately" resolved the name or not, blocking the entire server works fine when each server corresponds to one name. The ability of users to privately resolve winnie-the-pooh.china.example to 10.20.30.40 doesn't help when Winnie can just block 10.20.30.40 entirely.
One of the things we see with the Great Firewall is that you can reach some brand new service, and then a few minutes later (after presumably some automation span up, examined it and didn't like what it found) it's blocked.
In contrast under ECH Winnie can choose to have 10.20.30.40 blocked, and if the only things on it are winnie-the-pooh.china.example and kick-putin-out.russia.example then why not. But if it also features popular-website.example then that's a difficulty.
If it helps while I expect Cloudflare will continue as before, ECH is actually carefully designed so that intermediates can be set up to be able to discern that you want winnie-the-pooh.example and make that work without in fact knowing how to answer for that name. In effect you can sign up to have some popular host (e.g. Google, Amazon, or indeed Cloudflare) provide their servers for your names, but not provide your services and not have any ability to MITM you, they're acting as a sort of IP proxy instead. And some of the big names are clearly enthusiastic about enabling this capability, albeit for a price.
It's really easy to make a mapping of domain names to IPs. If you want a chance at privacy, you need load balancer IPs that have a huge number of sites behind them.
