Due presentazioni prima che parta qualsiasi script
Tutto ciò che si scrive sul fingerprinting del browser riguarda cose che una pagina può misurare: canvas, WebGL, font, dimensioni dello schermo. Tutto avviene dopo che la connessione è stabilita.
A quel punto il tuo client ha già fatto due dichiarazioni su di sé che non può ritirare. Il ClientHello TLS annuncia quali suite di cifratura, estensioni, curve ellittiche e protocolli ALPN supporta, e in che ordine. Il preambolo HTTP/2 annuncia i valori del suo frame SETTINGS, la dimensione dell'aggiornamento di finestra e l'ordine in cui invia gli pseudo-campi dell'intestazione.
Nessuna delle due è un'affermazione sull'identità. Entrambe sono una conseguenza di quale libreria TLS e quale stack HTTP sono stati compilati nel binario. Ed è proprio questo a renderle utili a un fornitore di sistemi di rilevamento: una stringa user agent è una frase che chiunque può digitare, un ClientHello è una struttura di cui devi essere davvero fatto.
JA3, e perché Chrome l'ha rotto
JA3, pubblicato da Salesforce nel 2017, prende cinque campi dal ClientHello — versione TLS, suite di cifratura, estensioni, curve ellittiche e formati delle curve — li concatena nell'ordine in cui viaggiano sul filo e ne calcola l'MD5. Il risultato è un hash di 32 caratteri stabile per una data build di client.
Ha funzionato bene per sei anni, poi Chrome l'ha ucciso. In Chrome 110, uscito a gennaio 2023, Google ha iniziato a randomizzare l'ordine delle estensioni TLS a ogni connessione, dichiaratamente come misura contro l'ossificazione e contro il fingerprinting. Siccome JA3 calcola l'hash dell'elenco delle estensioni nell'ordine in cui viaggiano, un ordine randomizzato produce un hash diverso ogni volta. Chrome è passato da un solo JA3 a JA3 di fatto illimitati da un giorno all'altro.
Ne è derivata una conseguenza che nessuno nel settore antidetect amava sottolineare: per un certo periodo, un JA3 stabile era di per sé sospetto, perché il vero Chrome non ne aveva più uno.
JA4 e la famiglia JA4+
JA4, pubblicato da FoxIO nel 2023, risolve il problema dell'ordinamento nel modo ovvio: ordina cifrari ed estensioni prima di calcolare l'hash. Randomizza pure l'ordine sul filo quanto vuoi; l'elenco ordinato resta lo stesso, quindi il fingerprint torna stabile.
È anche leggibile invece che opaco. Un JA4 è una stringa di 36 caratteri in tre parti, e la prima è comprensibile a occhio nudo: protocollo e versione TLS, presenza di SNI, numero di cifrari ed estensioni e il valore ALPN. Puoi guardare un JA4 e capire che un client ha offerto 15 cifrari su TLS 1.3 con h2 negoziato, prima ancora di cercare l'hash.
JA4 è il fulcro di una famiglia più ampia, e due parenti contano qui:
- JA4H fa il fingerprint della richiesta HTTP stessa — metodo, versione, nomi delle intestazioni in ordine, presenza di cookie e il valore
Accept-Language. Coglie un client le cui intestazioni non corrispondono al browser che dichiara di essere. - JA4L misura la latenza fra i passi dell'handshake. È il più difficile del gruppo da falsificare, perché non è un valore che emetti: è il tempo fisico che il tuo stack impiega a rispondere, e un intermediario che termina e ristabilisce il TLS lo cambia che tu lo voglia o no.
Al 2026 JA4 è in produzione su Cloudflare, Akamai e AWS WAF, fra gli altri. Consideralo distribuito universalmente, non una tecnica emergente.
HTTP/2: il fingerprint Akamai
HTTP/2 rivela quanto TLS, ed è controllato meno spesso da chi cerca di passare inosservato.
Il formato più usato è quello di Akamai, e ha quattro parti unite da barre verticali:
- Frame SETTINGS — i parametri che il client invia e i loro valori, in ordine. Chrome, Firefox e Safari ne inviano ciascuno un insieme diverso. Così fa ogni libreria HTTP.
- WINDOW_UPDATE — l'incremento iniziale della finestra a livello di connessione.
- Frame di priorità — se il client li invia e come struttura l'albero.
- Ordine degli pseudo-header — la sequenza di
:method,:authority,:scheme,:path. Chrome usam,a,s,p. Quasi nessuna libreria lo fa.
Quest'ultimo punto è di un'efficacia quasi comica. La specifica HTTP/2 non impone un ordine, quindi le implementazioni hanno scelto il proprio e non l'hanno mai cambiato. Una richiesta che dichiara di essere Chrome ma invia i suoi pseudo-header in un ordine diverso si è contraddetta prima che il server abbia letto una sola intestazione vera.
Perché non puoi sistemarlo dall'interfaccia del browser
Questa è la parte su cui vale la pena essere brutali, perché va contro parecchio marketing — compreso, a essere onesti, il marketing di questo settore in generale.
Le impostazioni di fingerprint del tuo browser antidetect — modalità canvas, vendor WebGL, fuso orario, font — operano dentro il renderer. L'handshake TLS avviene nello stack di rete, in un altro processo, prima che il renderer entri in gioco. Non c'è nessuna impostazione che lo cambi, perché nel profilo non c'è niente da cambiare: l'handshake lo produce BoringSSL così com'è compilato nel binario.
Il che porta all'unica notizia davvero buona di questo articolo: se stai pilotando una build di Chromium vera, i tuoi fingerprint TLS e HTTP/2 sono già quelli di Chrome. Puppeteer su Chrome vero, Playwright su Chrome vero e qualsiasi browser antidetect basato su Chromium presentano lo stesso handshake del Chrome che hai sul desktop, perché è lo stesso codice. I flag di automazione non lo cambiano.
I client che vengono beccati a questo livello sono quelli che non sono affatto browser: requests, axios, httpx, il net/http di Go, curl. Impostano uno user agent Chrome e poi consegnano un ClientHello che nessun Chrome ha mai prodotto. È esattamente l'incoerenza che JA4 è stato costruito per cogliere.
Cosa fanno i proxy all'handshake
La scelta del proxy qui conta, ed è una distinzione che quasi tutte le guide sbagliano.
| Tipo di proxy | Effetto sul fingerprint TLS |
|---|---|
| SOCKS5 | Nessuno. Inoltra i byte TCP senza toccarli; il tuo ClientHello arriva intatto al server. |
| HTTP CONNECT | Nessuno. Apre un tunnel; il TLS viene negoziato da un capo all'altro attraverso di esso. |
| MITM / che termina il TLS | Totale. Il proxy esegue il proprio handshake, quindi il server vede il fingerprint del proxy, non il tuo. |
La modalità di guasto è l'ultima riga, e non è sempre qualcosa che hai scelto tu. Gli apparati aziendali di ispezione, alcuni servizi proxy "che ottimizzano l'SSL" e qualsiasi strumento locale di debug della famiglia Charles o Fiddler terminano tutti il TLS. Se il fingerprint di un browser improvvisamente risulta esotico, cerca un intercettatore prima di cercare qualsiasi altra cosa.
Vale la pena aggiungere: JA4L rende parzialmente visibile anche un proxy trasparente, perché il salto in più costa tempo. Non è una cosa che puoi togliere di configurazione. È un motivo per preferire un proxy geograficamente vicino all'uscita che stai dichiarando, invece di uno instradato attraverso tre continenti.
Flag che contano e flag che non contano
Una domanda ricorrente è se i flag di avvio di Chrome cambino l'handshake. Quasi sempre no, e vale la pena conoscere le eccezioni.
Nessun effetto sul TLS: --headless, --no-sandbox, --disable-gpu, --disable-dev-shm-usage, il dimensionamento della finestra e l'intera famiglia di flag lato renderer. Cambiano come vengono disegnate le pagine e come il processo viene isolato, non come BoringSSL saluta un server.
Effetto reale: --disable-http2 forza il downgrade a HTTP/1.1, il che elimina il fingerprint HTTP/2 e lo sostituisce con qualcosa di più raro e quindi più vistoso — un Chrome moderno che rifiuta h2 è insolito. --ssl-version-min e simili alterano direttamente ciò che viene offerto nel ClientHello. Le opzioni che disattivano QUIC cambiano quali protocolli vengono tentati e in che ordine.
La regola generale: se un flag sembra toccare lo stack di rete, dai per scontato che cambi il tuo fingerprint e verifica prima di metterlo in produzione.
Come controllare il tuo
Tre endpoint pubblici ti dicono a che punto sei in meno di un minuto:
- tls.peet.ws/api/all — restituisce il tuo JA3, JA4, il fingerprint HTTP/2 Akamai completo e l'ordine delle tue intestazioni, in JSON. La vista singola più completa.
- browserleaks.com/tls — lo stesso terreno con una presentazione più amichevole.
- scrapfly.io/web-scraping-tools/ja3-fingerprint — utile per confrontare un client con firme di browser note come buone.
Il test che conta davvero richiede due finestre. Apri uno di quegli URL nel tuo normale Chrome desktop, poi riaprilo con lo strumento che stai valutando. Confronta il JA4 e il fingerprint HTTP/2 campo per campo. Se coincidono, questo strato non è il tuo problema e faresti meglio a dedicare attenzione alla superficie CDP e al fatto che il tuo fingerprint stia in piedi. Se differiscono, nessuna quantità di configurazione del canvas ti aiuterà.