How we defend our systems is about to shift in the coming weeks with a major change to the Transport Layer Protocol (TLS) taking place between the browser and a new device called the client-facing server, which is mostly positioned at content delivery networks (CDNs). Encrypted Client Hello (ECH) has now been enabled in the Chrome browser, and it will soon be enabled in the Mozilla browser and at servers hosted by Cloudflare. It is possible other CDNs 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 Client Hello 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 IETF standard TLS.
What the TLS Encrypted Client Hello changes mean for you
It is important to be aware of these forthcoming changes and how this affects 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 alternative 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 alternative 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 lookup blocking services
These types of services are not impacted, as the browser continues to perform a look-up of the destination domain name to the DNS server that offers the DNS-based screening capability. 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 organization 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 organization’s 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 organizations 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. Some service offerings do not currently intercept web traffic, as DNS-based blocking and protection services which provide protection from malicious websites.
Browser security extensions
The 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 (that is, containerized) 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 in 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 the 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 (for example, 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 in 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 (IoCs) with hostnames for destination websites will remain effective.
When ECH is enabled, visibility to the SNI is eliminated and the IDS can see 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 is 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 defence 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 organization that purchases the CDN’s service offering? Or will the burden of being compromised rest with the organization in recovery?
- What does it mean regarding national and regional regulation schemes (for example, EU), which have specific requirements as CDNs are mostly US 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.
Kathleen Moriarty is Chief Technology Officer at the Center for Internet Security and the former IETF Security Area Director. She has more than two decades of experience working on ecosystems, standards, and strategy.
Adapted from the original post on CIS Blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.