What is JA3 Fingerprinting?

Back to learning

JA3 is a method for summarising a TLS client's ClientHello. It records five ordered groups of values, serialises them as decimal numbers, then takes the MD5 hash of that string. The result is compact and easy to compare across logs.

It is a fingerprint of an observed TLS handshake, not a unique identifier for a person, device or application. Several programs can use the same TLS library and produce the same JA3. A program can also change its handshake and produce a different one.

How is a JA3 fingerprint calculated?

The canonical JA3 field order is:

SSLVersion,Cipher,SSLExtension,EllipticCurve,EllipticCurvePointFormat

Values inside a field are joined with hyphens and the five fields are joined with commas. The original JA3 specification gives this example:

769,47-53-5-10-49161-49162-49171-49172-50-56-19-4,0-10-11,23-24-25,0

JA3 then applies MD5 to produce a 32-character value. It preserves the advertised order of ciphers and extensions. That order is useful evidence about an implementation, but it also means deliberate or routine reordering changes the hash.

JA3 removes GREASE values before constructing the string. GREASE values therefore do not, by themselves, create a new canonical JA3 fingerprint. This handling is part of the original implementation, not an extension added by later formats.

What can JA3 tell you?

A JA3 can group connections that advertised the same five groups of values in the same order. That is useful for searching captures, correlating events and comparing traffic with a labelled dataset. In a tightly controlled network, an unexpected value may also be worth investigating.

The label attached to a hash matters as much as the hash. A match against a historical malware sample means that the current connection has the same JA3; it does not prove that the current connection is the same malware. Browser automation, shared libraries and deliberate impersonation all create collisions in attribution.

Where does JA3 break down?

• Cipher or extension reordering changes the complete MD5 value.
• MD5 hides which field changed unless the unhashed JA3 string is retained.
• Two handshakes can collide because JA3 only covers selected ClientHello fields.
• TLS stacks and browser releases change, so labels and allowlists drift.
• A client that controls its TLS stack can copy another client's handshake shape.
• A proxy or TLS terminator may be the client visible at the observation point.

JA3 is still useful when existing logs, detections and historical datasets use it. JA4 changes the representation and normalises ordering, while JA3 versus JA4 explains the operational trade-off.