JA3 and JA4 fingerprinting is the control that identifies client software from the shape of its TLS handshake rather than its address. Whether it still tells attacker tooling apart from real browsers once traffic climbs is what a DDoS test measures. Both are behavioral Layer 7 signals: they turn the first packet of an encrypted connection into a short string that names the library on the other end.
How the fingerprint is built
Before any application data flows, a TLS client sends a ClientHello that advertises what it supports: the TLS versions, the ordered list of cipher suites, the extensions, the elliptic curves, and the EC point formats. Different software populates those fields differently, and the differences are stable per library. JA3, published by Salesforce engineers in 2017, concatenates five of those fields and takes an MD5 hash, producing a 32-character fingerprint. A companion, JA3S, does the same for the server's ServerHello. A curl build, a Go HTTP client, a python requests session, and a real Chrome each carry a recognizably different value, so the fingerprint identifies the tool without ever seeing a source IP or a decrypted payload.
JA4, released by John Althouse in 2023, exists because JA3 grew brittle. When Chrome began randomizing the order of its ClientHello extensions that year, JA3's hash of the raw order changed on every connection, so a single browser no longer had one fingerprint. JA4 sorts the cipher and extension lists before hashing, so shuffling does not move the value, and it is human-readable rather than an opaque MD5. It is part of a wider JA4+ suite that fingerprints other parts of a session, not TLS alone.
Why it matters under attack
Fingerprinting is a behavioral control, not a threshold on a counter, so it fails differently from a rate limit. It does not care how fast a client sends; it cares what the client is. That makes it useful against an application-layer flood built on scripted tooling, because a million requests from hping-style clients all share one telltale fingerprint even when they arrive from a scattered botnet with clean IP reputation. Blocking by address does nothing there; blocking by fingerprint drops the whole campaign in one rule.
The weakness is symmetric. An adaptive attacker who controls the client can rotate cipher ordering, extensions, and TLS parameters to shift the fingerprint deliberately, and mature tooling now mimics a real browser's ClientHello outright. A defense tuned against a static allowlist of known-bad hashes is then blind, because the traffic wears a fingerprint the allowlist has never seen.
What a DDoS test measures
A test probes the detection boundary rather than a rate: it drives traffic whose fingerprint is varied on purpose and watches where the control still recognizes tooling and where it stops. The question worth answering is whether the fingerprinting rules were tuned against the observed fingerprint space, including clients that impersonate browsers, or only against a handful of well-known signatures that any current tool avoids.
It also checks the failure mode. Does an unrecognized fingerprint default to pass or to challenge, and does that default hold when the volume of unfamiliar handshakes rises? Where behavioral L7 controls sit alongside the volumetric and protocol layers is worked through in Application-Layer (L7) DDoS Testing.