# Encrypted Client Hello Is Coming: A View from Passive Measurements
## 1 Introduction  
Passive monitoring refers to the process of observing and analyzing traffic within operational networks. While it has proven useful for applications such as traffic engineering, cybersecurity, and behavioral analysis, it also involves processing personal data. In particular, client IP addresses can often be linked to individuals, and the content of their network traffic may reveal sensitive information, such as visited websites, which can, in turn, expose user habits and characteristics. As such, passive monitoring poses significant privacy concerns for end users [1]. Over the past two decades, various efforts have aimed to enhance network privacy through encryption. These include the widespread adoption of Transport Layer Security (TLS) and Hypertext Transfer Protocol Secure (HTTPS) [2], as well as the more recent deployment of the QUIC protocol [3], which encrypts nearly all transport layer fields. However, these technologies do not fully protect user privacy. Although they encrypt application-layer payloads, domain names remain exposed in Domain Name System (DNS) queries and the Server Name Indication (SNI) field of the TLS Client Hello message. To mitigate this issue, recent standards have introduced encrypted versions of DNS, namely DNS over TLS (DoT) [4] and DNS over HTTPS (DoH) [5], the latter of which is increasingly supported by major web browsers. Despite these advancements, encrypted DNSonly partially addresses the problem. However, in many networks, users are still forced to use local DNS resolvers, and DoH/DoT traffic can often be detected and blocked [6; 7]. Moreover, even with encrypted DNS, domain names continue to be visible in the SNI field. To fully hide domain names from passive eavesdroppers, it is necessary to also encrypt the SNI field, which presents significant technical challenges. The SNI is essential for servers hosting multiple virtual hosts, as it allows them to select the correct TLS certificate. Simply removing the SNI is, therefore, not feasible. The recent Encrypted Client Hello (ECH) draft [8] addresses this issue by proposing encryption of the SNI and other TLS handshake fields using a public key retrieved via DNS. The current ECH draft is an evolution of the earlier Encrypted SNI (ESNI) proposal, with the key difference being that ECH can encrypt any Client Hello field (or even the entire message), while ESNI only encrypted the Server Name Indication (SNI) within it. Specifically, the client queries a new type of DNS record called \"HTTPS\", which contains the server's public key and other connection metadata [9]. The server uses the corresponding private key to decrypt the ECH. These HTTPS records are designed to eventually replace traditional A and AAAA records, as they can also contain server IP addresses and application-layer protocol information (superseding ALPN negotiation). In this paper, we present the first study of ECH and HTTPS DNS adoption from a passive monitoring perspective. Using traffic traces collected over one month from a campus network, we analyze DNS and QUIC traffic to evaluate the real-world deployment and use of these protocols. Our findings reveal that HTTPS DNS queries already account for approximately 8% of all DNS traffic. However, the responses often lack fundamental information, such as server IP addresses, forcing clients to issue additional A and AAAA queries. As a result, overall DNS traffic increases. We also observe that ECH is already used in a substantial share of connections, that is, 59% of QUIC flows include an ECH extension. Notably, clients often send ECH even when the destination server does not support it. Only a small subset of servers--all uniquely hosted on Cloudflare--actually support ECH. Among connections to these servers, 1.96% include a valid ECH. In the other cases, clients send an ECH containing random values called GREASE (Generating Random Extensions and Sustain Extensibility), which carries no meaningful data and has the sole purpose of preventing protocol ossification.