TLS-Fingerprinting und JA4-Hashes erklärt

Jede HTTPS-Verbindung beginnt mit einem TLS-Handshake, und jeder TLS-Handshake beginnt mit einer Client-Hello-Nachricht. Diese Nachricht enthält eine Fülle von Informationen über den sich verbindenden Client — Cipher Suites, Erweiterungen, unterstützte Kurven, Signaturalgorithmen — die über Browser, Versionen und Betriebssysteme hinweg erheblich variieren. TLS-Fingerprinting erfasst diese Informationen und nutzt sie als Identifikationssignal.

Was steckt in einem Client Hello?

Wenn ein Browser sich mit einem HTTPS-Server verbindet, sendet er eine Client-Hello-Nachricht, die Folgendes enthält: die TLS-Version, die er unterstützt, die Liste der Cipher Suites, die er zu verwenden bereit ist, die TLS-Erweiterungen, die er einschließt (wie SNI, ALPN und Key Share), die elliptischen Kurven, die er unterstützt, die Signaturalgorithmen, die er akzeptiert, und die Kompressionsmethoden, die er anbietet.

Jede Browser-Familie hat einen unterscheidungskräftigen Fingerprint. Chrome, Firefox und Safari senden allesamt unterschiedliche Cipher-Suite-Reihenfolgen, unterschiedliche Erweiterungssätze und unterschiedliche Kurvenpräferenzen. Selbst innerhalb derselben Browser-Familie können verschiedene Versionen leicht unterschiedliche Client-Hello-Nachrichten senden, während Cipher Suites hinzugefügt oder abgekündigt werden.

Von JA3 zu JA4

JA3 war der ursprüngliche TLS-Fingerprinting-Hash, 2017 von Salesforce eingeführt. Er verkettet die TLS-Version, Cipher Suites, Erweiterungen, elliptischen Kurven und EC-Punktformate zu einem String und berechnet einen MD5-Hash. Obwohl bahnbrechend, hat JA3 Grenzen: Er produziert einen einzelnen, undurchsichtigen Hash, der schwer zu analysieren ist, und geringfügige Änderungen in einem beliebigen Feld erzeugen einen völlig anderen Hash.

JA4, 2023 von FoxIO eingeführt, verbessert JA3 in mehrfacher Hinsicht. Er produziert einen strukturierten Fingerprint mit drei Komponenten: einem menschenlesbaren Präfix (wie „t13d1715h2" — TLS 1.3, 17 Cipher Suites, 15 Erweiterungen, HTTP/2), einem geordneten Hash der Cipher Suites und einem geordneten Hash der Erweiterungen. Diese Struktur macht JA4-Fingerprints auf einen Blick analysierbar und behält gleichzeitig die für die Identifikation nötige Präzision bei.

Warum TLS-Fingerprints für Device Intelligence wichtig sind

TLS-Fingerprints sind wertvoll, weil sie erfasst werden, bevor JavaScript ausgeführt wird. Ein Bot, der seinen User Agent fälscht, sein Canvas-Rendering vortäuscht und seine navigator-Eigenschaften patcht, sendet dennoch eine echte Client-Hello-Nachricht von der TLS-Bibliothek, die er tatsächlich verwendet. Wenn das Client Hello „Go's crypto/tls library" sagt, der User Agent aber „Chrome 124", wissen wir, dass etwas gefälscht wird.

Diese Kreuzvalidierung ist für die Bot-Erkennung äußerst wirkungsvoll. Die meisten Automatisierungsframeworks — Selenium, Puppeteer, Playwright — verwenden den nativen TLS-Stack des Browsers, sodass ihre TLS-Fingerprints zu dem Browser passen, den sie steuern. Aber benutzerdefinierte HTTP-Clients, Go-basierte Scraper und Python-Skripte, die die requests-Bibliothek verwenden, haben allesamt unterscheidungskräftige TLS-Fingerprints, die sie sofort als Nicht-Browser-Clients identifizieren.

TLS-Fingerprint-Stabilität

Ein Bedenken beim TLS-Fingerprinting ist die Stabilität über Browser-Updates hinweg. Wenn Chrome eine Cipher Suite hinzufügt oder entfernt, ändert sich der TLS-Fingerprint. In der Praxis geschieht dies seltener, als Sie erwarten könnten. Die Cipher-Suite-Liste von Chrome ist relativ stabil — größere Änderungen erfolgen ein- oder zweimal pro Jahr, nicht mit jeder Version.

Das strukturierte Format von JA4 hilft hier. Das menschenlesbare Präfix bleibt über kleinere Versionsänderungen hinweg stabil (die Anzahl der Cipher Suites und Erweiterungen ändert sich nicht oft), sodass selbst dann, wenn sich der detaillierte Hash ändert, das Präfix Kontinuität bietet. In unserem Mehrstufen-Identifikationssystem werden TLS-Fingerprint-Daten in Stufe 2 platziert — stabil genug, um zur Identifikation beizutragen, aber durch sitzungsübergreifendes Matching verarbeitet, um erwartete Drift zu behandeln.

Serverseitige Erfassung

Anders als clientseitige Signale, die eine JavaScript-Ausführung erfordern, werden TLS-Fingerprints vollständig serverseitig erfasst. Unsere Edge-Server inspizieren den rohen TLS-Handshake und extrahieren das Client Hello, bevor die Verbindung aufgebaut wird. Das bedeutet, dass TLS-Fingerprinting auch dann funktioniert, wenn JavaScript blockiert ist, wenn der Browser Privatsphäre-Erweiterungen installiert hat oder wenn der Client überhaupt kein Browser ist.

Diese serverseitige Natur macht TLS-Fingerprints zudem resistent gegen Spoofing. Obwohl es theoretisch möglich ist, ein benutzerdefiniertes TLS Client Hello zu erstellen, das einen bestimmten Browser nachahmt, erfordert dies die Implementierung von TLS auf niedriger Ebene — weitaus mehr Aufwand, als einen User-Agent-String zu ändern. Die meisten Spoofing-Werkzeuge versuchen es nicht.

Integration mit der Geräteidentifikation

In unserer Geräteidentifikations-Engine dient der TLS-Fingerprint sowohl als Signal als auch als Validator. Als Signal trägt er mit seinem eigenen Identifikationsgewicht zum gesamten Device-Fingerprint bei. Als Validator liefert er eine Gegenprobe zur behaupteten Browser-Identität. Wenn die JavaScript-Signale „Chrome auf macOS" sagen, der TLS-Fingerprint aber „Firefox auf Linux", löst die Diskrepanz ein Manipulations-Flag in unserer Smart-Signals-Analyse aus.