ESNI: The Road Not Taken
What is ESNI?
In order to understand ESNI or Encrypted Server Name Indicator, we first must understand what SNI is.
Server Name Indication (SNI) is an extension within the Transport Layer Security (TLS) protocol (version 1.3, which is still new, as of October 2021) by which a client indicates which hostname it is attempting to connect to at the start of the TLS handshaking process. This allows a server to present one of the multiple certificates on the same IP address and TCP Port Number and multiple secure (e.g. HTTPS enabled) websites to be served by the same IP address without requiring all those sites to use the same certificate.
This is a particularly sophisticated feature that also helped us alleviate the IPv4 Address Exhaustion.
But unfortunately, exposing in plaintext what website the client is requesting is a privacy risk. Any third-party middleman can snoop in on the TLS (version 1.3) handshake process.
That is where ESNI comes in. It keeps the SNI encrypted and a secret for any bad-faith listeners. It makes the client’s browsing experience private and secure.
Figure: SNI vs ESNI in TLS v1.3
Implementation
The major problem with this approach was that for the server to decrypt the ESNI, it needs the necessary information related to the encryption. But as the Client Hello is the very first communication that usually occurs between the client and the server, how would the client convey that information to the server?
Enter DNS, our savior.
The solution that was agreed upon was that the server would add its public key to its DNS (Domain Name System) TXT record which can be summoned by the client through a query with the website’s name and ‘_esni.’ as a prefix. The response from the nameservers would then hold the necessary information to encrypt the SNI in such a way that the server would be able to decrypt it.
Figure: DNS Communication for ESNI
Upon deciphering the ESNIKeys response in accordance with the second draft of the ESNI spec, we can find the following information:
Figure: ’ ESNIKeys’ Response
Which is then used to encrypt the SNI. Here is what the ESNI field looks like on Wireshark when it’s sent within the TLS Client Hello packets as an extension:
Figure: ESNI in TLS Client Hello\
Another interesting fact that was observed was that all of the ESNI supporting TXT records had the same key exchange (x25519) and the same cipher suite (TLS_AES_128_GCM_SHA256).
The mechanism is somewhat like Amazon securing its package with a lock and storing the key in a public gallery with a label of the package's content, from where the customer finds the key and opens their package after delivery.
This also sounds like an invasion of privacy and a very efficient way for Amazon to lose its customers. What if a bad-faith onlooker stalks the customer and sees the package's label as well? That is why in order to have a completely secure ESNI implementation, we need to have the DNS queries secured using DNS over TLS (DoT) or DNS over HTTPS (DoH).
This ensures that the client’s query to the DNS record is not plain text as well, and the 'public gallery' gets a curtain in the name of privacy.
Acceptance from the Internet
In order to see how many of the popular websites supported ESNI as a feature, we surveyed the Top 1000 websites that Alexa has ranked.
A website is said to support the feature when these two conditions are met –
a. It supports TLS version 1.3
b. It has a TXT record in DNS Nameserver with the necessary encryption information.
Out of the 1000 websites, 403 supported TLS v1.3. Among those 403, only 92 supported ESNI.
Just to be on the safe side with our results, we also queried for the HTTPS Resource Records for the Alexa Top 1000 Websites. No mention of ESNI Keys (or ECH) was found in any of the responses, yet.
On the client-side, among popular web browsers, only Firefox seemed to have implemented the capabilities to be compatible with ESNI, in accordance with the second draft. They only introduced it as a hidden experimental feature a few years ago that has since been deprecated in their latest releases.
However, the lack of confidence within ESNI from security researchers and content delivery networks alike, despite it being a necessary step forward in terms of privacy, could be attributed to the introduction of ECH i.e. Encrypted Client Hello.
ECH: The Next Big Thing in Privacy?
In a nutshell, as the name suggests, ECH attempts to encrypt the entire Client Hello in the TLS 1.3 Handshake, and not just the SNI. It safeguards the TLS parameters and prevents the possibility of handshake metadata like ALPN Extension and Key Share falling into the wrong hands. ECH had been proposed by the very same researchers behind the ESNI draft as a natural evolution of the ESNI standard.
The method of public key distribution has also been changed in ECH. As of the latest specification it no longer takes the help of TXT records, but HTTPS Resource Records within DNS. It also seeks to handle the failure scenario of handshake with ECH by retrying the connection, and not aborting the connection attempt at once as ESNI does.
It is evident that ECH is an attempt to significantly improve upon its predecessor i.e. the ESNI and not just a rebranding with a few extra features. This is more apparent by Firefox already going ahead with adding ECH as a hidden feature in its browser configurations in their recent releases.
Could ECH be the path to overcome the shortcoming of Handshake Encryption within TLS 1.3, while getting widespread acceptance from CDNs and Web Browsers as well?
Watch this space, because whenever that happens, we will be here with another blog!
On top of this analysis, BreakingPoint also supports this workflow by soon supporting either ESNI or ECH in a coming release, as it currently already supports the associated DoH and DoT.