Skip to main content

· 4 min read

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

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 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

Do get in touch if you need support with this.

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 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

· 6 min read
lie

It's actually 5 less problems. But that wouldn't have made a catchy title.

The DiscrimiNAT Firewall now integrates with AWS' Gateway Load Balancer. Deploying this version alleviates five distinct problems.

  1. Exfiltration and Command & Control TTPs
  2. Discovery and maintenance of outbound FQDNs' allowlists
  3. High Availability
  4. Load Balancing
  5. Auto Scaling

Read on for more details.

· 8 min read
learning

Test driving the Log4Shell vulnerability with various versions of Java and observing the network egress connections

Log4Shell in a nutshell

➟ An attacker is able to conduct a completely unauthenticated Remote Code Execution on a publicly-exposed service.

➟ If a JVM-based service (Java, Scala, etc.) is using the log4j logging library (very popular), the service is vulnerable.

➟ A patched version of the log4j library, version 2.15.0, that fixes this issue was released on 06 Dec 2021.

➟ log4j 2.16.0 was released at 13 Dec 22:28 with the following note:

· 10 min read
learning

Identify and protect GitHub Actions' permissible network egress, with leak detection

Story of pipeline nobody would like to see develop a leak.

GitHub Actions Pipeline Leak with Secrets and Snowflake Data

It runs in a self-hosted GitHub Actions Runner, spun up on AWS spot instances by philips-labs' terraform-aws-github-runner, connecting to Snowflake – with 'secrets' stored in GitHub itself.

🏗 we build the normal list of FQDNs such a pipeline accesses when run
🔒 enforce it via the DiscrimiNAT Firewall
🔇 introduce an unobtrusive curl command, like in the Codecov Uploader breach
🚫 see it fail in exfiltrating any data from the CI environment
🔎 detect the attempt in flow logs

· 9 min read
Last updated: Mar 20, 2023

The week before the pentest

The situation is nothing to write home about. C2 malware, supply-chain risk, ransomware, cryptomining, unsolicited telemetry, plaintext protocols across the Internet, escalating data egress charges – you name it – this one unplugged gap in the Cloud, the outbound connections originating from your deployments, keeps on giving (or taking.)

With no human-readable visibility on any egress flows, not much you can do with all those IP addresses in the flow logs. Talk about flying blind. It's time to install a filtering proxy, and Squid is the word on the grapevine.

Let's take a deep-dive 🔎

· 7 min read

Why do we seek IP addresses in the Cloud-first world?

  • Is it the mindset leftover from the bygone era of procured hardware & CIDR blocks?
  • Is it the availability of published IP ranges that makes you want to utilise them?
  • Or is it a hard bit of how the internet works to detach from?

Let's consider the case of Datadog Agent v7.32.3, the endpoint for which, as per official docs, would simply be 7-32-3-app.agent.datadoghq.com. This is the contract Datadog will fulfil, and we shouldn't assume more.

But first, Datadog IP ranges at present...

· 7 min read
learning

A closer look at what data is sent to entropy.ubuntu.com on Cloud instance boot

Routine Test

At Chaser, we routinely test a variety of real-world setups through the DiscrimiNAT Firewall. It helps keep on top of implementation subtleties by different vendors and identify any regressions early as we improve the product.

FQDN filter for Ubuntu on GCP egress, shall we?

So we fire up Ubuntu Bionic Beaver LTS this time, with egress allowed to 0.0.0.0/0 on all ports.

· 3 min read
learning

Observation of traffic from a Windows Server 2019 instance with a firewall restricting its egress, and a CloudWatch exercise in filtering and aggregation

Routine Test

At Chaser, we routinely test a variety of real-world setups through the DiscrimiNAT Firewall. It helps keep on top of implementation subtleties by different vendors and identify any regressions early as we improve the product.

FQDN filter for Windows on AWS egress, shall we?

So we fire up the latest and greatest Windows this time, with outbound allowed to 0.0.0.0/0 on all ports.