Cloudflare Encrypts SNI Across Its Network

Cloudflare this week announced it has turned on Encrypted SNI (ESNI) across all of its network, making yet another step toward improving user privacy.

The Transport Layer Security (TLS) Server Name Indication (SNI) extension was introduced to resolve the issue of accessing encrypted websites hosted at the same IP address. Before that, when a request was made for a HTTPS connection, the web server would only hand a single SSL certificate per IP address.

With SNI, however, if a web server hosts multiple domains, the request is routed to the correct site and the right SSL certificate is returned. This ensures that content is encrypted correctly and browsers widely adopted the TLS extension after its specification was introduced by the IETF in 2003.

The issue with SNI, however, is that it leaks the identity of the sites that the user visits. Thus, although the connection to the website is encrypted via HTTPS and the contents sent to and from the site are kept secure, information about the accessed websites isn’t.

“Today, as HTTPS covers nearly 80% of all web traffic, the fact that SNI leaks every site you go to online to your ISP and anyone else listening on the line has become a glaring privacy hole. Knowing what sites you visit can build a very accurate picture of who you are, creating both privacy and security risks,” Cloudflare’s Matthew Prince points out.

SNI requires clients to specify which site they want to connect to during the initial TLS handshake, but, as the client and server don’t share an encryption key yet, the ClientHello message is sent unencrypted.

This, however, changes with ESNI, which encrypts the SNI even if the rest of the ClientHello message remains in plaintext.

ESNI works by fetching a public key the server publishes on a well-known DNS record and replacing the SNI extension in ClientHello with a variant encrypted using a symmetric encryption key derived using the server’s public key.

The server can derive the symmetric encryption key (given that it owns the private key), and can then terminate the connection or forward it to a backend server. Only the client and the server can derive the encryption key, meaning that the encrypted SNI cannot be decrypted and accessed by third parties, Cloudflare’s Alessandro Ghedini notes.

ESNI is an extension to TLS version 1.3 and above, meaning that it doesn’t work with previous versions of the protocol. TLS 1.3 moves the Certificate message sent by the server to the encrypted portion of the TLS handshake (it was sent in plaintext before), thus preventing the attacker to determine the identity of the server through observing the plaintext certificates.

The client’s ESNI extension also includes the client’s public key share, the cipher suite it used for encryption, and the digest of the server’s ESNI DNS record, while the server generates a decryption key using its own private key share and the public portion of the client’s share. This ensures the encryption key is cryptographically tied to the TLS session it was generated for and cannot be reused.

To avoid exposing all ESNI symmetric keys generated from a server if the server’s private key is compromised, Cloudflare’s own SNI encryption implementation rotates the server’s keys every hour, yet also keeps track of the keys for the previous few hours to allow for DNS caching and replication delays.

Further privacy protections are ensured through features such as DNS over TLS (DoT) and DNS over HTTPS (DoH), which are provided through public DNS resolvers such as Cloudflare’s 1.1.1.1. One can, however, determine the visited websites by looking at the destination IP addresses on the traffic originating from users’ devices.

With Encrypted SNI now enabled across Cloudflare’s network, all of the company’s customers can take advantage of it, for free. It still requires browsers to adopt it, and Mozilla is expected to release the first supporting Firefox Nightly this week. The ESNI spec is still under development, so it’s not stable just yet.

“Encrypted SNI, along with TLS 1.3, DNSSEC and DoT/DoH, plugs one of the few remaining holes that enable surveillance and censorship on the Internet. More work is still required to get to a surveillance-free Internet, but we are (slowly) getting there,” Ghedini concludes.