Encrypted server name indication (ESNI) helps keep user browsing private. It does this by encrypting a previously unencrypted part of the TLS handshake that can reveal which website a user is visiting.
After reading this article you will be able to:
Copy article link
Encrypted server name indication (ESNI) is an essential feature for keeping user browsing data private. It ensures that snooping third parties cannot spy on the TLS handshake process to determine which websites users are visiting. ESNI, as the name implies, accomplishes this by encrypting the server name indication (SNI) part of the TLS handshake.
SNI tells a web server which TLS certificate to show at the start of a connection between the client and server. SNI is an addition to the TLS protocol that enables a server to host multiple TLS certificates at the same IP address.
Think of SNI as being like the apartment number on a mailing address: multiple apartments are in one building, so each apartment needs a different number to distinguish it. Similarly, while the server is indicated by the IP address, a client device needs to include SNI in its first message to the server to indicate which website (which apartment) it is trying to reach.
Transport Layer Security, or TLS for short, is an encryption protocol that keeps communications private and secure on the Internet. TLS is used mostly to encrypt the communication between applications and web servers, like when web browsers load a website. All websites that use TLS must have a TLS certificate. TLS is sometimes called SSL, although SSL is an outdated name for the protocol.
All TLS connections start with something called a "handshake." Just as a handshake is used in real life when two people meet and exchange introductions, the TLS handshake is a series of introductory communications between a client device (like a user's smartphone) and a web application or website. During a TLS handshake, the two communicating devices agree on what encryption keys to use, among other steps. Despite the number of steps involved, a TLS handshake takes only a few milliseconds.
SNI is a small but crucial part of the first step of the TLS handshake. The first message in a TLS handshake is called the "client hello." As part of this message, the client asks to see the web server's TLS certificate. The server is supposed to send the certificate as part of its reply.
The problem is, many web servers host more than one website, and each website may have its own TLS certificate. If the server shows the wrong one to the client, then the client will be unable to connect securely to the desired website, resulting in a "Your connection is not private" error.
SNI solves this problem by indicating which website the client is trying to reach. Paradoxically, no encryption can take place until after the TLS handshake is successfully completed using SNI. As a result, regular SNI is not encrypted because the client hello message is sent at the start of the TLS handshake. Any attacker monitoring the connection between the client and the server could determine which website the client was connecting with by reading the SNI part of the handshake, even though all further communications are indecipherable to the attacker. (Attackers could use this information in a number of ways — setting up a phishing website to trick the user, for instance.)
ESNI keeps SNI secret by encrypting the SNI part of the client hello message (and only this part). Encryption only works if both sides of a communication — in this case, the client and the server — have the key for encrypting and decrypting the information, just as two people can use the same locker only if both have a key to the locker. Because the client hello message is sent before the client and server have negotiated TLS encryption keys, the ESNI encryption key has to be communicated some other way.
The solution: public key cryptography. The web server adds a public key to its DNS record, so that when the client looks up where to find the right server, it finds the server's public key as well. This is somewhat like leaving a house key in a lockbox outside one's home so that a visitor can safely enter the home. The client can then use the public key to encrypt its SNI record in such a way that only that specific server can decrypt it. (This is a somewhat simplified explanation; for a lengthier technical explanation, see this blog post.)
Imagine that Alice wants to visit Bob's website, www.bobisawesome.example.com. Like every responsible website owner should, Bob uses TLS for his website so that all traffic to and from his website is encrypted. Bob has also implemented ESNI to further protect site visitors like Alice.
When Alice types https://www.bobisawesome.example.com into her laptop's browser, her laptop goes through the following process for loading the website:
*This last statement is only true if the DNS part of the process used DNSSEC and either DNS over HTTPS or DNS over TLS — more below.
ESNI is a major step towards privacy and security on the web, but other new protocols and features are important as well. The Internet was not designed with security and privacy in mind, and as a result there are a number of steps in the process of visiting a website that are not private. However, various new protocols are helping to encrypt and secure each step from malicious attackers.
The Domain Name System, or DNS, matches human-readable website addresses like www.bobisawesome.example.com to alphanumerical IP addresses. It is like looking up someone's address in a large address book that everyone uses. However, normal DNS is not encrypted, meaning anyone could see which address someone is looking up, and anyone could pretend to be the address book. Even with ESNI in place, an attacker could see what DNS records users are querying and figure out which websites they are visiting.
DNS over TLS and DNS over HTTPS both do the same thing: encrypt DNS queries with TLS encryption. The main differences between them are what layer of the network they use and which network port they use. DNSSEC verifies that DNS records are real and come from a legitimate DNS server, not from an attacker impersonating a DNS server (as in a DNS cache poisoning attack).
The Cloudflare network has supported ESNI since September 2018. Not only was Cloudflare the first major network to support ESNI, but Cloudflare was also instrumental in developing ESNI. ESNI has not yet been published as an official RFC, or Internet standard, but a draft RFC is in the works.
Learning Center Navigation