Fingerprinting TLS e hash JA4 spiegati

Ogni connessione HTTPS inizia con un handshake TLS e ogni handshake TLS inizia con un messaggio Client Hello. Questo messaggio contiene una grande quantità di informazioni sul client che si connette — cipher suite, estensioni, curve supportate, algoritmi di firma — che varia in modo significativo tra browser, versioni e sistemi operativi. Il fingerprinting TLS cattura queste informazioni e le usa come segnale di identificazione.

Cosa contiene un Client Hello?

Quando un browser si connette a un server HTTPS, invia un messaggio Client Hello che contiene: la versione TLS supportata, l'elenco delle cipher suite che è disposto a usare, le estensioni TLS che include (come SNI, ALPN e key share), le curve ellittiche supportate, gli algoritmi di firma accettati e i metodi di compressione offerti.

Ogni famiglia di browser ha un fingerprint distintivo. Chrome, Firefox e Safari inviano tutti ordinamenti diversi delle cipher suite, set diversi di estensioni e preferenze diverse sulle curve. Anche all'interno della stessa famiglia di browser, versioni diverse possono inviare messaggi Client Hello leggermente diversi man mano che le cipher suite vengono aggiunte o deprecate.

Da JA3 a JA4

JA3 è stato l'hash originale per il fingerprinting TLS, introdotto da Salesforce nel 2017. Concatena la versione TLS, le cipher suite, le estensioni, le curve ellittiche e i formati dei punti EC in una stringa e ne calcola un hash MD5. Pur essendo rivoluzionario, JA3 ha dei limiti: produce un unico hash opaco difficile da analizzare, e modifiche minori in qualsiasi campo producono un hash completamente diverso.

JA4, introdotto da FoxIO nel 2023, migliora JA3 sotto diversi aspetti. Produce un fingerprint strutturato con tre componenti: un prefisso leggibile (come «t13d1715h2» — TLS 1.3, 17 cipher suite, 15 estensioni, HTTP/2), un hash ordinato delle cipher suite e un hash ordinato delle estensioni. Questa struttura rende i fingerprint JA4 analizzabili a colpo d'occhio pur mantenendo la precisione necessaria per l'identificazione.

Perché i fingerprint TLS contano per la device intelligence

I fingerprint TLS sono preziosi perché vengono raccolti prima che venga eseguito qualsiasi JavaScript. Un bot che falsifica il proprio user agent, finge il rendering del canvas e modifica le proprietà del navigator invia comunque un genuino messaggio Client Hello da qualunque libreria TLS effettivamente utilizzi. Se il Client Hello dice «la libreria crypto/tls di Go» ma lo user agent dice «Chrome 124», sappiamo che qualcosa è stato falsificato.

Questa validazione incrociata è estremamente potente per il rilevamento dei bot. La maggior parte dei framework di automazione — Selenium, Puppeteer, Playwright — usa lo stack TLS nativo del browser, quindi i loro fingerprint TLS corrispondono al browser che controllano. Ma i client HTTP personalizzati, gli scraper basati su Go e gli script Python che usano la libreria requests hanno tutti fingerprint TLS distintivi che li identificano immediatamente come client non-browser.

Stabilità del fingerprint TLS

Una preoccupazione riguardo al fingerprinting TLS è la stabilità tra gli aggiornamenti del browser. Quando Chrome aggiunge o rimuove una cipher suite, il fingerprint TLS cambia. In pratica questo accade meno frequentemente di quanto si potrebbe pensare. L'elenco delle cipher suite di Chrome è relativamente stabile — i cambiamenti importanti avvengono una o due volte l'anno, non a ogni versione.

Il formato strutturato di JA4 aiuta in questo. Il prefisso leggibile resta stabile tra i cambi di versione minori (il conteggio delle cipher suite e delle estensioni non cambia spesso), quindi anche quando l'hash dettagliato cambia, il prefisso fornisce continuità. Nel nostro sistema di identificazione multi-tier, i dati del fingerprint TLS sono collocati nel Tier 2 — abbastanza stabili da contribuire all'identificazione, ma elaborati tramite matching cross-sessione per gestire il drift previsto.

Raccolta lato server

A differenza dei segnali lato client che richiedono l'esecuzione di JavaScript, i fingerprint TLS vengono raccolti interamente lato server. I nostri edge server ispezionano l'handshake TLS grezzo ed estraggono il Client Hello prima che la connessione venga stabilita. Questo significa che il fingerprinting TLS funziona anche quando il JavaScript è bloccato, quando il browser ha estensioni per la privacy installate o quando il client non è affatto un browser.

Questa natura lato server rende inoltre i fingerprint TLS resistenti allo spoofing. Sebbene sia teoricamente possibile costruire un Client Hello TLS personalizzato che imiti uno specifico browser, farlo richiede implementare il TLS a basso livello — uno sforzo di gran lunga superiore a quello di cambiare una stringa user agent. La maggior parte degli strumenti di spoofing non ci prova nemmeno.

Integrazione con Device Identification

Nel nostro motore di identificazione dei dispositivi, il fingerprint TLS funge sia da segnale sia da validatore. Come segnale, contribuisce al fingerprint complessivo del dispositivo con il proprio peso di identificazione. Come validatore, fornisce un controllo incrociato rispetto all'identità del browser dichiarata. Se i segnali JavaScript dicono «Chrome su macOS» ma il fingerprint TLS dice «Firefox su Linux», la discrepanza attiva un flag di manomissione nella nostra analisi Smart Signals.