JA3, JA4, and TLS Fingerprinting for Fraud Teams

Before a single HTTP header is sent, the client has already described itself. The TLS ClientHello carries a specific ordering of cipher suites, extensions, elliptic curves, and signature algorithms — and that combination is a property of the TLS library that built it, not of any string the application chose to send.

That is what makes it interesting for fraud work. A user agent is a claim. A TLS fingerprint is a consequence. When the two disagree, you have learned something the client did not intend to tell you.

This is a reference rather than a pitch: what these fingerprints capture, where they fail, and the narrow set of jobs they do well.

What JA3 was, and why it stopped working

JA3, published by Salesforce researchers in 2017, hashes five fields out of the ClientHello — TLS version, cipher suites, extensions, elliptic curves, and point formats — into a single MD5 digest. Simple, cheap, and for several years genuinely effective.

Two things eroded it. First, GREASE (RFC 8701) injects deliberately random values into these lists so that middleboxes cannot ossify around fixed sets; implementations must filter GREASE values or the hash changes constantly. Second, and decisively, Chrome began randomizing ClientHello extension order in 2023. Because JA3 hashes extensions in the order they appear, a browser that reorders them per connection produces a different JA3 every time.

The result is that JA3 values for modern Chromium clients are unstable by design. Blocklists keyed on specific JA3 hashes quietly stopped matching, and plenty of stacks are still carrying rules that have not fired in two years.

What JA4 changed

JA4, from FoxIO, is the direct response. Two design choices matter for anyone deciding whether to adopt it.

• Sorted, not ordered. Ciphers and extensions are sorted before hashing, so extension-order randomization no longer changes the output. This is the fix that makes the fingerprint stable again.
• Human-readable structure. Instead of one opaque MD5, a JA4 string exposes its components: transport, TLS version, whether SNI was present, cipher and extension counts, ALPN, then truncated hashes of the sorted cipher and extension lists. You can read a JA4 and reason about it, which matters enormously during incident response.

The JA4+ family

JA4 is one member of a set, and the others are frequently more useful than the TLS fingerprint alone.

Licensing, before you build on it

This trips teams up at the worst moment. The core JA4 TLS client fingerprint is published under a permissive BSD-style licence, but several other methods in the JA4+ family carry FoxIO's own licence, which places conditions on redistributing them inside a commercial product.

Using them internally is generally fine. Shipping them as a feature you sell is the case that needs a read. Check the current terms for the specific methods you plan to use before they end up in a release — retrofitting a licence decision into a shipped detection pipeline is not a pleasant week.

The honest limits

TLS fingerprints are frequently oversold. Three constraints decide whether they are useful in your architecture.

• Low entropy on its own. Hundreds of millions of people run the same Chrome build on the same platform and produce the same JA4. It identifies a *stack*, never a person. As an identifier it is close to worthless; as a consistency check it is excellent.
• TLS termination hides the client. If traffic reaches you through a CDN or reverse proxy that terminates TLS, you see that intermediary's fingerprint. You need the fingerprint captured at the true edge and forwarded, or you are fingerprinting your own infrastructure.
• Deliberate impersonation exists. Tooling built specifically to reproduce browser TLS fingerprints is mature and freely available. A determined operator can present a convincing browser JA4 from a script. This raises their cost; it does not stop them.

What it is genuinely good at: contradictions

Given those limits, the value is not identification. It is cross-layer consistency. A client is asserting things at several layers simultaneously, and those assertions have to agree.

• A user agent claiming Safari on macOS, presenting a JA4 that only Chromium produces.
• A request claiming a current browser version, presenting the cipher list of a build from three years ago.
• A residential IP — clean by every reputation measure — presenting the TLS signature of a Python or Go HTTP client. The address says home broadband; the stack says script. That contradiction is the single most useful thing a TLS fingerprint tells a fraud team.
• HTTP/2 settings and header ordering that do not match the browser the ClientHello implies. This is where JA4H earns its place.

How it fits with network signals

TLS fingerprinting sits above the network layer and answers a question IP intelligence cannot: what software is on the other end. IP intelligence answers what network it is using. Neither substitutes for the other, and the interesting cases are where they disagree.

A residential address carries little inherent risk on its own — that is precisely why residential proxy networks are worth paying for. Add a TLS fingerprint that no consumer browser produces, and the picture inverts. The address stops being reassuring and becomes evidence of effort.

The practical pattern is to treat the fingerprint as one input alongside tunnel detection, datacenter classification, and device-level signals, then let the combination drive the verdict. A contradiction between layers should raise risk; agreement across layers should lower it. Neither should decide alone.

If you are starting from nothing

Capture JA4 and JA4H at your true edge and log them next to the user agent and the IP verdict. Do not write blocking rules yet. Spend a couple of weeks looking at which combinations appear together in traffic you already know was fraudulent.

The contradictions will be obvious once you can see both layers in one place, and the rules will write themselves. Starting with a downloaded blocklist of hashes, by contrast, mostly teaches you that JA3 stopped being stable in 2023.

Go deeper

• AI agent traffic: telling assistants from attackers
• Device fingerprinting vs IP intelligence
• Headless browser detection in 2026

See the contradiction, not just the claim

Network, tunnel, and device signals in one server-side verdict.

Try Sentinel free →