Disabling Encrypted ClientHello in Google Chrome, and Why

Last updated: June 16, 2024

In cases where inspection of domain names in TLS connections is acceptable and desirable (such as in enterprise environments), TLS Encrypted ClientHello in Google Chrome can be disabled.

PowerShell tl;dr

$PATH = "HKLM:\\Software\Policies\Google\Chrome\"
$NAME = "EncryptedClientHelloEnabled"
if (-not(Test-Path $PATH)) {New-Item -Path $PATH -Force}
New-ItemProperty -Path $PATH -Name $NAME -Value 0x0 -Force

What is ClientHello

ClientHello is a TLS handshake step initiated by a client for a TLS connection to a server. It contains Server Name Indication (SNI) besides Application-Layer Protocol Negotiation (ALPN), etcetera, in plaintext – so the receiving server can serve up the correct server certificate (on an otherwise shared IP address) and route the request to the most suited backend. In the world before Encrypted ClientHello, transit encryption has not begun until this point.

What is Encrypted ClientHello

Conceived initially as Encrypted SNI (ESNI), its scope was to mask the SNI alone. SNI leaks the target domain for a client-initiated connection, in plaintext, to all parties that may be snooping on the wire. Encrypted ClientHello (ECH) extends the concept to most parameters in a ClientHello.

One of its uses is "to prevent censors from learning the server names". The paper On the Importance of Encrypted-SNI (ESNI) to Censorship Circumvention (2019) studies the implications of ECH for censorship.

The IETF standard for ECH is still in draft and at version 17 at the time of writing.

The side-effect of masking the target domain is that any transparent middle-boxes, firewalls, IDS, IPS and the like will no longer have visibility of domain names in outbound connections. This could impact the quality of logging and the effectiveness of network controls.

It is not expected that ECH will have a similar effect on connection-terminating inspection solutions such as proxies and firewalls with TLS decryption configured and the CA certificates of those distributed to the clients' trust stores.

Disabling ECH from Chrome UI (v105 - v121)

Google Chrome announced their intent (Sep 11, 2023) to switch on ECH by default from v117 onwards. This has impacted some of our customers using DiscrimiNAT to either monitor or control outbound traffic from cloud-based workstations with Chrome installed as the browser.

In cases where inspection of domain names in TLS connections is acceptable and desirable, ECH can be disabled by visiting chrome://flags in Google Chrome and searching for Encrypted ClientHello or by simply visiting chrome://flags/#encrypted-client-hello instead and setting the property to Disabled.

Disabling ECH from Chrome policies (v122+)

A file with the following contents should be present under /etc/opt/chrome/policies/managed/ on a Mac/Linux system.

{
  "EncryptedClientHelloEnabled": false
}

This file location for policies is documented here, and the policy EncryptedClientHelloEnabled itself here.

The effect of the policy can be observed then at the URL chrome://policy/ within Chrome.

Disabling ECH using PowerShell

Under Windows, Registry location Software\Policies\Google\Chrome\EncryptedClientHelloEnabled should be set to 0x0.

This location is documented under the EncryptedClientHelloEnabled policy for Google Chrome Enterprise.

A handy PowerShell script to create the path if it does not exist and then force update the key name (whether or not it exists prior) is as follows:

$PATH = "HKLM:\\Software\Policies\Google\Chrome\"
$NAME = "EncryptedClientHelloEnabled"
if (-not(Test-Path $PATH)) {New-Item -Path $PATH -Force}
New-ItemProperty -Path $PATH -Name $NAME -Value 0x0 -Force

Headless Chrome in Containers

You may be running something like, if not, Selenium for headless tests in a continuous integration pipeline, the outbound traffic for which is filtered via DiscrimiNAT.

To disable ECH in a container, the Mac/Linux instructions above need to be applied inside the container. This can be achieved:

• either by mounting a file, say ech-disabled.json (with the following content), stored under a directory called chrome-managed-policies in the current working directory, at /etc/opt/chrome/policies/managed/ inside the container

{
  "EncryptedClientHelloEnabled": false
}

docker run --volume "./chrome-managed-policies/:/etc/opt/chrome/policies/managed/" selenium/standalone-chrome:125.0

• or by building a new container image. An example Dockerfile would look like

FROM selenium/standalone-chrome:125.0

COPY chrome-managed-policies/ /etc/opt/chrome/policies/managed/

Do get in touch if you need support with any of these.

DiscrimiNAT's behaviour with ECH

Since the release of DiscrimiNAT v2 in November 2020, we've built in the detection of ESNI/ECH use and prevented the egressing of such traffic altogether – even if an explicit rule to allow the domain name exists. This is because, as a transparent inspection device, DiscrimiNAT cannot decrypt an encrypted TLS extension and ensure that it contains an allowed destination address.

DiscrimiNAT also ignores the outer, unencrypted SNI if an inner, encrypted SNI is set too. This is a known method of evading firewalls that may only be satisfied with the presence of an allowed domain name in the outer, unencrypted SNI. For more information on this, see defo.ie or tls-ech.dev and our comparison page.

The flow log message reason field for denying traffic with ECH set will contain the phrase ech was found. An example of such a log message from discriminat-flow is:

{
    "outcome": "disallowed",
    "proto_v": "1.3",
    "reason": "ech was found",
    "spt": 50083,
    "dhost": "mail.google.com",
    "dst": "74.125.69.18",
    "proto": "tls",
    "cat": "client",
    "dpt": 443,
    "instance": "discriminat-tiger-phf7",
    "src": "192.168.101.7"
}

Also note that a Layer 3 check, that is, if the client is connecting to a legitimate IP address for the presented domain name, is carried out after the presence of ECH check; therefore, if both checks had to fail, the message ech was found will take precedence.

Discuss on Hacker News | Discuss on Reddit | Discuss on Twitter | Discuss on LinkedIn | Discuss on Mastodon