Keywords

1 Introduction

The evolution of the Internet gave rise to a copious amount of online services. However, although no technology has proven to be the silver bullet against the emerging cyber-security threats in these services, there is a continuous effort in alleviating the issues that come to surface. In this direction, one of the first solutions to combat security weaknesses was Secure Socket Layer (SSL), which was introduced by Netscape in 1994. In the last two decades, SSL has been transformed through various upgrades, changing name and reaching the form we know today as TLS [1].

The main security properties provided by TLS are confidentiality, data integrity, and authentication in a typical client-server architecture. TLS aims to prevent eavesdroppers from inherent weaknesses in communication channels, such as Man-in-the-middle (MitM) attacks [2]. Based on the ISO reference model, it is a session layer protocol that is composed of two layers: the TLS handshake, which is used for agreeing several parameters needed for the connection establishment, and the TLS record, which is used for the actual exchange of data.

One of the TLS handshake extensions, which was introduced back in 2003, is the SNI [3]. This feature allows a client to communicate the actual domain that is being requested to a web server that hosts multiple virtual servers behind the same IP address. The procedure is as follows: the client communicates the SNI in the first TLS handshake message, known as the ClientHello, and this piece of data is used by the host server for forwarding the certificate of the specific virtual server that is indicated in the SNI. Unfortunately, this functionality results in a privacy leak, as the SNI is conveyed in plain text and can be easily sniffed by a malicious entity that snoops the communication channel.

Overall, in a TLS-protected communication there are three different channels that can leak private information: (Case 1) sniffing cleartext Domain Name System (DNS) queries, (Case 2) observing domains that are being visited, and (Case 3) sniffing the cleartext SNI included in the ClientHello message. Figure 1 offers an overview of the possible ways that an SNI-based TLS communication can divulge private information.

Fig. 1.
figure 1

Leaking channels

Full size image

For (1), DNS over HTTPS (DoH) [4], DNS over TLS (DoT) [5], or DNS over QUIC (DoQ) [6], all together commonly referred to as “encrypted DNS”, could be used to protect end user privacy; an overview of these protocols is provided in [7]. These protocols could also be used in conjunction with Domain Name System Security Extensions (DNSSEC) [8] to avoid DNS cache poisoning attacks. Regarding (2), since the visited server is co-located with other servers behind a provider hosting multiple domains with the same IP address, it is difficult for an attacker to distinguish which domain is actually visited. In this case, the attacker sniffs only the common IP address but is not aware of the actual domain that is being visited. As a solution to (3), the encrypted version of SNI, namely ESNI [9], was introduced a few years ago. The point of this Internet draft was to secure the information leaked in the ClientHello message by SNI. However, it soon became apparent that other extensions sent in cleartext in ESNI-enabled TLS handshakes, such as the Application-Layer Protocol Negotiation (ALPN), could also expose private information. The latest version of the standard, which was renamed to ECH in 2020 [10], safeguards the whole ClientHello message and uses a diverse approach to deliver the encryption keys compared to its predecessor.

Generally, among others, the adoption of encrypted DNS and privacy-aware TLS extensions are lately in the spotlight. For instance, according to [11], China is allegedly blocking all HTTPS/ESNI traffic, but not ECH. Similar measures are reportedly planned by Russia’s Digital Development Ministry, which proposed the ban of several encryption protocols, including TLS 1.3/ESNI, DoT, DoH, and others [12]. Finally, TLS filtering and SNI-based blocking have been found to be applied in India [13, 14], while DoT is widely blocked in Iran [15].

In this context, the work at hand examines the global adoption of the ESNI and ECH extensions in the top 1M sites included in the Tranco list [16]. Furthermore, we measure the availability of DoH when requesting the public keys required by ESNI and ECH and resolving the visited top 1M domain names. Last but not least, we scrutinize how ESNI and ECH operate in detail, with respect to key retrieval, key configuration in the TLS handshake phase, and the completion of HTTPS requests.

The rest of the paper is structured as follows. The next section overviews the related work. Section 3 discusses the fundamentals around TLS, ESNI, and ECH. Section 4 presents our experimental setup and measurement results, while the last section draws our conclusions.

2 Related Work

This section summarizes the works that have been presented in the literature thus far, regarding the adoption of ESNI and ECH extensions. Nearly all of these works examine the effectiveness of the ESNI and DoH/DoT standards to achieve domain name privacy.

The work in [17] provides a measurement study on the adoption of ESNI in China. The authors focus on the use of ESNI to achieve censorship circumvention. According to their study, 10.9% of the Alexa top 1 M sites support ESNI. Moreover, based on their results, 84.5% of the websites which can be bypassed in terms of censorship are subject to IP address blocking. This indicates that even when ESNI is deployed, IP filtering cannot be avoided.

In the same direction, the authors in [18] investigate the adoption of ESNI as well as the impacts of DNS-based filtering on domain blocking. Their research is far broader in terms of geography, as it takes into account countries from diverse continents which are known to apply censorship and domain filtering. Contrariwise to the previous work, their results highlight that domain name encryption can be used to bypass censorship in more than 55% of the cases in China and more than 95% in the domains of the other examined countries, except from Iran where it was almost infeasible to circumvent any domain.

The study in [19] examines the applicability of ESNI and DoH/DoT mechanisms to lessen privacy leaks. Taking into account these mechanisms, they examine destination IP addresses to infer if multiple IP addresses are mapped to the same hostname. According to their results, 30% of the examined domains are mapped k-anonymously to more than 100 IP addresses. On the contrary, as they claim, 20% of the examined hostnames result in a one-to-one mapping, something that indicates a potential privacy leak by simply monitoring the visited hostname.

In the same direction, the authors in [20] examine the potential of inferring the server domain name by monitoring encrypted traffic relying on ESNI or DoH. After deploying a machine learning model, they state that it is possible to deduce 80% of the monitored domain names, with an F-score that exceeds 0.8.

3 Protecting the SNI in TLS Handshakes

TLS operates in the session layer of the Open Systems Interconnection (OSI) model. It makes use of both symmetric and asymmetric cryptography. The usual approach is that asymmetric cryptography is used to exchange the symmetric keys, which are then used to encrypt the traffic between the communicating parties. The different cryptographic and communication parameters are agreed between the parties during the handshake phase.

Precisely, the main purpose of a TLS handshake is to establish the following: (a) selection of the TLS version that will be used, (b) selection of the ciphers that will be used, (c) authentication of the communicating parties, and (d) generation of the keys used for confidentiality and message integrity/authenticity. The message that initiates the TLS handshake is the ClientHello; this is also the message where the SNI information is transmitted.

The rest of this section provides some preliminaries regarding ESNI and ECH to highlight the similarities and differences between these two major versions of encrypted SNI.

3.1 Background on ESNI

Since the ESNI is sent in the ClientHello message, it cannot be encrypted with the TLS keys which are negotiated later in the handshake. The solution is to use a different public key solely for ESNI. There are diverse ways to distribute the public key and metadata used for encrypting the ESNI; these include publishing it to DNS or having it preconfigured to applications, which apparently does not scale. In the rest of this section, we will present the DNS case in order to cover all the privacy issues mentioned in Sect. 1.

There are two topologies in which ESNI operates: shared and split mode. In Fig. 2a, the shared mode is depicted where the client-facing server (or ESNI service provider) and the backend server (or TLS terminator) are co-located in the same physical machine, having the same IP address. In this case, the TLS connection is terminated in this shared host who has access to the plaintext of the connection. In Fig. 2b, the split mode is presented where the client-facing server and the backend server are two different entities with different IP addresses. In the present case, the DNS records point to the client-facing server who relays the connection to the backend server; here the TLS connection is terminated in the backend server and the client-facing server does not have access to the plaintext of the connection. In the rest of the text, we will use the split mode as it is the most general case.

Fig. 2.
figure 2

Possible topologies for ESNI

Full size image

When a client wishes to establish a TLS session using ESNI, it first acquires the ESNI encryption key; this could be done through DNS and preferably using DoH/DoT/DoQ for privacy. Then, it encrypts the SNI field using this key and sends the ClientHello message as depicted in Fig. 3. The client-facing server decrypts the ESNI and proceeds with the handshake with the decrypted SNI information. Naturally, if the decryption is unsuccessful, the handshake process is terminated. Although it can be considered one step forward towards better privacy, the main issue with ESNI is that other sensitive fields, such as the ALPN, are not protected.

Fig. 3.
figure 3

Using ESNI in the TLS 1.3 handshake

Full size image

3.2 Background on ECH

Similar to the case of ESNI, in ECH the key could be published to the DNS. The difference is that the type of the entry is labeled as HTTPS (TYPE 65). Thus, the point is to request from the DNS the specific type of entry for a host. The response contains an echconfiglist element which advertises the relevant key [21]. Figure 4 illustrates how the client-facing server can publish an ECH configuration, containing an ECH encryption public key and metadata, to a DNS server. A possible alternative to this mechanism is preconfiguring the ECH configuration to the client.

Fig. 4.
figure 4

Publishing an ECH public key to a DNS server

Full size image

ECH is supported only in TLS v1.3 [1] and newer versions. The descriptions below are based on the latest at the time of writing Internet draft for ECH, namely v14 [10]. The main objective of ECH is to protect the entire ClientHello message, including all the sensitive parameters exchanged during the TLS handshake. One of the main differences between ESNI and ECH is that in the former the connection is terminated if the ESNI cannot be decrypted, whereas in ECH two ClientHello messages are used in an attempt to complete the handshake as follows.

When a client wants to establish a TLS session with the backend server using ECH, instead of the typical ClientHello TLS message, it creates a ClientHelloOuter message with an outer SNI value pointing to the client-facing server. This message is transmitted in plaintext and contains an “encrypted_client_hello” extension, which carries a ClientHelloInner structure with an inner SNI value pointing to the backend server. The latter contains other sensitive data as well, such as the ALPN values; the entire ClientHelloInner is encrypted with the ECH public key. To initiate the TLS session, the client sends the ClientHelloOuter to the server. First, the decryption of the ClientHelloInner is tried; if it succeeds, the handshake is completed using the ClientHelloInner message only, otherwise it is attempted to perform a handshake with the ClientHelloOuter. These two processes, namely ECH acceptance and ECH rejection respectively, work as follows:

  • ECH acceptance. The client-facing server checks some parameters of the received message, for example that the TLS version is 1.3 or above and the “encrypted_client_hello” extension is well-formed. If these checks succeed, the client-facing server forwards the ClientHelloInner to the backend server; if the latter is able to decrypt it, the handshake is completed between the client and the backend server with the client-facing server forwarding the respective messages. This case is depicted in Fig. 5.

  • ECH rejection. If the backend server is unable to decrypt the ClientHelloInner, it notifies the client-facing server. Then, the latter completes the handshake between itself and the client with the ClientHelloOuter, sending the correct ECH key to the client. Finally, the client resends the ClientHelloOuter message using the correct key for encrypting the ClientHelloInner. This situation is depicted in Fig. 6.

Fig. 5.
figure 5

The server accepts ECH

Full size image
Fig. 6.
figure 6

ECH rejected due to incorrect ECH key

Full size image

4 Measurements

We performed a large-scale measurement of the adoption of both ESNI and ECH, based on the top 1M websites included in the Tranco list [16]. Tranco is a combination of three well-known lists, namely Alexa, Cisco Umbrella, and Majestic, and is already widely used by the research community. The reasons behind selecting Tranco have to do with reliability: similar lists disagree on the popularity of each domain, the domain rankings change significantly from day to day, and they are open to manipulation by malicious perpetrators.

The procedure is as follows: first, we check for the existence of ESNI and ECH key entries in DNS. If a key is found, the SNI field is encrypted using this key; otherwise we abort the test and return back to the first step using the next website from the list. Finally, a curl query is executed, first performing a DNS query to retrieve the IP address of the target server and then a TLS handshake with this same server. The main metrics we calculated during this campaign are: (a) DoH support while querying the top 1M domain DNS records, including ESNI/ECH keys and DNS A records, (b) ESNI support in the top 1M domains, and (c) ECH support in the top 1M domains.

4.1 Setup

For our measurements we used a Linux Virtual Machine (VM) equipped with 4 GB of RAM and 2 CPUs, each one with a clock speed of 2.1 GHz. We developed a bash script that retrieves ESNI/ECH public keys from DNS using the kdig tool in version 2.6.5 with DoH enabled. Then, the script executes HTTPS requests towards the websites using curl version 7.66.0 with DoH enabled. To parallelize the procedure, we split the top 1M domains of the original Tranco list into 15 different files and run 15 instances of the script, each having one of these lists as input. Figure 7 provides an overview of this procedure.

Fig. 7.
figure 7

Experimental setup

Full size image

In more detail, our script executes the operations presented in the pseudocode of Algorithm 1. After the Tranco list is split into smaller domain_list files, each of these files is used as an input to an instance of the script. For each domain in such a list, the script sends a DoH-enabled DNS request to retrieve the TXT resource record that holds the ESNI or ECH public key for the domain (step 2). If the key exists, it is used to encrypt the SNI field (when ESNI support is checked) or the entire ClientHello (when ECH support is checked); then, the TLS handshake is initiated (steps 3–4). If the key does not exist, the script continues without performing any request for the domain (step 6). Finally, the results for the domain are printed in a text file for further analysis (step 8). The data that we store are: the name of the domain, a boolean value showing if DoH is supported for the domain (doh_support(domain)), a boolean value showing that there exists a TXT record with a key in DNS (has(public_key)), and the result of the curl request that shows the outcome of three operations, that is, curl, TLS handshake and ESNI- or ECH-enabled TLS handshake (curl_result).

Algorithm 1
figure a

. Query domains for ESNI and ECH support

Full size image

4.2 Results

We analyzed 1M domains from the Tranco top 1M list and our findings are presented in Tables 1 and 2, both as number of domains and as a percentage of domains; moreover, for easy reference, Fig. 8 graphically depicts these results. Regarding the key retrieval phase, it is perceived that only 18.2% of the domains (that is, 182,068) have an active ESNI key record stored in DNS. The key was retrieved successfully with a DoH query in all but one case, where the relevant TXT resource record retrieval was performed over plain DNS. As far as it concerns ECH, we only found one key in DNS for the “cloudflareresearch.com” domain; also in this case DoH was used for its retrieval. This last finding suggests that ECH has not been adopted yet; this is further verified by the results presented in previous work [18].

Table 1. Overall measurement results
Full size table
Fig. 8.
figure 8

ESNI/ECH and DoH support in the top 1M domains

Full size image

While querying the top 1M domains, we also kept data for other relevant supported standards. First, we calculated that DoH requests were completed successfully for 99.8% of the examined domains (or 998,256 domains). Regarding the curl queries, 991,323 were completed successfully and 8,677 failed; this very small number could be attributed to temporary failures of some web sites. It is worth mentioning that the curl queries for all the domains with ESNI key were completed successfully, but failed for the single domain with ECH key. A further observation is that, while connecting to the aforementioned domains, a TLS handshake was successful in 78.3% or 783,416 domains; this is consistent with other recent independent TLS uptake metrics [22]. This figure comprises also the 16.9% (or 169,784) of the domains that completed the handshake procedure with ESNI enabled.

Further concentrating only on the domains that support ESNI, we performed an ESNI-enabled TLS handshake to all the 182,068 domains that have an ESNI key in DNS; our findings are presented in Table 2. As stated above, only one domain did not have DoH support. Based on our measurements, in 93.6% of the domains which have been found to have an active ESNI key, the TLS handshake was successful; the handshake including the ESNI as well was successful in 93.2% of the total number of domains.

Table 2. Measurement results for domains supporting ESNI
Full size table

Based on our findings, it can be stated that ESNI implementation in the most popular websites is \(\approx \)18%, whereas ECH implementation is practically non-existent. Regarding the retrieval of the ESNI/ECH public key, a DoH query can be performed for almost all domains (99.9%), thus, protecting end users’ privacy from third-party eavesdroppers. Notably, the results in ESNI-enabled domains (Table 2) between plain TLS handshakes and ESNI-enabled TLS handshakes shows a difference of 0.4% or 666 domains. Given that these 666 domains neither are offline nor have a wrong ESNI key (in this case the TLS handshake would have failed as explained in Sect. 3.1), leads us to the conclusion that, although they have an ESNI key in DNS, the web servers of these domains are not properly configured to perform the ESNI procedure.

5 Conclusions

This paper examines the adoption of two well-known TLS extensions, namely ESNI and ECH. According to our measurements, only the ESNI extension has already been deployed, although not extensively. More precisely, we found that only 18.2% of the top 1M websites in the Tranco list have published an ESNI key in the DNS. After using these keys in the TLS handshake process, we found that these keys have been successfully used in the TLS handshake in 16.9% of the aforementioned domains.

With regards to the most recent ECH extension, we found only a single DNS record entry with a public key. Although this can be considered normal, given that the first appearance of ECH was two years ago and the specification is at the time of writing still in draft form, it shows a reluctance on the service providers’ side to adopt it. On the other hand, the wide deployment of DoH provides a major milestone, as it is the main prerequisite for protecting end user privacy through ESNI/ECH.

As future work, we intent to revisit our large-scale measurements of the adoption of ESNI/ECH, as soon as the respective RFC is finalized and the standard is deployed. A further enhancement of the present work would be a more in-depth analysis of the ESNI/ECH adoption by employing the complete Tranco list that comprises 7M domain names in order to argue whether the same results are observed in less popular web sites as well. Finally, we plan to further investigate the geographic distribution of the examined domains, as well as to analyze the domains which suppress encryption mechanisms for efficient censorship.