Was ist JA4-TLS-Fingerprinting, und was sagt es wirklich aus?

Das Erste, was ein Client sendet, ist kein Header. Es ist ein TLS Client Hello: eine Liste unterstützter Cipher Suites, die gewünschten Extensions, die akzeptierten Protokollversionen und das Anwendungsprotokoll, das er sprechen möchte. All das kommt im Klartext an, vor jeder Request-Zeile, vor jedem User-Agent. Ein JA4-Fingerabdruck ist eine kompakte Zusammenfassung dieser Nachricht, und interessant ist er aus einem Grund: Der Client hat ihn nicht als Aussage über sich selbst gewählt. Er ergibt sich aus der TLS-Bibliothek, auf der der Client gebaut wurde.

Damit ist er ein anderer Typ Signal als alles in der HTTP-Schicht. Ein User-Agent ist ein Satz, den der Client schreibt. Ein JA4-Fingerabdruck kommt eher einem Akzent nahe.

Die Zeichenkette lesen

Ein JA4-Wert besteht aus drei Teilen, getrennt durch Unterstriche:

t13d1516h2_8daaf6152771_b186095e22b6

Der erste Teil ist ohne Nachschlagen lesbar. t steht für TCP, ein q an dieser Stelle stünde für QUIC. 13 ist TLS 1.3. d sagt, dass eine SNI vorhanden war, der Client also nach einer Domain gefragt hat statt sich zu einer nackten IP zu verbinden. 15 ist die Zahl der angebotenen Cipher Suites, 16 die der Extensions. h2 ist der ALPN-Wert, dieser Client wollte also HTTP/2.

Der zweite Teil ist ein gekürzter Hash der sortierten Cipher-Liste. Der dritte deckt die Extensions und die Signaturalgorithmen ab, ebenfalls sortiert. GREASE-Werte, also die absichtlich eingestreuten Platzhalter, mit denen Browser Middleboxen ehrlich halten, werden vorher entfernt.

Sortieren klingt nach einem Detail. Es ist der ganze Grund, warum es das Format gibt.

Warum JA3 nicht mehr funktionierte

JA3, der Vorgänger von 2017, hashte dieselben Felder in ihrer Reihenfolge auf der Leitung. Das ging gut, solange TLS-Stacks berechenbar waren. Anfang 2023 führte Chrome dann Extension Permutation ein, mischte die Reihenfolge der Extensions im Client Hello bei jeder Verbindung, und eine einzige Chrome-Installation produzierte plötzlich pro Anfrage einen anderen JA3-Hash. Regeln, die auf JA3-Allowlists beruhten, wurden innerhalb eines Release-Zyklus von präzise zu nutzlos.

JA4 sortiert vor dem Hashen, Umsortieren ändert also nichts. Zusätzlich bleibt das lesbare Präfix außerhalb des Hashes, sodass Sie eine QUIC- von einer TCP-Verbindung unterscheiden oder einen Client mit nur drei Cipher Suites erkennen können, ohne eine Datenbank bekannter Werte. Der Rest der JA4+-Familie deckt andere Schichten ab: JA4H für HTTP-Header, JA4T für TCP-Optionen, JA4S für die Antwort des Servers. Die meiste Erkennungsarbeit läuft über die TLS-Variante.

Was er erkennt

Ehrlich gesagt: JA4 ist sehr gut darin, Clients zu erwischen, die nie versucht haben, sich anzupassen.

Ein Python-Skript mit requests erzeugt ein Client Hello, das kein Browser erzeugt. Der Standard-Transport von Go in net/http hat seine eigene erkennbare Form. curl ebenso, ein altes OpenSSL-Build ebenso, und der HTTP-Client in den meisten SDKs auch. Nichts davon versteckt sich, es ist schlicht, was es ist, und der Fingerabdruck sagt das auch dann, wenn sich die Anfrage als Chrome 141 auf macOS ausgibt.

Genau diese Diskrepanz ist der nützliche Teil. Für sich genommen sagt ein Fingerabdruck eines Go-HTTP-Clients nichts Schlechtes aus. Zusammen mit einem User-Agent, der einen Browser behauptet, sagt er Ihnen, dass der Client sich falsch beschreibt, und die Gründe dafür sind meist nicht harmlos.

Für Headless-Browser gilt dasselbe, nur schwächer. Ein echtes Chrome-Build und ein von Playwright gesteuertes Chrome teilen sich den TLS-Stack, ihre JA4-Werte stimmen also überein. Unterscheiden lassen sie sich woanders: am webdriver-Flag, an fehlenden Browser-Schnittstellen, am Timing der Anfragen und daran, ob der Client je die Stylesheets und Schriften lädt, die ein Browser laden würde. Deshalb ist der Fingerabdruck ein Eingangswert und kein Urteil, ein Punkt, der auch in den besten Signalen für Bot-Erkennung auftauchte.

Wo er aufhört, ein Beweis zu sein

Zwei Grenzen zählen, und beide werden in Anbieterprosa gern überblättert.

Ein Fingerabdruck ist eine Gruppe, keine Identität. Jedes Chrome 141 unter Windows sendet praktisch dasselbe Client Hello. Das sind Millionen Menschen mit einer gemeinsamen Zeichenkette. Sie können sagen "diese Verbindung kam von etwas in der Form von Chrome 141", aber über das Wer sagen Sie gar nichts. Wer einen JA4-Wert als Besucherkennung behandelt, liegt ständig daneben, und zwar in beide Richtungen.

Fingerabdrücke sind kopierbar. Mit uTLS kann ein Go-Programm ein Client Hello senden, das byte-identisch zu einer gewählten Chrome-Version ist. curl-impersonate leistet dasselbe für curl. Wer motiviert genug ist, einen Blogbeitrag zu lesen, bringt seinen Scraper dazu, einen völlig unauffälligen Browser-Fingerabdruck zu zeigen. Was das kostet, ist Aufwand, und Aufwand ist ein echter Filter: Der Unterschied zwischen einem Skript, das sich die Mühe gemacht hat, und einem, das es nicht tat, macht den Großteil der Automatisierung im Netz aus. Ein entschlossener Betreiber kommt an diesem Signal jedoch vorbei, also lässt alles, was allein auf JA4 beruht, ihn durch.

Es gibt ein drittes, leiseres Problem. Unternehmens-Proxys mit TLS-Inspektion schreiben das Client Hello um, alle Mitarbeitenden dahinter teilen also den Fingerabdruck des Proxys statt den ihres Browsers. Wer auf einen Fingerabdruck hin blockiert, kann eine ganze Firma auf einmal verlieren.

Der Einsatz neben den anderen Signalen

Was sich bewährt, ist Stapeln, nicht Ranken. Jedes Signal beantwortet eine andere Frage:

Lesen Sie die Spalte "Versagt, wenn" von oben nach unten, dann wird der Punkt offensichtlich: Die Umgehungen sind für jede Zeile andere. Eine zu schlagen ist leicht, alle fünf gleichzeitig ist ein Projekt. Eine Rechenzentrums-IP plus ein Go-Fingerabdruck plus ein Chrome-User-Agent ist nicht mehrdeutig. Eine Residential-IP mit echtem Chrome-Fingerabdruck und ohne Headless-Spuren ist wahrscheinlich ein Mensch und sollte auch so behandelt werden.

Nach dieser Logik arbeitet Agentscan. Ein POST liefert eine Klasse zurück, human, known_bot, ai_agent oder malicious_automation, dazu einen Confidence-Wert und die zugrunde liegenden Signale, JA4 darunter. Gecachte Verdicts kommen in unter 50ms zurück, und genau das erlaubt es, die Prüfung in einen Middleware-Hop zu legen statt in eine Log-Auswertung am nächsten Morgen.

Eine praktikable Policy

1. Holen Sie den Fingerabdruck dort ab, wo TLS terminiert. Anwendungscode sieht das Client Hello nie. Er kommt von Ihrem CDN, Ihrem Load Balancer oder einer vorgeschalteten Detection-API.
2. Bewerten Sie die Diskrepanz, nicht den Fingerabdruck. Das Signal lautet "TLS-Stack passt nicht zum behaupteten Browser", nicht "dieser Hash ist schlecht". Eine Blockliste von Hashes zu pflegen altert schlecht, denn jedes Browser-Release bringt neue hervor.
3. Lassen Sie ihn nie allein entscheiden. Kombinieren Sie ihn mindestens mit der Herkunft. Für sich erwischt er einen Unternehmens-Proxy und verpasst einen fähigen Scraper, also zweimal das falsche Ergebnis.
4. Rechnen Sie mit Bewegung in den Werten. Browser-Updates verändern Cipher- und Extension-Sätze. Was Sie heute festschreiben, braucht einen Review-Termin, sonst flaggt es irgendwann still echte Nutzer.
5. Loggen Sie ihn in jedem Fall. Auch wenn Sie nicht darauf reagieren: Den JA4 pro Anfrage zu speichern macht den nächsten Vorfall lesbar. Zu sehen, dass 40.000 Anfragen einen ungewöhnlichen Fingerabdruck teilten, ist ein deutlich schnellerer Einstieg als rohe Logs zu lesen.

Fazit

JA4 sagt Ihnen, wie ein Client TLS spricht. Das ist schwerer beiläufig zu fälschen als jeder Header und leichter absichtlich zu fälschen, als die meisten Anbieter zugeben. Er ist ein starkes Signal über die Form der Software am anderen Ende, ein schwaches über die Absicht und gar keines über die Identität. Nutzen Sie ihn, um die Automatisierung zu erwischen, die nie versucht hat, menschlich auszusehen, stapeln Sie ihn mit IP-Herkunft und Headless-Markern für die, die es versucht hat, und bauen Sie keine Blockierregel, die allein auf ihm ruht.