# Encrypted Client Hello Is Coming: A View from Passive Measurements
## 2 Background and Related Work  
The Encrypted Client Hello (ECH) extension [8] enhances privacy in TLS by encrypting the entire Client Hello message, including sensitive fields such as the Server Name Indication (SNI), which would otherwise be visible in plaintext during the handshake. To achieve this, the client constructs two Client Hello messages--an outer Client Hello and an inner Client Hello. The outer Client Hello acts as a syntactically valid decoy that can be processed by servers that do not support ECH. It also includes a placeholder, in-clear SNI, called \"ECH Public Name\". The inner Client Hello contains the actual parameters of the TLS connection, including the real server name and any sensitive extensions. This inner Client Hello is then encrypted using the Hybrid Public Key Encryption (HPKE) scheme and embedded within the outer Client Hello as the payload of the encrypted_client_hello extension. In addition to real ECH usage, clients may also send GREASE ECH values to help prevent protocol ossification. GREASE (Generate Random Extensions And Sustain Extensibility) was originally introduced in TLS to ensure that middleboxes and servers do not incorrectly assume that certain protocol features will always be absent or follow a fixed structure. In the context of ECH, a GREASE ECH is a syntactically valid but semantically meaningless ECH extension, typically containing a random encrypted payload. These are deliberately constructed so that they cannot be decrypted by any server, and they serve no functional purpose in the handshake. Instead, their role is to keep the network ecosystem flexible by normalizing the presence of ECH extensions in Client Hello messages, even in cases where true ECH is not used. This reduces the risk of network interference or broken connections when ECH is eventually deployed at scale. The server's ECH public key and configuration parameters are advertised through a DNS HTTPS resource record associated with the target domain. The HTTPS DNS resource record (RR), defined in RFC 9460 [9], is a new type of DNS record designed to allow clients to discover configuration details about a service endpoint, including those needed for Encrypted Client Hello (ECH). Unlike traditional A or AAAA records that simply map domain names to IP addresses, the HTTPS RR can carry metadata in the form of service parameters. These parameters can specify endpoint addresses (IPv4 or IPv6), supported protocols (e.g., QUIC), port numbers, and the ECH configuration. The ECH configuration includes the public key, cipher suites, and other encryption parameters necessary for clients to encrypt the inner Client Hello. This information is embedded as a base64-encoded blob within the HTTPS record. When a client wishes to initiate a TLS connection using ECH, it first performs a DNS resolution for the HTTPS RR of the target domain. If the record is available and contains valid ECH configuration data, the client can construct the inner Encrypted Client Hello using HPKE. When a server that supports ECH receives a Client Hello with the ECH extension, it attempts to decrypt the inner Client Hello using its private HPKE key. If decryption is successful, it proceeds with the handshake using the decrypted values. If decryption fails, the server falls back to processing the outer Client Hello to ensure backward compatibility. Adopting ECH and HTTPS DNS records requires significant infrastructural changes on the part of content providers, as well as updates to client implementations. The research community has thus begun to explore this transition. A number of articles tackled the impact of ECH on traffic classification [10; 11; 12], showing that machine learning models can, under some circumstances and provided an adequate training set, nullify the privacy benefits of ECH. [PERSON] et al. [13] analyze the cryptographic correctness of the ECH proposal, while [PERSON] et al. [14] study the relationship between ECH and state-level censorship systems. The first study regarding ECH adoption was carried out by [PERSON] et al.