JA3 vs JA4 TLS fingerprinting, and what a proxy changes

Originally published on proxymint.

JA3 vs JA4 TLS fingerprints compared field by field: why Chrome's extension shuffle broke JA3, how JA4 stays stable, and what a proxy changes.

TL;DR

• JA3 and JA4 both fingerprint the TLS ClientHello. JA3 hashes five fields in the order sent with MD5, while JA4 sorts ciphers and extensions into a readable a_b_c string.
• Chrome's extension shuffle broke JA3 for browsers. Since January 2023 Chrome has randomized extension order on each connection, about 10^12 orderings, so practically every connection gets its own JA3.
• JA4 is more stable, not strictly better. JA3 still gives one stable hash for clients that send a fixed order, and a match on either fingerprint is evidence, not proof of who is connecting.
• A tunnelling proxy leaves the TLS fingerprint alone. The client's TLS library builds the ClientHello, and the proxy exit owns only the IP, the ASN and the TCP fingerprint.

Key takeaways

• Capture your own JA3 and JA4 before choosing a tier. Record the ClientHello on a server you control and compare the script with a real browser on the same machine.
• Match the handshake to the claim. If the User-Agent says Chrome, the TLS, HTTP/2 settings and header order all have to be Chrome's; otherwise send an honest User-Agent.
• Do not change proxy tier to fix a TLS problem. No tier, mobile or residential, changes the handshake a script sends.
• Keep the client current. JA4 fingerprints change as TLS libraries are updated, so a pinned old build drifts away from what real users send.

Read the full guide on proxymint, with the commands, tables and sources.