Encrypted Client Hello: Closing the SNI Metadata Gap
The internet is getting more private, whether governments like it or not.
Encrypted Client Hello (ECH) is nearing final IETF standardization [1]. It closes the last remaining metadata leak in HTTPS connections by encrypting the Server Name Indication (SNI) field. When you visit cdt.org, that hostname has been visible in plaintext to network observers since SNI was introduced in 2003 [2]. Thanks to the new ECH standard, that will no longer be true. This represents a milestone in the multi-decade effort to eliminate online metadata leakage.
To understand why this matters, let’s rewind to February 2019, when South Korean internet users learned this lesson the hard way. Working with local Internet Service Providers, the Korea Communications Standards Commission (KCSC) quietly rolled out a new censorship technique: instead of the traditional DNS (Domain Name System) blocking that savvy users could bypass, they began inspecting the SNI field in HTTPS (encrypted web) handshakes and dropping connections to deny-listed domains [3].
Results were immediate and unsettling. Eight hundred ninety-five foreign websites (mostly gambling and adult content) suddenly became unreachable. No block pages, no government warnings, just clean connection failures that left users staring at generic “This site can’t be reached” browser errors.
The public response was swift and angry. A petition on the Blue House website opposing the new censorship technique garnered more than 140,000 signatures in just two days, with the petitioner arguing, “This could be the beginning of censorship.”[4] Users understood the implications: their government could now monitor which HTTPS sites they visited, even when the content remained encrypted. The technique was elegant in its simplicity and devastating in its effectiveness. Even though the web had become overwhelmingly encrypted, this one plaintext breadcrumb, SNI, was enough to give network operators surgical precision over what people could access online.
Background: Where Metadata Leaks
Despite the fact that HTTPS now protects over 90% of web traffic [5], certain metadata about your browsing remains visible to anyone observing network traffic. While the content of your web pages stays encrypted, information about which sites you’re visiting can still leak out. Understanding these metadata leaks explains why SNI inspection became such an effective censorship tool.
These leaks exist at different layers of the network stack. Even when website content is fully encrypted, various clues about your destination remain exposed to observers on the network path.
Here’s what’s visible at each layer:
Connection Step
What Network Observers Could See
What They See With With Privacy Features Enabled
DNS lookup
DNS equivalent of “What’s the IP for cdt.org?” sent without encryption
DNS over HTTPS (2018) encrypts the question
Network routing
Destination IP address
IP still visible (but many sites share the same IP)
Security certificate
Website’s SSL certificate sent in plaintext
Certificate encrypted during connection setup by TLS 1.3 (2018)
Initial handshake containing SNI
“I want to visit cdt.org” sent in plaintext
ECH will hide the hostname
Each layer tells a different story about how the technical community has systematically closed privacy gaps. DNS queries revealed which domains you wanted to visit, so they were encrypted with DNS over HTTPS starting in 2018 [6]. Although IP addresses remain visible, they often reveal little when sites use shared hosting or CDNs. There are only a finite number of IP addresses, so hosting providers must share them among many websites. TLS 1.3 (2018) encrypted security certificates that previously leaked hostname information. Even with this progress, SNI remained stubbornly exposed. RFC 9505 [7], a recent survey of worldwide censorship techniques supported by CDT, identified SNI as a significant remaining design issue for a censorship-resistant web.
Why SNI Became the Last Privacy Gap
SNI exists for a practical reason: web servers need to know which SSL certificate to present when multiple websites share the same IP address. The client tells the server which hostname it’s trying to reach before the encrypted session begins. This was a necessary compromise when SNI was introduced in 2003, but it created a privacy gap that would later be exploited.
This metadata leak became particularly valuable to censors as HTTPS adoption soared and richer plaintext sources disappeared. As the IETF’s ECH specification notes:
“Although TLS 1.3 encrypts most of the handshake, there are several channels that allow a network observer to determine the domain name the client is trying to connect to, including unencrypted client DNS queries, visible server IP addresses, and unencrypted SNI in ClientHello messages” [1].
SNI was the last reliable signal for hostname identification. That signal should now be disappearing thanks to ECH.
Think of ECH as sending a letter in two envelopes: the outer envelope shows a generic destination, while the actual address remains hidden inside. Your browser creates two messages: an outer message containing a generic hostname that reveals nothing about your destination (except for which company is hosting it), and an inner message containing your specific destination, encrypted using the server’s public key.
Network observers see only the outer message. They know the web server to which you’re connecting, but not the specific site. The web server decrypts the inner message and routes your connection correctly. This eliminates the SNI inspection shortcut that network operators have relied on for content filtering.
Adapting Network Security Systems
If content filtering is the goal, network operators can still determine which connections are made to which sites with ECH. They’ll just need to do it explicitly. SNI inspection was a shortcut that allowed network intermediaries to filter content without decrypting it. The implications are significant for everyone involved in internet traffic monitoring.
Without SNI, the type of interference introduced in South Korea in 2019 would no longer be effective. And it isn’t just government actions that are affected. Your ISP, corporate IT departments, hotel WiFi operators, and any other network operator lose their easiest window into which sites you visit. If they want to filter content now, they’ll need to insert their filter where the content is actually decrypted, such as in browsers, operating systems, or web servers, rather than on the network.
ECH forces a more principled approach to network security and content policy. Content filtering and access controls implemented at the endpoint (either the browser or the web server) often provide better security than SNI-based filtering, since they operate at the application layer, where content can be appropriately analyzed.
Trial by Firewall
The networking community has long recognized the SNI problem and has been working on a solution for years. By 2018, engineers at Cloudflare, Mozilla, and others were already working on Encrypted SNI (ESNI). The concept was elegant: encrypt just the SNI field while leaving the rest of the TLS handshake unchanged.
ESNI seemed like the correct surgical fix. Cloudflare deployed it experimentally in 2018, and Mozilla began testing it in Firefox [8]. The SNI problem appeared solved. Then the censors fought back.
China was the first to react. By 2020, the Great Firewall began dropping any TLS connection that included the ESNI extension [9]. The approach was simple: block any connection that tried to encrypt SNI. No negotiation, no fallback. Just a connection reset and a failed handshake. The message was clear: some governments would rather block large chunks of the internet than allow encrypted SNI traffic.
The real problem with ESNI was that it stuck out like a sore thumb. ESNI created a detection problem: connections either had the ESNI extension or they didn’t, making privacy-enhanced traffic easy to identify and block.
This “sticking out” issue drove the evolution from ESNI to ECH in 2020. ECH needed to be undetectable, so it borrowed a clever approach from TLS 1.3. When TLS 1.3 was developed, it included dummy messages to disguise itself as older TLS 1.2 traffic (like wearing a suit to blend in at a formal event) [10]. ECH does something similar: all connections send ECH-like extensions, whether they’re using privacy features or not. This way, censors can’t tell which connections are privacy-enhanced.
Current Deployment and Adoption
ECH adoption is already substantial. When Cloudflare enabled ECH by default for all customers in late 2023, ECH became available across millions of websites automatically [12]. Browser adoption followed a similar path: Firefox and Chrome both added ECH support in October 2023 [13][14]. Apple’s Safari remains on the sidelines, with ECH support still in development [15].
For users, the change is largely invisible. Privacy protection shouldn’t require technical expertise or special software. ECH works automatically when both your browser and the website support it, requiring no configuration or user action. You browse normally, but network observers see only generic web server connections instead of specific site destinations.
The IETF has accepted the ECH protocol for publication, which means the Internet community has agreed to standardize it. But it won’t be fully adopted until more websites start using it. ECH deployment varies considerably by provider and region. While comprehensive statistics remain limited, the trend indicates that major content delivery networks are leading the adoption, while traditional hosting providers have been slower to implement ECH support.
Privacy technologies and censorship techniques will continue to evolve. ECH represents just the latest milestone in building privacy into internet protocols by default.
British Public Oppose Secret Surveillance Powers and Want Strong Protections for Encrypted Communications
CDT released nationally representative polling data revealing that a the British public are broadly concerned about the security, privacy, and free speech consequences of allowing law enforcement to access encrypted communications.
Changing Course to Get It Right: The Advisory Committee Reviews Its AI Evidence Rule
CDT is keeping a close eye on Proposed Federal Rule of Evidence 707, which would govern when AI-generated information can be admitted as evidence in federal court — and many state courts where the federal rules are routinely adopted — without a human expert to explain it.
