The History of Encrypted Server Name Indication (SNI) to ESNI to ECH
Server Name Indication (SNI) is a feature in the Transport Layer Security (TLS) protocol that enables a client to send the hostname of the website it wants to connect to before starting the SSL/TLS negotiation. This information is used by the server to determine which certificate to present to the client, allowing multiple websites to share the same IP address and still maintain secure, encrypted connections.
However, before the advent of encrypted SNI, this information was sent in plain text, making it vulnerable to snooping and tampering. In this article, we’ll take a look at the history of encrypted SNI and how it has helped to enhance the security of the internet.
SNI History
The use of SNI dates back to 2003, when it was first introduced as an extension to the SSL protocol. At the time, SNI was used primarily to allow multiple websites to share the same IP address and still maintain secure connections. However, because the SNI information was sent in plain text, it was vulnerable to snooping and tampering, which could allow attackers to intercept and modify the SNI information.
Developing ESNI
In response to these security concerns, work began on developing encrypted SNI (ESNI), which would encrypt the SNI information and prevent it from being intercepted or modified. The first draft of the ESNI specification was published in 2018, and it quickly gained widespread support from industry leaders, including Google and Cloudflare.
Encrypted SNI works by encrypting the SNI information with a key that is derived from the server’s certificate and shared with the client. This encryption ensures that the SNI information remains confidential and can only be decrypted by the server that holds the corresponding private key. As a result, encrypted SNI provides a higher level of security compared to traditional, plain text SNI.
From ESNI to ECH
In March 2020, ESNI was reworked into the TLS v1.3 Encrypted Client Hello (ECH) extension, after analysis demonstrated that encrypting only the SNI is insufficient.
For example, specifications permit the Pre-Shared Key extension to contain any data to facilitate session resumption, even transmission of a cleartext copy of exactly the same server name that is encrypted by ESNI. Also, encrypting extensions one-by-one would require an encrypted variant of every extension, each with potential privacy implications, and even that exposes the set of extensions advertised. Lastly, real-world deployment of ESNI has exposed interoperability limitations. The short name was ECHO in March 2020 and changed to ECH in May 2020.
Encrypted Client Hello (ECH) is a TLS 1.3 protocol extension that enables encryption of the whole Client Hello message, which is sent during the early stage of TLS 1.3 negotiation. ECH encrypts the payload with a public key that the relying party (a web browser) needs to know in advance, which means ECH is most effective with large CDNs known to browser vendors in advance.
Both ESNI and ECH are compatible only with TLS 1.3 because they rely on KeyShareEntry which was first defined in TLS 1.3. Also, to use ECH, the client must not propose TLS versions below 1.3.
By encrypting the SNI information, encrypted SNI or ECH helps to prevent attackers from intercepting and modifying the SNI information, making it more difficult for them to carry out man-in-the-middle attacks.
DNS ECH Technical Details
DNS ECH (Encrypted Client Hello) is a mechanism used to encrypt the initial client hello message in the DNS over HTTPS (DoH) protocol. It provides additional privacy and security for users by preventing eavesdroppers from intercepting and reading the client hello message.
When a client initiates a DoH connection, it sends a client hello message to the DoH server. The client hello message contains information about the client’s supported cryptographic algorithms, cipher suites, and other parameters that are used to negotiate a secure connection with the server.
With DNS ECH, the client hello message is encrypted using a public key provided by the server. This ensures that only the DoH server can decrypt and read the message, preventing eavesdroppers from intercepting and reading the message.
The encryption process involves the following steps:
- The client generates a random key, called the “client hello encryption key.”
- The client uses the client hello encryption key to encrypt the client hello message.
- The client sends the encrypted client hello message and the public key provided by the server to the DoH server.
- The DoH server uses its private key to decrypt the encrypted client hello message and read its contents.
DNS ECH is implemented as an extension to the TLS (Transport Layer Security) protocol. It provides additional privacy and security for DoH connections, especially in situations where the client’s network traffic may be intercepted by malicious actors. However, it requires additional processing and resources on both the client and server sides, which may impact performance.
Summary
In conclusion, the history of encrypted SNI / ECH is a testament to the ongoing efforts to enhance the security of the internet. By encrypting the SNI information, encrypted SNI provides a higher level of security compared to traditional, plain text SNI, helping to prevent attackers from intercepting and modifying the SNI information. With its widespread support and critical importance to the security of the internet, encrypted SNI is poised to play a significant role in the future of online security.