Security Control Changes Due to TLS Encrypted ClientHello

Encrypted ClientHello (ECH) has been enabled in the Chrome browser, the Mozilla browser, and servers hosted by Cloudflare. It is possible other content delivery networks (CDN) will follow suit. Cloudflare supports about 70% of websites and will add support back for beta client sites in early 2024 after running into some issues with the initial testing in October 2023.

ECH means that HTTPS sessions will no longer expose the domain name of the destination web server when ECH is enabled. The entire ClientHello is encrypted from the web browser to the CDN, thus limiting visibility by any middlebox systems to the name of the client-facing server hosted by the CDN in the “ClientHelloOuter” as the destination and the browser as the other endpoint. The ”ClientHelloInner” with the true destination will remain encrypted and only visible to the browser and CDN. There are some great resources that discuss the privacy reasons behind these changes in the Internet Engineering Task Force (IETF) standard TLS.

What the TLS encrypted ClientHello changes mean for you

It is important to be aware of these changes and how they affect your current set of defences. Depending on the mechanisms used for the detection of threats by middlebox devices, the ability to detect threats based on a known malicious URL or known bad domain name using signatures on TLS-encrypted sessions may be diminished. It’s important to note that your devices may use alternate techniques and may not be affected by this change; however, many will be impacted.

As visibility is limited on the wire, it is likely that we will see shifts in how protection is offered. Ideally, this would be planned in advance to also consider the impact of threats to enterprise networks resulting from known attack vectors. It is important to monitor the efficacy of your security products in the coming weeks and months. If there is a decline or anticipated decline, reach out to your vendor to determine if alternate approaches are being added. This is also a time to reconsider your security protection strategy with the evolving push for endpoint-based protections due to the increased use of encryption and built-in security. As we move to zero trust, some controls will no longer be necessary as new controls that are built-in may supplant the need for the traditional infrastructure.

Security defences that won't be impacted by this change

Domain name look-up blocking services

These types of services, which include the Multi-State Information Sharing and Analysis Center's (MS-ISAC’s) Malicious Domain Name Blocking and Reporting (MDBR) and MDBR+ offerings, are not impacted, as the browser continues to perform a look-up of the destination domain name. The service offerings use DNS to determine if access to a website is permitted and there is no change in terms of this capability. This provides a control point in aggregate where an organisation can contract with services to provide protection from malicious content.

The DNS service offerings are typically provided through a contract where a service-level and security-level agreement is in place to protect the privacy of the organisations' web access history.

Managed endpoint devices

ECH and DNS over HTTPS (DoH) are disabled in Chrome, Firefox, and Edge on a managed device. This means that ECH will not impact security services as they function today on managed devices since it is assumed that organisations control their endpoints and have the chance to ensure this capability is disabled.

If a product is listed as impacted but the clients are managed, this changes the impact of the other services to not impacted.

Note that instances of bring your own devices (BYOD) may be impacted if not managed.

Endpoint protection services

As encryption is increasingly deployed, the endpoint becomes a greater focus for protection.

An endpoint agent-based product continues to provide protection for applications running directly on the operating system. An endpoint agent-based product will not be able to intercept browser connections where ECH is supported, as any interception is considered an attack by the TLS protocol extension for ECH. CIS Endpoint Security Services (ESS) and the Elections Infrastructure Information Sharing and Analysis Center's (EI-ISAC's) Endpoint Detection and Response (EDR) service offerings do not currently intercept web traffic, as MDBR and MDBR+ provide protection from malicious websites via DNS protections.

Browser security extensions

Google Safe Browsing extension (supported on Chrome and Firefox) or Edge’s Microsoft Defender SmartScreen integrated into the browser will continue to prevent access to known malicious sites included in their blocklists.

Browser extensions to monitor for data exfiltration or other services will continue to function since they are part of the browser platform.

Browser tabs executing in isolation (a.k.a. containerised) will continue to prevent malware from escaping the tab as long as there are no known/unknown vulnerabilities exploited in the browser.

Security products that may be impacted by ECH

Endpoint products that proxy web traffic

Any endpoint agent-based product will not be able to proxy web traffic from a browser with ECH enabled. Any interception between the browser and CDN endpoint terminating the TLS session is considered an attack by the protocol and is prevented by the design.

TLS proxy services

TLS Proxy firewalls or deep packet inspection services that intercept, terminate, and then restart a TLS session maintain full visibility of traffic with the exception of the SNI value unless ECH is disabled at the browser. When ECH is enabled, visibility to the session content and outer ECH is possible. It provides only the hostname of the CDN where use of the SNI value contained in the ClientHelloInner is no longer possible. If your firewall relies upon SNI to determine which sessions to inspect (e.g., approved categories to remain encrypted such as healthcare or financial), then you need to disable ECH. A middlebox is considered an attacker in the ECH draft and downgrading a session to remove ECH is not permitted by the firewall. This can be done at the browser.

TLS proxies break zero trust architectures, as they provide a point of exposure for aggregated traffic that would otherwise be secured and distributed. As other compensating controls and built-in security mechanisms improve, the value of this type of interception should diminish. Monitoring the efficacy of your tools over the coming years will assist in business decisions to remove unnecessary layers of protection as new built-in capabilities emerge.

Intrusion detection systems (IDSes)

When ECH is not enabled for managed systems, capabilities to see the true destination server listed in the SNI remain. Detection using indicators of compromise (IoC) with hostnames for destination websites will remain effective.

When ECH is enabled, visibility to the SNI is eliminated and the IDS is capable of seeing the TCP/IP packet header information with a destination of the CDN. With this configuration, IoCs on destination hostnames will not be visible to the IDS.

Supporting business needs with security investments

As encryption continues to increase in pervasiveness on the Internet, it's important to monitor the effectiveness of controls and to adjust. Ideally, this would be in advance as opposed to after these new controls have been implemented. The technology landscape is quickly evolving; new protection and defense capabilities are emerging. In a number of cases, these new capabilities are built-in and may reduce the need for adding layers with additional products. As infrastructure changes continue to evolve, such as with cloud-native trends and endpoint protection capabilities, it will be necessary to evaluate and balance out security investments to ensure business needs are met.

Here is a resource that explains the privacy-security tradeoffs for ECH and includes links to how each browser sets the option for this capability.

Considerations for the future

This shift in protections also raises a few additional questions:

• In instances where one can only see the client-facing server hosted by the CDN as a destination with ECH enabled, does this also shift the responsibility of protection to the CDN for potentially malicious content supported through the CDN as other control points are diminished?
• Will the CDN be held responsible for ensuring they are not assisting customers to serve up malicious content?
• Will this burden be placed only on the organisation that purchases the CDN’s service offering? Or will the burden of being compromised rest with the organisation in recovery?
• What does it mean regarding national and regional regulation schemes (e.g., EU), which have specific requirements as CDNs are mostly U.S. companies?

We will see the short-term impact of these changes in the coming weeks. If malware infections increase, there may be pivots made on policies and services to adjust for the long-term.