JA4+ is the name FoxIO uses for a family of network fingerprinting methods. JA4 itself is the TLS ClientHello method. It builds on lessons from JA3, but the wider family also contains separate methods for servers, HTTP, certificates, TCP, SSH and other observations.
JA4 and JA4+
JA4 produces an a_b_c value. Its readable a section records selected connection properties and counts. The b and
c sections are truncated SHA-256 values derived from normalised ClientHello fields. Analysts can compare selected
components, such as JA4_ac, when the complete fingerprint is too narrow for the question being asked. Other JA4+
methods have their own inputs and specifications; they should not be treated as extra fields inside core JA4.
JA4+ consists of various components:
- JA4: TLS Client
- JA4S: TLS Server Response
- JA4H: HTTP Client
- JA4L: Light Distance/Location
- JA4X: X509 TLS Certificate
- JA4SSH: SSH Traffic
For a more thorough breakdown, the JA4 blog provides the announcement and describes the fingerprints.
JA4+ brings useful improvements, but a few aspects and quirks deserve closer attention.
What sorting changes
JA4 sorts cipher identifiers and most extension identifiers before hashing them. This was especially useful after Chrome began permuting TLS extension order. Sorting puts those permutations back into one cohort. It also discards the order as evidence. That is the trade-off: a more stable identifier retains less information about how the ClientHello was serialised.
Where investigation matters, retain the raw JA4 form as well as the compact value. JA4_r exposes the normalised
cipher, extension and signature-algorithm lists, which makes a difference easier to inspect.
The overview of TLS fingerprinting provides a more in-depth explanation of how a TLS signature is formed.
Chrome's change was intended to stop servers and middleboxes from depending on one fixed extension order. In our extension-randomisation analysis, the number of order-sensitive TLS fingerprints rose sharply after the rollout. Sorting reduced that artificial fragmentation. It did not make the resulting value a client identity, and it did not preserve every distinction in the original handshake.
JA3 and Mercury took different paths
Before digging further into JA4+'s features and limitations, it helps to separate two related lineages. The original JA3 established a portable TLS fingerprint that was easy to share and match. Cisco Mercury developed a richer protocol representation and a separate destination-context classification system. Mercury is not a predecessor in the JA3-to-JA4 naming line. Our history of the two lineages explains where their work overlaps and where it does not.
Implementation differences still matter
While sharing signatures through SHA is appealing, it has limits, most notably potential compatibility issues. As Fastly noted, differences in the implementation can be hidden behind the SHA hash, causing issues when searching for and correlating signatures between different services. Record the implementation and version that generated a value; a shared format name does not prove that two sensors handled every field identically.
Check the method, implementation and licence
The official JA4+ repository contains the current specifications and implementations. Check the licence for the individual method before adopting it: core JA4 is BSD-3-Clause, while most other JA4+ methods use the FoxIO Licence and place additional conditions on commercial use.
For a field-level example rather than a format summary, our same-ClientHello lab
records JA3, JA4, JA4_r and Mercury NPF output from one packet and pins the implementations that generated them.
