The History of Encrypted Server Name Indication (SNI)
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.
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.