Fingerprinting TLS și hash-urile JA4 explicate

Fiecare conexiune HTTPS începe cu un handshake TLS, iar fiecare handshake TLS începe cu un mesaj Client Hello. Acest mesaj conține o mulțime de informații despre clientul care se conectează — cipher suite-uri, extensii, curbe suportate, algoritmi de semnătură — care variază semnificativ între browsere, versiuni și sisteme de operare. Fingerprinting-ul TLS captează aceste informații și le folosește ca semnal de identificare.

Ce conține un Client Hello?

Când un browser se conectează la un server HTTPS, trimite un mesaj Client Hello care conține: versiunea TLS pe care o suportă, lista de cipher suite-uri pe care este dispus să le folosească, extensiile TLS pe care le include (precum SNI, ALPN și key share), curbele eliptice pe care le suportă, algoritmii de semnătură pe care îi acceptă și metodele de compresie pe care le oferă.

Fiecare familie de browsere are o amprentă distinctivă. Chrome, Firefox și Safari trimit toate ordini diferite ale cipher suite-urilor, seturi diferite de extensii și preferințe diferite de curbe. Chiar și în cadrul aceleiași familii de browsere, versiuni diferite pot trimite mesaje Client Hello ușor diferite, pe măsură ce cipher suite-urile sunt adăugate sau depreciate.

De la JA3 la JA4

JA3 a fost hash-ul original de fingerprinting TLS, introdus de Salesforce în 2017. Concatenează versiunea TLS, cipher suite-urile, extensiile, curbele eliptice și formatele de puncte EC într-un șir de caractere și calculează un hash MD5. Deși revoluționar, JA3 are limitări: produce un singur hash opac care este dificil de analizat, iar modificări minore în oricare câmp produc un hash complet diferit.

JA4, introdus de FoxIO în 2023, îmbunătățește JA3 în mai multe privințe. Produce o amprentă structurată cu trei componente: un prefix lizibil (precum „t13d1715h2” — TLS 1.3, 17 cipher suite-uri, 15 extensii, HTTP/2), un hash ordonat al cipher suite-urilor și un hash ordonat al extensiilor. Această structură face amprentele JA4 analizabile dintr-o privire, menținând în același timp precizia necesară pentru identificare.

De ce contează amprentele TLS pentru device intelligence

Amprentele TLS sunt valoroase pentru că sunt colectate înainte ca vreun JavaScript să se execute. Un bot care își falsifică user agent-ul, își simulează randarea canvas și își modifică proprietățile navigatorului tot trimite un mesaj Client Hello autentic de la orice bibliotecă TLS pe care o folosește de fapt. Dacă Client Hello spune „biblioteca crypto/tls a Go”, dar user agent-ul spune „Chrome 124”, știm că ceva este falsificat.

Această validare încrucișată este extrem de puternică pentru detectarea boților. Majoritatea framework-urilor de automatizare — Selenium, Puppeteer, Playwright — folosesc stiva TLS nativă a browserului, așa că amprentele lor TLS se potrivesc cu browserul pe care îl controlează. Dar clienții HTTP personalizați, scraperele bazate pe Go și scripturile Python care folosesc biblioteca requests au toate amprente TLS distinctive care le identifică imediat drept clienți care nu sunt browsere.

Stabilitatea amprentelor TLS

O preocupare legată de fingerprinting-ul TLS este stabilitatea între actualizările de browser. Când Chrome adaugă sau elimină un cipher suite, amprenta TLS se schimbă. În practică, acest lucru se întâmplă mai rar decât ai putea crede. Lista de cipher suite-uri a Chrome este relativ stabilă — schimbările majore au loc o dată sau de două ori pe an, nu cu fiecare versiune.

Formatul structurat al JA4 ajută aici. Prefixul lizibil rămâne stabil între schimbările de versiune minore (numărul de cipher suite-uri și de extensii nu se schimbă des), așa că, chiar și atunci când hash-ul detaliat se schimbă, prefixul asigură continuitatea. În sistemul nostru de identificare pe mai multe niveluri, datele amprentei TLS sunt plasate în nivelul 2 — suficient de stabile pentru a contribui la identificare, dar procesate prin potrivire între sesiuni pentru a gestiona derapajul așteptat.

Colectarea pe partea de server

Spre deosebire de semnalele de pe partea de client care necesită execuția JavaScript, amprentele TLS sunt colectate integral pe partea de server. Serverele noastre edge inspectează handshake-ul TLS brut și extrag Client Hello înainte de stabilirea conexiunii. Asta înseamnă că fingerprinting-ul TLS funcționează chiar și când JavaScript este blocat, când browserul are extensii de confidențialitate instalate sau când clientul nu este deloc un browser.

Această natură de pe partea de server face amprentele TLS și rezistente la spoofing. Deși este teoretic posibil să construiești un Client Hello TLS personalizat care imită un browser specific, a face acest lucru necesită implementarea TLS la un nivel scăzut — mult mai mult efort decât schimbarea unui șir de user agent. Majoritatea instrumentelor de spoofing nici nu încearcă.

Integrarea cu identificarea dispozitivelor

În motorul nostru de identificare a dispozitivelor, amprenta TLS servește atât ca semnal, cât și ca validator. Ca semnal, contribuie la amprenta generală a dispozitivului cu propria pondere de identificare. Ca validator, oferă o verificare încrucișată față de identitatea declarată a browserului. Dacă semnalele JavaScript spun „Chrome pe macOS”, dar amprenta TLS spune „Firefox pe Linux”, discrepanța declanșează un indicator de manipulare în analiza noastră Smart Signals.