Bug in Lynx's SSL certificate validation – leaks password in clear text via SNI

  authority   = [ userinfo "@" ] host [ ":" port ]

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.

https://en.wikipedia.org/wiki/Server_Name_Indication

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.

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.