Ancora un anno fa, lo schema era chiaro: prendi un cliente che sa come falsificare l'handshake TLS, scegli un profilo per il nuovo Chrome, ottieni un JA4 corrispondente — e l'antibot ti lascia passare. Nel 2026, questa ricetta ha iniziato a dare problemi a causa di un motivo che non ha nulla a che fare con il "bypass delle protezioni". I browser hanno massicciamente adottato lo scambio di chiavi post-quantistiche, mentre la maggior parte dei stack di scraping no. E ora, l'assenza di uno scambio di chiavi post-quantistico è di per sé un segnale di automazione.
Analizziamo per criteri: cosa è cambiato esattamente nell'handshake, quali stack hanno già effettuato la transizione, quali no, e perché l'hash JA4 corrispondente ha smesso di essere una condizione sufficiente.
Cosa è successo: lo scambio post-quantistico è diventato la norma, non un'esotica
Lo scambio ibrido di chiavi post-quantistiche è una combinazione della curva ellittica classica X25519 e del meccanismo reticolare ML-KEM (standard NIST FIPS 203). La sessione rimane protetta se almeno uno dei due componenti è resistente. Il concetto è proteggere da uno scenario di "cattura ora, decifra poi", quando il traffico viene archiviato in attesa di un futuro computer quantistico.
La cronologia dell'implementazione nei client:
- Chrome 124 (aprile 2024) — lo scambio ibrido post-quantistico è attivato di default; nei patch curl-impersonate è registrato come "curve X25519Kyber768/X25519MLKEM, introdotte in Chrome 124 e 130".
- Firefox 132 (novembre 2024) — supporto attivato.
- Safari su iOS e macOS — lo scambio post-quantistico è arrivato nell'ottobre 2025.
- OpenSSL 3.5.0 (aprile 2025) — i gruppi ibridi X25519MLKEM768, SecP256r1MLKEM768 e SecP384r1MLKEM1024 sono stati inclusi nell'elenco di gruppi TLS di default.
- Go 1.24 (febbraio 2025) — X25519MLKEM768 è incluso in crypto/tls di default, a meno che Config.CurvePreferences non sia specificato esplicitamente.
Dalla parte dell'infrastruttura, la situazione è ancora più chiara. Cloudflare Radar ad aprile 2026 mostrava circa 67% del traffico HTTPS umano con crittografia post-quantistica — rispetto al 32% di gennaio 2025. Akamai ha reso lo scambio di chiavi post-quantistiche il default per tutte le connessioni client 31 gennaio 2026, completando il rollout nella rete a marzo. Secondo le misurazioni di settore, circa 57,4% di tutte le transazioni browser sono già pronte per il post-quantistico, con Chrome che ha una quota di capacità PQ di circa il 93%.
Si noti l'asimmetria: il supporto sui server di origine cresce molto più lentamente (da Cloudflare è circa il 9%). Quindi, la post-quantisticità oggi è prima di tutto una caratteristica del client. Proprio ciò che interessa all'antibot.
Criterio 1: dimensione del key share e struttura ClientHello
Il key share post-quantistico non è "solo un altro flag nell'estensione". È fisicamente grande: circa 1124 byte contro 36 byte del classico X25519. Le conseguenze sono visibili ad occhio nudo a livello di pacchetti.
Il ClientHello con il key share post-quantistico supera i 1400 byte e smette di entrare in un singolo segmento TCP. Viene suddiviso in due o più pacchetti. E qui inizia la parte più interessante per il rilevamento: il pattern di frammentazione è diverso tra le varie implementazioni. Come esattamente lo stack taglia un grande ClientHello, in quale ordine invia i segmenti, con quali tempistiche — questo è un comportamento osservabile che non può essere dedotto dall'hash JA4 e che quasi nessuno degli autori di strumenti di scraping riproduce consapevolmente.
Conclusione pratica: l'antibot ha ora un livello che opera sotto l'impronta abituale. Puoi raccogliere perfettamente un elenco di cifrari ed estensioni, ma potresti rivelarti dal modo in cui il tuo stack inserisce i byte nel socket.
Criterio 2: coerenza con la versione del browser dichiarata
Il principale tranello del 2026 è la dissonanza tra chi ti presenti e ciò che il tuo stack TLS sta realmente facendo.
Le piattaforme antibot mantengono database di ClientHello di riferimento. Una richiesta che nel User-Agent e nel JA4 dichiara Chrome 131, ma arriva senza il key share post-quantistico, non corrisponde a nessun Chrome 131 valido conosciuto. Non è "sospetto" — è una combinazione logicamente impossibile. Un vero Chrome di quella versione non può fisicamente inviare un key share classico con le impostazioni di default.
Quanto bene questo venga separato dall'apprendimento automatico è stato anche calcolato. Il classificatore CatBoost, basato sulle caratteristiche JA4, mostra negli studi AUC 0,998 e accuratezza 0,9863; il traffico post-quantistico si distingue da quello classico con un'accuratezza di circa 98%. Non si tratta di "euristiche con falsi positivi", ma di un segnale praticamente deterministico.
Criterio 3: prontezza di specifici stack
Qui si trova la vera linea di demarcazione. Suddividiamo in gruppi.
Inviano PQ key share di default
- Chrome 124+, Firefox 132+, Safari (iOS/macOS da ottobre 2025) — il riferimento con cui ti confrontano.
- Go 1.24+ — crypto/tls include X25519MLKEM768 automaticamente, a meno che tu non abbia sovrascritto CurvePreferences. Un'importante sfumatura: c'è post-quantisticità, ma JA4 in un client Go nudo non è comunque browser-based. Ottieni un'impronta "compatibile PQ, ma non simile a Chrome".
- Node.js 24 — utilizza OpenSSL 3.5, quindi l'elenco di gruppi di default include già l'ibrido. Inoltre, in node:crypto sono stati aggiunti ML-KEM tramite crypto.encapsulate()/decapsulate() e ML-DSA in sign()/verify().
Dipendono da ciò a cui sono collegati
- Python: requests, aiohttp, httpx — utilizzano il modulo ssl, che prende l'OpenSSL di sistema. Su Ubuntu 24.04, il sistema ha OpenSSL 3.0.x, dove i gruppi post-quantistici non ci sono affatto. Per ottenere PQ, è necessario compilare OpenSSL 3.5 dai sorgenti, inserirlo tramite LD_LIBRARY_PATH e, molto probabilmente, ricompilare Python stesso. Nella pratica, questo significa: un tipico scraper Python nel 2026 invia un key share classico e su Akamai appare come un'anomalia.
Possono, ma solo se si sceglie il profilo giusto
- curl_cffi / curl-impersonate — il supporto per le curve post-quantistiche è presente nel fork ed è dichiarato esplicitamente. Ma l'elenco dei target va da chrome99 a chrome146 (nel fork — fino a chrome150), e i profili più vecchi riproducono l'handshake del loro tempo, cioè senza PQ. Copiare
impersonate="chrome116"dalla guida di due anni fa è un modo diretto per essere rilevati. - uTLS — stesso principio: i profili HelloChrome inferiori al 131 non contengono PQ key share. Inoltre, nella libreria del 2026 sono state chiuse due vulnerabilità di impronta: CVE-2026-26995 (versioni 1.6.0–1.8.1) e CVE-2026-27017 (1.6.0–1.8.0, dissonanza nella scelta del cifrario per GREASE ECH — Chrome lo sceglie in modo deterministico, mentre parrot in uTLS lanciava una moneta tra AES e ChaCha20, il che è impossibile per un vero Chrome). È necessario aggiornarsi almeno alla 1.8.2.
Il denominatore comune: gli strumenti hanno per lo più raggiunto il passo. Il problema non è in essi, ma nel fatto che le configurazioni invecchiano più velocemente dei browser. Un profilo che era ideale nel 2024 oggi funziona come un marcatore.
Come controllare il proprio stack in cinque minuti
- Invia una richiesta con il tuo client di produzione a
https://tls.peet.ws/api/alloja4db.com— restituiscono JA3/JA4 attivi e l'analisi del ClientHello in JSON. - Cerca nell'analisi l'elenco supported_groups e key_share. Cerca X25519MLKEM768 (o X25519Kyber768 nei profili più vecchi). Se ci sono solo x25519/secp256r1 — non c'è scambio post-quantistico.
- Confronta questo con la versione del browser con cui ti presenti. Dichiarando Chrome 131+ e non vedendo i gruppi PQ — la combinazione non è valida, correggi il profilo.
- Controlla la dimensione del ClientHello. Meno di ~1400 byte con un Chrome recente dichiarato — è lo stesso segnale, solo da un'altra prospettiva.
- Esegui il controllo da ogni nodo di uscita, non solo dalla macchina di lavoro: l'ispezione SSL su un gateway aziendale o dal provider potrebbe riscrivere l'handshake per te.
Cosa fanno qui i proxy
È importante non mescolare due strati indipendenti. Il key share post-quantistico riguarda l'handshake, la reputazione dell'indirizzo riguarda la rete. L'antibot li considera separatamente e li somma.
Da qui due conseguenze pratiche. Prima: un IP residenziale ideale non salverà una richiesta che a livello TLS si presenta come Chrome 131 senza un gruppo PQ — perderai ancora prima che il server guardi l'indirizzo. Secondo, speculare: un handshake post-quantistico ben costruito non aiuterà se centinaia delle tue sessioni provengono da una subnet di data center con una reputazione compromessa. È necessario riparare entrambi gli strati, e si riparano con strumenti diversi.
Distribuzione pratica per i compiti: per obiettivi oltre Akamai e Cloudflare, dove si considerano sia l'handshake che la rete, è ragionevole utilizzare proxy residenziali e contemporaneamente alzare il target impersonate a un Chrome recente. Per applicazioni mobili e piattaforme dove il peso della reputazione IP è maggiore delle esigenze TLS, spesso vincono proxy mobili. E per API proprie, estrazioni partner e monitoraggio interno, dove non ci sono antibot, non ha senso pagare di più per residenziali — bastano datacenter.
Se stai affrontando l'impronta da zero, inizia con le basi: come è strutturato JA4 e cosa include. E quando si tratta non di un client HTTP, ma di un browser completo, il confronto tra build stealth e i loro punti deboli è stato raccolto separatamente — nodriver, Camoufox e Patchright nelle misurazioni del 2026.
Conclusione
Lo scambio di chiavi post-quantistiche non è stato concepito come un meccanismo antibot. È diventato tale incidentalmente: i browser sono passati a questo rapidamente e in massa, l'infrastruttura (Akamai — dal 31 gennaio 2026) lo ha reso il default, e gli stack di scraping si sono divisi in tre gruppi — quelli già passati, quelli che dipendono dall'OpenSSL di sistema e quelli che possono farlo solo con un profilo recente.
Il controllo si riduce a una domanda: il tuo client invia X25519MLKEM768 e questo è coerente con la versione del browser con cui ti presenti? Se no — un JA4 corrispondente non ti salverà, perché non si confrontano più solo gli hash, ma l'intera forma dell'handshake: dimensione del key share, numero di segmenti TCP e ordine di invio. La buona notizia è che in molti casi questo si risolve aggiornando il profilo e la versione della libreria, piuttosto che riscrivendo lo scraper.