| SNI goes like this: 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. |