Recent changes to the behavior of major browsers have rendered the popular JA3 fingerprinting technique nearly useless in its ability to uniquely identify a client. Network security monitoring tools that rely on JA3 better adapt quickly.
JA3 is a widely-used technique for creating SSL/TLS client application fingerprints which can subsequently be used -- in conjunction with its server-side counterpart JA3s -- to identify unusual or abnormal client interaction with applications. It underpins the encrypted traffic analysis functionality of many intrusion detection (IDS), network security monitoring (NSM), and network detection and response (NDR) systems.
JA3 was originally developed by Salesforce researchers in 2017. To read more about JA3 and Ja3s, see this post by its original creator John Althouse https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967/. Sidenote: John Althouse currently maintains the latest in TLS client and server fingerprinting technology at FoxIO-LLC.
The JA3 computation derives the fingerprint by picking various elements of the TLS client hello (ClientHello) message and building a string. One of the elements is the TLS extension list. Extensions are used to convey things like the protocol versions and cryptographic parameters supported by the client. The JA3 algorithm takes all the extensions announced in the message and concatenates them in a string (separated with dashes) in sequential order of their appearance in the ClientHello message.
Because most applications present the same extensions consistently in the TLS ClientHello message, this technique has worked well for a few years. But in early 2023 new versions of the Chrome browser began randomizing the order in which extensions are issued in the client Hello message. Other browser and client implementations are also adopting this same change.
So at every connection, the order of the TLS extensions is changed. As a result, the computation of the extensions list in JA3 returns different results for every connection, and thus the JA3 fingerprint changes.
The Chrome team explains that by using randomization they will force all server implementation to respect RFC 8446 (see https://chromestatus.com/feature/5124606246518784) and will “reduce the risk of server and middleboxes fixating on details of our current ClientHello. This should make the TLS ecosystem more robust to changes.”
This new implementation does, indeed, conform to the RFC as only one of the TLS extensions parameters is required to be in a fixed position. But if we look at a sample we extracted from internet traffic, we observe a single client application announcing 16 TLS extensions and randomizing them. This means 16! = 20922789888000 different JA3 hashes for this agent.
So, because of this, JA3 has been rendered useless for identifying clients and user agents. TLS implementations that use fixed extension ordering will still have a single JA3 hash value and will continue to be detected, but there is no direct link between a single JA3 and a set of agents as one agent can now have billions of JA3.
Here’s a recent blog post by fastly on the subject: https://www.fastly.com/blog/a-first-look-at-chromes-tls-clienthello-permutation-in-the-wild
Because randomization is a reasonably-effective evasion technique, we can bet it is going to be adopted by malware authors, too. Defenders need to move to something else. Attentive readers are going to say that it is just enough to order the TLS extensions (which are integers) when building the fingerprint to fix the situation. It will indeed fix the issue but it will also limit the capacity of the resulting fingerprints to separate implementations (that are not using randomization). But TLS extensions are among the few pieces of information that are really interesting and distinctive, so we do not really want to drop them from a fingerprint. And, while keeping them in a fixed order reduces entropy, it is better than removing them from the fingerprint computation.
FoxIO-LLC has proposed a new fingerprinting technique named JA4 that, among other things, is resistant to the randomization and incorporates some other useful dimensions like Application Layer Protocol Negotiation that were not part of JA3. JA4 also covers the increasingly popular QUIC transport layer protocol.
While the JA4 client for TLS and QUIC is released under an open BSD-like license (https://github.com/FoxIO-LLC/ja4/blob/main/LICENSE-JA4), FoxIO-LLC is selling other fingerprint techniques under a commercial license. This is definitely weird on the licensing side as this is code that is being licensed and not an algorithm. In Europe at least, where software patents are officially forbidden, this looks awkward and could become a challenge for their widespread adoption.
Weirdness aside, adoption of JA4 as a more powerful TLS client fingerprinting technique is growing. And several open source software systems such as Suricata are working to incorporate it, even if the license issue/weirdness is slowing things down.