Blog Post

TLS: Encrypted Client Hellos

TLS Client HellNo

Many security and privacy minded folks have been watching the EARN IT act (TLDR – this would essentially choose winners and losers for end-to-end encryption; a page straight out of The Shock Doctrine🤦). But something else has been underway for most of this year that you most likely haven’t heard about: Encrypted Client Hellos (it has been dubbed ECHO). Apparently they may be coming. Many of us have heard chatter about Encrypted DNS (DNSCrypt, DoH and DoT) potentially limiting visibility for security boots-on-the-ground. At least some of us have also focused on the potential security implications of the widespread adoption of Encrypted SNI (encrypting the server name extension in the TLS client hello so that anyone intercepting or monitoring, like ISPs, governments, and other benevolent entities can’t use it to identify what servers you are visiting).

Without ESNI

With ESNI

But as far as I can tell there has not been any open discussion about ECHO in the infosec community. I just recently stumbled upon it myself in an RFC draft; so here I am, discussing it.

Specifically there is an RFC draft that rather than encrypting just the SNI extension, includes the option of encrypting the entire client hello. This is actually an update to the RFC draft that proposed ESNI and you can see the updates in the github commit history. The use case behind this appears the same as any other privacy-focused addition to the TLS protocol: to hide destinations from prying eyes that have access to your network traffic.

JA3 is Dead, long live JA3!

There are clearly serious security implications of this proposal being ubiquitously adopted. For instance, TLS fingerprinting technologies, such as JA3, are dependent on the information that’s in the plain text variant of that client hello. These technologies aren’t perfect, but the fact remains that this information is used by security analysts to identify threats and filter out false positives. The implication is that if the information is encrypted, then security teams lose that visibility and will be challenged with detection in encrypted traffic.

“ECHO works by encrypting the entire ClientHello, including the SNI

and any additional extensions such as ALPN. This requires that each

provider publish a public key and metadata which is used for

ClientHello encryption for all the domains for which it serves

directly or indirectly (via Split Mode).”

Avoiding Dystopia

I understand that it may currently be difficult to be optimistic about the future, but at least with TLS there’s not necessarily a cause for panic. Worst-case scenario, the widespread implementation of encrypted client hellos is a long way off. The first draft of the TLS ESNI RFC was written in September 2018 (which coincides with Cloudflare’s announcement of it, and you still have to manually enable it in Firefox), and I still don’t see any usage of it on the networks we monitor. But if I had here is how it would show up in Wireshark.

Wireshark display of ESNI in a client hello

TLS features aren’t the only internet-related improvements to protocols where we’ve seen this long runway; don’t worry, IPv6 is going to be mainstream any day now (RFC 2460, yes they go back that far, is from 1998) – admittedly that comparison is a bit hyperbolic since there’s certainly more of a push to support privacy than an IP assignment scheme that hasn’t been historically necessary.

That said, I don’t think that any of this is reason to completely dismiss the possibility of encrypted client hellos having an impact on security visibility. We should be ready to deal with this possibility in the years to come. Luckily, like most privacy-and-encryption-related improvements (DoH, DoT, TLS 1.3, to name a few), the improvement is designed to fallback to legacy versions/implementations if the client/server doesn’t support it. This means that even if this is implemented ubiquitously there is still a path to preventing it from lessening the security team’s visibility. Specifically, security teams can ensure that enterprise proxies don’t support it (might as well since most of these proxies are downgrading TLS already anyways. They could also choose to block it based on if the extension is present in the traffic. ESNI currently requires DoH to be used in order to work and it’s possible that ECHO may have the same stipulations. Identifying, blocking, and preventing the use of DoH is something else that could be used to deal with the loss of metadata. That btw is the topic of another blog post.

All is not yet lost, and we still have a while until it may be even slightly lost… well, at least with respect to ECHO. I was unable to find a single implementation of ECHO yet, and the extension code (65535) will potentially change before it is seen in the wild. However, in the meantime I’ll be on the lookout for that extension and you should too.

 

Troy Kent
Troy Kent

Threat Researcher