TLS-fingerprinting en JA4-hashes uitgelegd

Elke HTTPS-verbinding begint met een TLS-handshake, en elke TLS-handshake begint met een Client Hello-bericht. Dit bericht bevat een schat aan informatie over de verbindende client — cipher suites, extensies, ondersteunde curves, signature-algoritmen — die sterk varieert tussen browsers, versies en besturingssystemen. TLS-fingerprinting legt deze informatie vast en gebruikt die als identificatiesignaal.

Wat staat er in een Client Hello?

Wanneer een browser verbinding maakt met een HTTPS-server, stuurt hij een Client Hello-bericht met daarin: de TLS-versie die hij ondersteunt, de lijst met cipher suites die hij wil gebruiken, de TLS-extensies die hij meestuurt (zoals SNI, ALPN en key share), de elliptische curves die hij ondersteunt, de signature-algoritmen die hij accepteert en de compressiemethoden die hij aanbiedt.

Elke browserfamilie heeft een kenmerkende fingerprint. Chrome, Firefox en Safari sturen allemaal een andere ordening van cipher suites, andere sets extensies en andere curve-voorkeuren. Zelfs binnen dezelfde browserfamilie kunnen verschillende versies iets andere Client Hello-berichten sturen naarmate cipher suites worden toegevoegd of afgeschaft.

Van JA3 naar JA4

JA3 was de oorspronkelijke TLS-fingerprintinghash, in 2017 geïntroduceerd door Salesforce. Het voegt de TLS-versie, cipher suites, extensies, elliptische curves en EC point-formaten samen tot een string en berekent daar een MD5-hash van. Hoewel baanbrekend, heeft JA3 beperkingen: het produceert één ondoorzichtige hash die moeilijk te analyseren is, en kleine wijzigingen in welk veld dan ook leveren een volledig andere hash op.

JA4, in 2023 geïntroduceerd door FoxIO, verbetert JA3 op verschillende manieren. Het produceert een gestructureerde fingerprint met drie componenten: een leesbare prefix (zoals "t13d1715h2" — TLS 1.3, 17 cipher suites, 15 extensies, HTTP/2), een geordende hash van de cipher suites en een geordende hash van de extensies. Door deze structuur zijn JA4-fingerprints in één oogopslag te analyseren, terwijl de precisie die nodig is voor identificatie behouden blijft.

Waarom TLS-fingerprints belangrijk zijn voor device intelligence

TLS-fingerprints zijn waardevol omdat ze worden verzameld voordat er JavaScript wordt uitgevoerd. Een bot die zijn user agent spooft, zijn canvas-rendering vervalst en zijn navigator-eigenschappen patcht, stuurt nog steeds een echt Client Hello-bericht vanuit welke TLS-bibliotheek hij daadwerkelijk gebruikt. Als de Client Hello "Go's crypto/tls-bibliotheek" zegt maar de user agent "Chrome 124" zegt, weten we dat er iets wordt gespooft.

Deze kruisvalidatie is buitengewoon krachtig voor botdetectie. De meeste automatiseringsframeworks — Selenium, Puppeteer, Playwright — gebruiken de native TLS-stack van de browser, dus hun TLS-fingerprints komen overeen met de browser die ze aansturen. Maar aangepaste HTTP-clients, op Go gebaseerde scrapers en Python-scripts die de requests-bibliotheek gebruiken, hebben allemaal kenmerkende TLS-fingerprints die ze direct identificeren als niet-browserclients.

Stabiliteit van TLS-fingerprints

Een aandachtspunt bij TLS-fingerprinting is de stabiliteit over browserupdates. Wanneer Chrome een cipher suite toevoegt of verwijdert, verandert de TLS-fingerprint. In de praktijk gebeurt dit minder vaak dan je zou verwachten. De lijst met cipher suites van Chrome is relatief stabiel — grote wijzigingen gebeuren een- of tweemaal per jaar, niet bij elke versie.

Het gestructureerde formaat van JA4 helpt hierbij. De leesbare prefix blijft stabiel over kleine versiewijzigingen (het aantal cipher suites en extensies verandert niet vaak), dus zelfs wanneer de gedetailleerde hash verandert, biedt de prefix continuïteit. In ons multi-tier identificatiesysteem worden TLS-fingerprintgegevens in Tier 2 geplaatst — stabiel genoeg om bij te dragen aan identificatie, maar verwerkt via cross-sessie matching om de verwachte drift op te vangen.

Server-side verzameling

Anders dan client-side signalen die JavaScript-uitvoering vereisen, worden TLS-fingerprints volledig server-side verzameld. Onze edge-servers inspecteren de ruwe TLS-handshake en extraheren de Client Hello voordat de verbinding tot stand komt. Dit betekent dat TLS-fingerprinting zelfs werkt wanneer JavaScript geblokkeerd is, wanneer de browser privacy-extensies heeft geïnstalleerd, of wanneer de client helemaal geen browser is.

Dit server-side karakter maakt TLS-fingerprints ook bestand tegen spoofing. Hoewel het theoretisch mogelijk is om een aangepaste TLS Client Hello te maken die een specifieke browser nabootst, vereist dat het op laag niveau implementeren van TLS — veel meer moeite dan het wijzigen van een user agent-string. De meeste spoofingtools proberen dit niet eens.

Integratie met apparaatidentificatie

In onze apparaatidentificatie-engine fungeert de TLS-fingerprint zowel als signaal als validator. Als signaal draagt hij met zijn eigen identificatiegewicht bij aan de totale apparaatfingerprint. Als validator biedt hij een kruiscontrole op de geclaimde browseridentiteit. Als de JavaScript-signalen "Chrome op macOS" zeggen maar de TLS-fingerprint "Firefox op Linux" zegt, activeert de discrepantie een tampering-flag in onze Smart Signals-analyse.