JA4 fingerprint: reading a TLS hello that survives shuffling

JA4 is the successor to JA3, written by the same person, John Althouse, now at FoxIO. Both read the TLS ClientHello a client sends before any page loads. JA3 squeezed it into one opaque MD5; JA4 keeps part of it readable and, more importantly, sorts the lists before hashing. That one change is why JA4 still works on Chrome.

How to read a JA4 fingerprint

FoxIO's technical details use this example:

t13d1516h2_8daaf6152771_b186095e22b6

The first part, t13d1516h2, is plain text. t is TLS over TCP (q for QUIC, d for DTLS). 13 is the highest TLS version offered, here 1.3. d means the client sent a server name, so it was going to a domain; i would be a bare IP. 15 is the number of cipher suites and 16 the number of extensions, both counted with GREASE values left out. h2 is the first and last character of the first ALPN value, so HTTP/2.

The second part is the first 12 characters of a SHA-256 of the cipher suites, sorted in hex order. The third is the same kind of hash over the extensions, sorted, followed by the signature algorithms in the order sent. The server name and ALPN extensions are left out of that hash, because the first part already records them, so one application gets the same third part whether it connects to a domain or an address.

How it works: Its own Chromium

Why sorting matters

Since Chrome 110, Chrome shuffles the order of its ClientHello extensions on every connection (Chrome Platform Status), and it scatters random GREASE values through several fields. A hash that keeps the order, like JA3, sees a new Chrome almost every time. JA4 sorts and drops GREASE, so the shuffle disappears and one Chrome version has one JA4.

That is also what makes JA4 useful for comparison. In our own measurement, Mosaic's engine against Google's Chrome for Testing 153.0.8010.36, same Mac, same minute:

ours     JA4 t13d1518h2_8daaf6152771_4980c97edce0
stock    JA4 t13d1518h2_8daaf6152771_4980c97edce0

Identical: 15 cipher suites, 18 extensions, ALPN h2, the same cipher hash and the same extension hash. Google Chrome 152 on the same machine read t13d1517h2, one extension fewer. A change between Chrome majors shows up in JA4, which is why a JA4 is only compared against a browser of the same major version.

What a site does with it

JA4 does not tell two Chrome users apart, since they send the same hello. It tells a site what software is really connecting, and lets it compare that with what the software says it is. A User-Agent claiming Chrome 153 over a JA4 that belongs to an HTTP library, or to a different Chrome major, is a contradiction read before any JavaScript runs. TLS fingerprinting covers the rest of the handshake checks, HTTP/2 included.

Licensing matters to anyone building on it. JA4 itself is BSD 3-Clause. The rest of the family, JA4S, JA4H, JA4X and the others grouped as JA4+, is under the FoxIO License 1.1, which FoxIO's README describes as permissive for internal use but not for selling it inside a product without an OEM licence.

How Mosaic handles it

We leave the handshake alone. Tesseract Chrome is built from Chromium source, so its JA4 is Chrome's JA4 for the same major version, as the measurement above shows, and there is no per-profile TLS setting to drift from the version a profile claims. When the engine moves to a new Chrome major, the JA4 moves with it, the way Chrome's does. Mosaic's detection tests include a JA3/JA4 echo page for reading a profile's handshake, and why we built our own Chromium explains why we patch values in the engine rather than in the network layer.