What Is Encrypted Server Name Indication (ESNI)? How Encrypted Client Hello (ECH) Protects Your Privacy

Server Name Indication (SNI) enables web servers to host multiple SSL Certificates on a single IP address by allowing clients to specify which hostname they want to connect to during the Transport Layer Security (TLS) handshake. However, this essential mechanism has a significant privacy limitation. The Server Name Indication (SNI) field is transmitted in plaintext before encryption is established, allowing anyone monitoring network traffic to see exactly which websites a user is visiting.

Encrypted Server Name Indication (ESNI) was developed to address this privacy gap by encrypting the Server Name Indication (SNI) portion of the Transport Layer Security (TLS) handshake. This technology has since evolved into Encrypted Client Hello (ECH), which provides even stronger privacy protection by encrypting the entire initial handshake message rather than just the hostname field.

Understanding how Encrypted Server Name Indication (ESNI) and Encrypted Client Hello (ECH) work helps website administrators and security professionals appreciate the privacy improvements in modern Transport Layer Security (TLS) implementations.

This article explains the privacy problem with traditional Server Name Indication (SNI), how encryption solutions address it, and what these changes mean for SSL Certificate deployment.

The Privacy Problem with Server Name Indication (SNI)

Server Name Indication (SNI) was standardized in 2003 through RFC 3546 as an extension to the Transport Layer Security (TLS) protocol. Before Server Name Indication (SNI) existed, each SSL Certificate required a dedicated IP address because the server had no way to know which SSL Certificate to present until after the encrypted connection was established.

Why Server Name Indication (SNI) Exists

When a client connects to a server using Transport Layer Security (TLS), the server must present an SSL Certificate before the encrypted session begins. Without Server Name Indication (SNI), the server cannot determine which SSL Certificate to present when multiple websites share the same IP address.

Server Name Indication (SNI) solves this problem by having the client include the desired hostname in its initial connection message. The server reads this hostname and responds with the appropriate SSL Certificate for that specific website. This allows hosting providers to serve multiple secure websites from a single IP address, dramatically reducing the number of IP addresses required for web hosting.

The Plaintext Exposure Problem

The fundamental issue with Server Name Indication (SNI) is timing. The client must tell the server which hostname it wants before encryption begins, but encryption cannot begin until the server presents the correct SSL Certificate. This creates an unavoidable chicken-and-egg problem where the hostname must be sent in plaintext.

Any observer monitoring network traffic between a client and server can read the Server Name Indication (SNI) field and determine exactly which website the user is accessing. Internet Service Providers (ISPs), corporate network administrators, government agencies, and attackers on shared networks can all see this information.

Even though Transport Layer Security (TLS) 1.3 encrypts most of the handshake including the server's SSL Certificate, the Server Name Indication (SNI) remains visible. This metadata leak allows observers to track browsing activity even when they cannot see the actual content of communications.

Real-World Exploitation of Server Name Indication (SNI)

The plaintext Server Name Indication (SNI) field has been actively exploited for surveillance and censorship. In February 2019, South Korea implemented a new censorship technique that inspected Server Name Indication (SNI) fields in Transport Layer Security (TLS) handshakes and dropped connections to blocked domains. This approach was more difficult to circumvent than traditional Domain Name System (DNS) blocking.

Similar techniques have been deployed by other governments to monitor citizen browsing activity and enforce content restrictions. The visibility of Server Name Indication (SNI) provides a reliable method for identifying which websites users visit, even when all other aspects of the connection are encrypted.

How Encrypted Server Name Indication (ESNI) Works

Encrypted Server Name Indication (ESNI) was developed to close the privacy gap by encrypting the hostname before sending it to the server. The key innovation is using Domain Name System (DNS) records to distribute encryption keys that clients can use to protect the Server Name Indication (SNI) field.

The Key Distribution Challenge

Encrypting the Server Name Indication (SNI) requires solving a fundamental problem. The client needs an encryption key before contacting the server, but traditionally the only way to get cryptographic keys from a server is through the Transport Layer Security (TLS) handshake itself.

Encrypted Server Name Indication (ESNI) solves this by publishing the server's public encryption key in Domain Name System (DNS) records. When a client wants to connect to a website, it first retrieves the Encrypted Server Name Indication (ESNI) public key from Domain Name System (DNS). The client then uses this key to encrypt the Server Name Indication (SNI) field before sending its connection request.

The server decrypts the Server Name Indication (SNI) using its corresponding private key, determines which SSL Certificate to present, and proceeds with the normal Transport Layer Security (TLS) handshake. To outside observers, the encrypted Server Name Indication (SNI) appears as opaque data that reveals nothing about which website the user is accessing.

The Requirement for Encrypted Domain Name System (DNS)

Encrypted Server Name Indication (ESNI) only provides privacy if the Domain Name System (DNS) queries that retrieve the encryption keys are also protected. If an observer can see the Domain Name System (DNS) request for a website's Encrypted Server Name Indication (ESNI) key, they already know which website the user intends to visit.

For complete privacy protection, Encrypted Server Name Indication (ESNI) must be combined with encrypted Domain Name System (DNS) protocols such as Domain Name System (DNS) over HTTPS (DoH) or Domain Name System (DNS) over Transport Layer Security (TLS) (DoT). These protocols encrypt Domain Name System (DNS) queries, preventing observers from seeing which domains the user is resolving.

When properly implemented together, encrypted Domain Name System (DNS) and Encrypted Server Name Indication (ESNI) prevent network observers from determining which websites a user visits based on either Domain Name System (DNS) queries or Transport Layer Security (TLS) handshakes.

Implementation and Deployment

Cloudflare deployed experimental Encrypted Server Name Indication (ESNI) support in 2018, and Mozilla began testing it in Firefox. The implementation required servers to publish their Encrypted Server Name Indication (ESNI) public keys as TXT records in Domain Name System (DNS) and rotate these keys periodically to maintain forward secrecy.

However, Encrypted Server Name Indication (ESNI) encountered significant obstacles. Some governments, particularly China, began blocking any Transport Layer Security (TLS) connection that included the Encrypted Server Name Indication (ESNI) extension. The presence of Encrypted Server Name Indication (ESNI) was itself detectable, making privacy-enhanced connections easy to identify and block.

The Evolution to Encrypted Client Hello (ECH)

The limitations of Encrypted Server Name Indication (ESNI) led to its evolution into Encrypted Client Hello (ECH) in 2020. Encrypted Client Hello (ECH) addresses the shortcomings of its predecessor while providing stronger privacy guarantees and better resistance to blocking.

Why Encrypted Server Name Indication (ESNI) Was Insufficient

Analysis of Encrypted Server Name Indication (ESNI) revealed that encrypting only the Server Name Indication (SNI) field was not enough. Other extensions in the Transport Layer Security (TLS) Client Hello message could also leak identifying information. For example, session resumption data could contain hostname information that would expose the same data Encrypted Server Name Indication (ESNI) was trying to protect.

Additionally, Encrypted Server Name Indication (ESNI) connections were trivially identifiable. Network observers could simply detect the presence of the Encrypted Server Name Indication (ESNI) extension and block or flag those connections. This "sticking out" problem meant that using Encrypted Server Name Indication (ESNI) could actually draw more attention to a connection rather than less.

How Encrypted Client Hello (ECH) Improves Privacy

Encrypted Client Hello (ECH) takes a more comprehensive approach by encrypting the entire Client Hello message rather than just the Server Name Indication (SNI) field. The Client Hello is split into two parts called the outer and inner messages.

The outer Client Hello contains non-sensitive information such as supported cipher suites and Transport Layer Security (TLS) version. It also includes a generic Server Name Indication (SNI) that points to a shared frontend server rather than the actual destination. As an example, for websites using Cloudflare, this outer Server Name Indication (SNI) shows cloudflare-ech.com regardless of which specific website the user is visiting.

The inner Client Hello contains the actual hostname and other privacy-sensitive extensions. This inner message is encrypted using a public key that the server advertises through Domain Name System (DNS). Only the destination server can decrypt the inner Client Hello and learn which website the user actually wants to visit.

Improved Key Distribution

Encrypted Client Hello (ECH) changes how encryption keys are distributed. Instead of using TXT records in Domain Name System (DNS), Encrypted Client Hello (ECH) uses HTTPS and SVCB resource records. These newer record types were designed specifically for service discovery and provide a more robust mechanism for distributing cryptographic parameters.

Encrypted Client Hello (ECH) also includes a retry mechanism that Encrypted Server Name Indication (ESNI) lacked. If a client uses outdated encryption keys due to Domain Name System (DNS) caching, the server can securely provide updated keys and allow the client to retry the connection. This improves reliability when server keys rotate or when clients have stale Domain Name System (DNS) data.

Resistance to Detection and Blocking

Encrypted Client Hello (ECH) is designed to be indistinguishable from non-privacy-enhanced Transport Layer Security (TLS) connections. All connections include Encrypted Client Hello (ECH) like extensions regardless of whether they are actually using the privacy features. This approach borrows from Transport Layer Security (TLS) 1.3, which includes dummy messages to disguise itself as older Transport Layer Security (TLS) 1.2 traffic.

By making all connections look similar, Encrypted Client Hello (ECH) prevents censors from identifying and blocking privacy-enhanced traffic based on protocol features alone. Blocking Encrypted Client Hello (ECH) would require blocking access to entire Content Delivery Networks (CDNs), which would affect millions of legitimate websites.

Browser and Server Support for Encrypted Client Hello (ECH)

Encrypted Client Hello (ECH) has achieved significant adoption in major browsers and server platforms. Understanding current support helps administrators plan for deployment and users understand what protection they currently have.

Browser Implementation Status

Google Chrome version 117 and later versions enable Encrypted Client Hello (ECH) by default when connecting to servers that support it. The feature requires Domain Name System (DNS) over HTTPS (DoH) to be enabled and servers to publish their Encrypted Client Hello (ECH) keys in HTTPS resource records.

Mozilla Firefox version 118 and later versions also support Encrypted Client Hello (ECH) by default. Firefox enables Encrypted Client Hello (ECH) automatically when using encrypted Domain Name System (DNS) resolvers that support the necessary record types. Mozilla recommends using Encrypted Client Hello (ECH) together with Domain Name System (DNS) over HTTPS (DoH) for maximum privacy.

Microsoft Edge, which is based on Chromium, includes the same Encrypted Client Hello (ECH) support as Chrome. Safari has indicated support for Encrypted Client Hello (ECH) through WebKit standards positions. Current estimates suggest approximately 59 percent of browsers actively use Encrypted Client Hello (ECH) when available.

Server and Content Delivery Network (CDN) Support

Cloudflare enabled Encrypted Client Hello (ECH) support for all hosted domains in September 2023. Because Cloudflare serves a significant portion of internet traffic, this single deployment made Encrypted Client Hello (ECH) available for millions of websites simultaneously.

For Encrypted Client Hello (ECH) to work, the server infrastructure must publish the necessary Domain Name System (DNS) records and handle the encrypted Client Hello messages. Most implementations rely on Content Delivery Networks (CDNs) that have deployed Encrypted Client Hello (ECH) support rather than requiring individual website operators to configure it themselves.

Web servers such as NGINX and Apache do not yet have native Encrypted Client Hello (ECH) support, though feature requests and development efforts are ongoing. Organizations requiring Encrypted Client Hello (ECH) typically use Content Delivery Network (CDN) services that provide this functionality.

Impact on SSL Certificate Operations

Encrypted Client Hello (ECH) changes how Transport Layer Security (TLS) handshakes reveal SSL Certificate information, but it does not change the fundamental requirements for SSL Certificate deployment. Website operators still need properly configured SSL Certificates from trusted Certificate Authorities (CAs).

SSL Certificate Selection with Encrypted Client Hello (ECH)

Under traditional Server Name Indication (SNI), observers could see which SSL Certificate the server would present based on the plaintext hostname. With Encrypted Client Hello (ECH), this selection happens after decryption of the inner Client Hello, so observers cannot determine which SSL Certificate corresponds to the connection.

The SSL Certificate itself is still transmitted during the handshake, but Transport Layer Security (TLS) 1.3 already encrypts this portion. Combined with Encrypted Client Hello (ECH), the entire process of SSL Certificate selection and presentation is hidden from network observers.

Website operators should ensure their SSL Certificates properly cover all hostnames that users might request. Encrypted Client Hello (ECH) does not change SSL Certificate validation requirements or the need for properly configured SSL Certificate chains.

Multi-Domain and Wildcard SSL Certificate Considerations

Encrypted Client Hello (ECH) works with all SSL Certificate types including single-domain, Multi-Domain, and Wildcard SSL Certificates. The privacy protection applies regardless of how many domains a single SSL Certificate covers.

Organizations using Multi-Domain SSL Certificates may find Encrypted Client Hello (ECH) particularly valuable because it prevents observers from determining which specific domain within the SSL Certificate the user is accessing. A Multi-Domain SSL Certificate covering dozens of different websites reveals nothing about which specific site is being visited when Encrypted Client Hello (ECH) is active.

Wildcard SSL Certificates similarly benefit from Encrypted Client Hello (ECH) protection. Without Encrypted Client Hello (ECH), observers could see the specific subdomain being accessed. With Encrypted Client Hello (ECH), only the encrypted inner Client Hello contains this information. Explore Our Wildcard SSL Certificate Options 🔗

Validation Levels and Encrypted Client Hello (ECH)

Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV) SSL Certificates all work with Encrypted Client Hello (ECH). The validation level affects what information appears in the SSL Certificate itself but does not change how Encrypted Client Hello (ECH) protects the handshake process.

The privacy improvements from Encrypted Client Hello (ECH) apply equally regardless of SSL Certificate validation level. Organizations that choose Organization Validation (OV) or Extended Validation (EV) SSL Certificates for trust reasons still benefit from the same handshake privacy as those using Domain Validation (DV) SSL Certificates.

Network Security Implications

Encrypted Client Hello (ECH) has significant implications for network security monitoring and policy enforcement. Organizations that rely on inspecting Server Name Indication (SNI) for security controls must understand how Encrypted Client Hello (ECH) affects their capabilities.

Impact on Network Monitoring

Many corporate firewalls and security appliances inspect the Server Name Indication (SNI) field to enforce access policies, categorize traffic, and detect threats. Encrypted Client Hello (ECH) prevents these systems from seeing which specific website a user is accessing when connecting to Encrypted Client Hello (ECH) enabled servers.

Security teams can still see that a connection is being made to an endpoint, but they cannot determine the specific destination website. This represents a significant change for organizations that rely on Server Name Indication (SNI) inspection for security policy enforcement.

Managed enterprise devices can have Encrypted Client Hello (ECH) disabled through browser policies. This allows organizations to maintain visibility into employee browsing activity on corporate-owned devices while preserving privacy for personal devices and general internet users.

Adapting Security Controls

Organizations affected by Encrypted Client Hello (ECH) are adapting their security strategies. Endpoint-based security products that operate on the device itself maintain full visibility regardless of Encrypted Client Hello (ECH) status. These solutions can inspect connections before encryption occurs.

Content filtering and access controls implemented at the application layer remain effective because they operate after Encrypted Client Hello (ECH) decryption completes. Organizations are shifting toward endpoint and application-layer security controls rather than relying solely on network-based Server Name Indication (SNI) inspection.

The Future of Transport Layer Security (TLS) Privacy

Encrypted Client Hello (ECH) represents a major milestone in the ongoing effort to eliminate metadata leakage from internet communications. Its standardization and deployment mark the closure of the last significant privacy gap in HTTPS connections.

Standardization Progress

Encrypted Client Hello (ECH) is nearing final Internet Engineering Task Force (IETF) standardization. As of late 2025, the specification has reached draft version 25 and is expected to receive final approval as a formal Request for Comments (RFC) standard. This standardization provides stability for implementers and ensures interoperability across different browsers and servers.

The progression from Encrypted Server Name Indication (ESNI) to Encrypted Client Hello (ECH) demonstrates how protocol designers learn from real-world deployment and adversarial responses. The lessons learned from Encrypted Server Name Indication (ESNI) blocking informed the design of Encrypted Client Hello (ECH) to be more resilient against detection and censorship.

Remaining Privacy Considerations

Encrypted Client Hello (ECH) does not provide complete anonymity. IP addresses still reveal some information about which servers a user is communicating with. Traffic analysis based on timing, volume, and patterns can also provide clues about user activity.

Certificate Transparency logs publicly record all issued SSL Certificates, so subdomain information remains discoverable through these logs even when protected during individual connections. Organizations requiring stronger anonymity should consider additional privacy measures beyond Encrypted Client Hello (ECH).

Conclusion

Server Name Indication (SNI) enabled the modern web by allowing multiple SSL Certificates to share IP addresses, but it created a privacy gap that exposed which websites users visit. Encrypted Server Name Indication (ESNI) addressed this by encrypting the hostname field, and Encrypted Client Hello (ECH) evolved this further to encrypt the entire initial handshake message.

Major browsers including Chrome, Firefox, and Edge now support Encrypted Client Hello (ECH) by default. Content Delivery Networks (CDNs) like Cloudflare have deployed server-side support, making Encrypted Client Hello (ECH) available for millions of websites. The combination of Encrypted Client Hello (ECH) with encrypted Domain Name System (DNS) protocols provides comprehensive privacy protection for web browsing.

SSL Certificate deployment and validation requirements remain unchanged with Encrypted Client Hello (ECH). Trustico® provides SSL Certificates that work seamlessly with Encrypted Client Hello (ECH) enabled servers.

Proper SSL Certificate configuration remains essential for secure communications regardless of the privacy enhancements that Encrypted Client Hello (ECH) provides at the protocol level. Discover Our Complete SSL Certificate Solutions 🔗