When a piece of server software wants to make itself available to clients via the network, it binds to a socket. A socket is simply the IP address and port combination the server software listens on for connections. (Most commonly server software chooses to listen on a particular port across all available network interfaces). What happens though if a particular server wants to serve multiple, different sites from the same server on the same port? One option would be to assign the server multiple IP addresses, but this introduces administrative complexity. Another option would be to interrogate the contents of the traffic coming into the server in order to make a decision as to which site the traffic should rightfully route to. While feasible for un-encrypted traffic, encryption quickly thwarts this strategy.
What is SNI
Server Name Indication (SNI) is a commonly supported extension to TLS which acts as a “selector” allowing the client to specify a particular host header. It was first defined in RFC 3546. The destination server uses this information in order to properly route traffic to the intended service. SNI is most commonly used for HTTPS traffic, but this extension can be used with other services wrapped in SSL/TLS as well. SNI information is sent in the client’s initial ClientHello message (part of the SSL/TLS handshake).
An inherently flawed approach
It is a recurring theme that as the years go by, computer security becomes ever more important. Long gone are the days where we build protocols without considering transport encryption (looking at you SMTP!), but only recently has the concept of a “zero trust” network become something we are all trying to achieve. We must constantly reevaluate our underlying assumptions and the things which we take for granted. In much the same way it is no longer considered reasonably secure to terminate SSL/TLS at your enterprise edge and allow traffic to reach your backing servers over HTTP, announcing to an attacker listening on the wire what service you are connecting to is unwise, albeit only in hindsight. As the internet becomes more and more politicized, in some parts of the world, visiting a particular website can be quite literally a matter of life and death.
Unfortunately, by the time this was considered, it was much too late to fix. Versions of TLS before 1.3 include the certificate sent by the server in clear text as well, so even if the SNI value were to be encrypted, it would be for naught. Note that while the server certificate portion was moved to the encrypted portion of the handshake, there still remains an un-encrypted portion of the SSL/TLS handshake which can leak other information potentially useful to attackers.
ESNI and ECH: A long overdue overhaul
TLS 1.3 sends the server certificate later on in the conversation, no longer exposing the endpoint a user is visiting in the plaintext portion of its response. This signaled that it was time to reevaluate SNI, and Encrypted SNI (ESNI) was born. ESNI relies on a server publishing a DNS record specifying a public key. From there, Diffie-Hellman is used to agree upon a symmetric key suitable for encrypting the SNI value in the Client Hello. Astute readers will realize that DNS is also a historically plaintext information exchange, and replacing a plaintext piece of information in the ClientHello with a plaintext DNS call adds no value. ESNI is expected to be used in conjunction with DNS-over-HTTPS (DOH) or DNS-over-TLS (DOT), closing the loop.
ESNI has been supported by popular browsers and sites since 2018, but it too is not without its flaws. ESNI, simply put, is not prescriptive enough regarding how to handle or mitigate failures, leading to inconsistent server behavior making it difficult to write reliable clients. Cloudflare, who has been at the fore of the move to ESNI, has pivoted their stance and now champions something called Encrypted Client Hello (ECH). This proposed standard would encrypt the entire handshake using a similar but more prescriptive scheme, solving two problems at once by fixing the flaws of ESNI and removing the plaintext initial handshake altogether. ECH also relies on DNS and relies equally on DOH or DOT.
Conclusion
The internet has always been a hodge-podge of confusing and competing standards. There is something exquisitely Darwinian about the whole affair, and in the coming months and years we will see whether ECH truly accomplishes the goals it sets out to achieve or whether other, unexpected challenges prevent wide adoption. One thing is clear however, the cadence at which fundamental technologies change is only speeding up.