Encrypted Client Hello

Background

When you want to visit a website, you might click a link or type in the domain name and boom, in an instant, the page loads on your screen. Behind the scenes, however, a complex exchange occurs between your browser (client) and the website’s server to establish a secure connection. This process, known as the TLS handshake, negotiates how information will be encrypted and transmitted between the two parties. While different versions of TLS (Transport Layer Security) implement this handshake slightly differently, the overall goal remains the same: agree on secure parameters for communication.

The TLS handshake begins when the client sends a Client Hello message to the server. This message contains critical information, such as supported versions of TLS, a list of preferred cryptographic algorithms (cipher suites), and any additional capabilities or settings required to establish a secure channel. These capabilities are communicated through a series of extensions, which serve as modular options that allow the client and server to enable or disable specific features based on what they support.

Client Hello and Extensions

The Client Hello message includes a set of extensions that help tailor the connection to the client’s needs and the server’s capabilities. Some commonly used extensions include:

• Supported Versions: Indicates the versions of TLS the client can support, such as TLS 1.2 or TLS 1.3.
• Server Name Indication (SNI): Allows the client to specify the exact hostname it wants to connect to, useful for servers that host multiple domains on a single IP address.
• Key Share: Provides the client’s public key for Diffie-Hellman or elliptic curve key exchanges, which are used to securely agree on a shared secret.
• Signature Algorithms: Lists the signature algorithms that the client supports, enabling the server to choose a compatible one for signing handshake messages.
• Supported Groups: Specifies the elliptic curve groups that the client supports for key exchange.

These extensions offer flexibility and extensibility to the handshake process, enabling advanced features like session resumption, early data transmission, and post-quantum cryptography.

After the client sends its Client Hello, the server reviews the extensions and chooses the appropriate configuration to establish secure communication. This configuration is then communicated back to the client in the Server Hello message, and both parties proceed to exchange cryptographic keys and complete the handshake. The inclusion and configuration of extensions play a important role in determining the security properties and features of the connection.

This process has traditionally been visible to anyone observing the network traffic. This means that extensions like SNI, which reveal the hostname, and details about supported cipher suites are exposed, providing an opportunity for attackers to identify or intercept connections. This visibility is what the Encrypted Client Hello (ECH) extension aims to address.

Purpose of ECH

The primary goal of ECH is to encrypt sensitive fields in the Client Hello message to prevent eavesdroppers and passive observers from gathering information about a client's capabilities, preferences, and intended destination. Without ECH, the Client Hello message is transmitted in cleartext, which exposes critical information such as:

1. Server Name Indication (SNI): The SNI extension contains the hostname of the server the client wants to connect to, which can be used for tracking or censorship.
2. Supported Cipher Suites: These can reveal the client’s operating system and application details.
3. Supported Extensions: Extensions such as supported_groups and key_share can provide additional fingerprinting vectors.

ECH encrypts the Client Hello, thereby preventing these fields from being visible to anyone other than the intended server. This helps mitigate attacks like domain fronting and hostname enumeration.

How ECH Works

ECH is designed with a two-step handshake process:

1. Outer Client Hello:

   • Contains limited information necessary to establish an initial connection and is intended to be observed by the network.
   • Includes an encrypted payload that contains the inner Client Hello and necessary keys to decrypt it.

2. Inner Client Hello:

   • Contains the full set of parameters for establishing the secure session.
   • Encrypted using a public key obtained from the server in a prior step or through DNS records (using DNS over HTTPS/DoH).

The ECH works by encrypting the Client Hello and some sensitive extensions, such as SNI, using a key that the server advertises via DNS. The server will then decrypt this encrypted inner Client Hello and respond using the same encrypted parameters.

ECH Components

1. ECH Configuration

   • The server advertises its public key for ECH in DNS as an HTTPS RR record. This public key, along with additional parameters, forms the ECH configuration. The client obtains this key and uses it to encrypt the sensitive parts of the Client Hello.

2. Outer Client Hello

   • The outer Client Hello is a minimal Client Hello message that contains only public information, such as legacy fields or placeholders. It also contains the encrypted payload of the inner Client Hello as an extension.

3. Inner Client Hello

   • The inner Client Hello is encrypted using the public key from the server's ECH configuration. This inner Client Hello contains the actual SNI, cipher suites, and other sensitive extensions that should not be visible to passive observers.

Example ECH Workflow

1. Client retrieves ECH configuration: The client queries the server's DNS for the ECH configuration, which includes the server's public key and supported ECH versions.

2. Client constructs the inner Client Hello: Using the obtained ECH configuration, the client constructs the inner Client Hello message, which includes all sensitive parameters and extensions.

3. Client encrypts the inner Client Hello: The inner Client Hello is encrypted with the server's public key from the ECH configuration.

4. Client sends the outer Client Hello: The outer Client Hello contains a reference to the ECH configuration, the encrypted inner Client Hello, and other public information.

5. Server decrypts the inner Client Hello: If the server recognizes the ECH configuration and has the corresponding private key, it decrypts the inner Client Hello and processes it.

6. Server responds based on inner Client Hello: The server responds using the parameters from the decrypted inner Client Hello, establishing a secure session with the client.

Technical Details of ECH

1. ClientHelloOuter and ClientHelloInner

   • The ClientHelloOuter is a minimal and public Client Hello message. It contains an encrypted payload (encrypted_client_hello extension) representing the ClientHelloInner.
   • The ClientHelloInner is the actual Client Hello with all the client's desired configurations.

2. Encryption Scheme

   • The ECH uses HPKE (Hybrid Public Key Encryption) for encrypting the inner Client Hello. HPKE is a general-purpose public key encryption scheme that provides confidentiality, integrity, and authenticity for messages.

3. Handling of ECH Keys

   • The ECH key is a public/private key pair. The server advertises the public key, while the server keeps the private key to decrypt the inner Client Hello.

4. ECH Extension Structure

   • The encrypted_client_hello extension in the outer Client Hello contains the following fields:
   • Config ID: Identifier for the ECH configuration.
   • Enc: Encrypted key share used in the handshake.
   • Cipher Suite: Specifies the encryption suite used (e.g., HKDF-SHA256/AES-128-GCM).
   • Payload: Encrypted inner Client Hello.

ECH Benefits

1. Protection of SNI:

   • The Server Name Indication (SNI) extension is encrypted, preventing passive observers from knowing which specific server or service the client is connecting to. This is crucial for circumventing censorship or preventing tracking.

2. Reduced Fingerprinting:

   • By encrypting the Client Hello, ECH minimizes the attack surface for client fingerprinting. Observers cannot see the list of supported cipher suites, extensions, or TLS versions.

3. Resilient Against Active Attacks:

   • Active attackers who intercept and modify the Client Hello cannot easily decrypt or tamper with the encrypted inner Client Hello, as they would need the server’s private key.

4. Compatibility:

   • ECH maintains compatibility with non-ECH aware servers by using the outer Client Hello. If the server does not support ECH, it will ignore the encrypted extension and continue with the outer Client Hello.

ECH Challenges and Limitations

1. Deployment Complexity:

   • ECH requires the server to advertise its ECH configuration via DNS, which involves changes to the DNS infrastructure.

2. Backward Compatibility:

   • Older servers that do not support ECH will fallback to the outer Client Hello, losing the privacy benefits.

3. DNSSEC Dependencies:

   • To ensure the integrity and authenticity of the ECH configuration, DNSSEC (DNS Security Extensions) should be used. However, not all DNS resolvers and servers support DNSSEC.

Current Status and Adoption

ECH is currently an experimental extension and is not yet standardized. It is defined in the TLS Encrypted ClientHello (draft-ietf-tls-esni-10). Adoption is currently limited, and ECH is primarily implemented in some experimental versions of popular browsers like Google Chrome and Mozilla Firefox, along with support from cloud providers like Cloudflare.

Encrypted Client Hello (ECH) can provide substantial privacy benefits, but like many security features, it also has the potential to be misused by malicious actors. Understanding how ECH could be leveraged for nefarious activities and identifying anomalies in its implementation can help defenders detect and respond to such threats. Let’s explore how attackers might exploit ECH and some signs that defenders can look for to identify misuse.

Potential Malicious Uses

1. Bypassing Network Security Measures:

   • Attackers can use ECH to bypass network-based security measures such as firewalls, intrusion detection systems (IDS), and censorship systems. ECH conceals the Server Name Indication (SNI) and other fields in the Client Hello that network-based devices rely on for inspection and filtering.
   • This can make it harder for defenders to identify connections to malicious or unapproved domains, as the SNI is encrypted and not visible to the network monitoring tools. Attackers could leverage this capability to hide communication with Command and Control (C2) servers, exfiltrate data, or initiate connections to known malicious endpoints.

2. Hiding Command and Control (C2) Communications:

   • Attackers might use ECH to initiate communications with their C2 servers, as it becomes challenging for network-based defenders to see which domain or server the client is connecting to.
   • Using ECH, attackers can blend their traffic into legitimate encrypted traffic, making it difficult for defenders to differentiate between benign and malicious communications.

3. Evading Reputation-Based Blocking:

   • Reputation-based blocking relies on identifying known malicious IPs, domains, or certificates. By encrypting the SNI and the entire Client Hello, attackers can prevent defenders from seeing which domain is being accessed, evading detection systems that rely on domain reputation.
   • This makes it difficult for defenders to identify connections to newly registered or suspicious domains that attackers often use in campaigns.

4. Facilitating Domain Fronting or Domain Masquerading:

   • Attackers can use ECH to perform domain fronting, where the domain visible to an observer (the outer Client Hello) is different from the actual domain accessed (encrypted in the inner Client Hello). This makes it difficult for defenders to identify the true destination.
   • Malicious actors could use this technique to evade detection and access blocked content or initiate connections to domains that would normally be blacklisted or restricted.

5. Obfuscating Initial Access or Phishing Attempts:

   • ECH can be used to hide the actual destination of initial access attempts or phishing campaigns. For example, if an attacker uses ECH to hide the SNI during a phishing campaign, network defenders will be unable to inspect the hostname and identify suspicious traffic patterns.

Indicators of Suspicious or Misused ECH

Given the potential for attackers to misuse ECH, defenders need to understand what suspicious activity might look like in the context of ECH. Here are some key indicators that might tip off defenders:

1. Suspicious ECH Configuration or Mismatched Hostnames:

   • If the outer Client Hello contains an SNI that doesn’t match the server being contacted or doesn’t align with expected behavior (e.g., different from the DNS query or observed connection patterns), it might indicate domain fronting or obfuscation.
   • Look for mismatches between DNS queries and observed ECH configurations or outer SNI values, as this might suggest that ECH is being used to hide the true target server.

2. Unexpected ECH Usage Patterns:

   • A sudden increase in the use of ECH by endpoints that previously didn’t use it can indicate an attempt to hide malicious traffic.
   • Track whether ECH is being used selectively for specific connections or domains, which might suggest that attackers are using it for targeted malicious activities.

3. Suspicious JA3 and JA4 Fingerprints:

   • JA3 and JA4 fingerprints can be used to identify unique characteristics of TLS and QUIC connections. Unusual or unknown JA3/JA4 hashes, especially if they don’t match legitimate applications or expected usage patterns, can indicate suspicious activity.
   • Monitor for JA3/JA4 fingerprints that are commonly associated with malware, penetration testing tools, or custom clients that might be used for malicious purposes.

4. Misconfigured or Invalid ECH Parameters:

   • Look for ECH extensions with malformed or suspicious parameters, such as unusually large encrypted payloads, unsupported cipher suites, or incorrect Config IDs.
   • A common misconfiguration might include encrypted Client Hello messages that fail to conform to known standards or server responses that indicate decryption failures.

5. Unusual ECH Version or Cipher Suite Selection:

   • Monitor for ECH implementations using uncommon or outdated ECH configurations. Anomalous ECH versions, unsupported cipher suites, or odd combinations of extensions can indicate experimentation or misuse by an attacker.

6. ECH Rejected by Server Yet Connection Proceeds:

   • If a server rejects the ECH, it typically falls back to the outer Client Hello. However, if the server is not known to support ECH but accepts the connection regardless, it might indicate that an attacker has configured the server for malicious purposes.

7. Uncommon Traffic Patterns:

   • Look for uncommon traffic patterns like frequent retries, unexpected ECH renegotiations, or excessive use of early data (0-RTT) sessions that are not typical of legitimate connections.
   • Excessive ECH rejections or modifications might suggest that attackers are experimenting with different configurations to bypass security controls.

Defending Against ECH Misuse

1. Implement Deep Packet Inspection (DPI) with ECH Awareness:

   • While DPI tools cannot decrypt the ECH, they can still be configured to identify the presence of ECH extensions and analyze metadata. Configure DPI systems to monitor ECH usage and raise alerts for suspicious patterns.

2. Leverage Network Flow Analysis and Behavioral Detection:

   • Analyze network flows for abnormal usage patterns, connections to suspicious IPs, or unusual amounts of encrypted traffic with unknown destinations. Behavioral detection can help identify anomalies even when traffic is encrypted.

3. Implement DNS Security:

   • Use DNSSEC to ensure the authenticity of ECH configurations retrieved from DNS. DNS-based attacks, such as spoofing ECH configuration records, can lead to exposure or misuse of ECH. Ensure DNS records are validated, and look for inconsistencies between DNS and observed traffic.

4. Use Certificate Transparency Logs:

   • Monitor Certificate Transparency (CT) logs for the presence of certificates associated with suspicious domains or ECH configurations. This can help detect when attackers issue certificates or misconfigure ECH.

5. Use JA3 and JA4 Fingerprint Whitelisting:

   • Maintain a whitelist of known good JA3 and JA4 fingerprints for approved clients and applications. Alert on or block unknown or suspicious fingerprints.

6. Collect and Analyze Encrypted Traffic Metadata:

   • Focus on metadata such as connection timing, session duration, and handshake anomalies. Even if the content is encrypted, metadata can provide clues about abnormal or malicious behavior.