TLS Pós-Quântico em 2026: Por Que o JA4 Não Salva Mais o Scraper

Há um ano, o esquema era claro: você pega um cliente que consegue falsificar o handshake TLS, ajusta o perfil para o Chrome mais recente, obtém um JA4 correspondente — e o anti-bot deixa passar. Em 2026, essa receita começou a falhar devido a um motivo que não tem nada a ver com "bypass de proteção". Os navegadores migraram em massa para a troca de chaves pós-quântica, enquanto a maioria das pilhas de scraping não o fez. E agora a ausência de compartilhamento de chave pós-quântica é, por si só, uma marca de automação.

Vamos analisar por critérios: o que exatamente mudou no handshake, quais pilhas já migraram, quais não, e por que o hash JA4 correspondente deixou de ser uma condição suficiente.

O que aconteceu: a troca pós-quântica se tornou a norma, e não uma exótica

A troca de chaves híbrida pós-quântica é uma combinação da curva elíptica clássica X25519 e do mecanismo de rede ML-KEM (padrão NIST FIPS 203). A sessão permanece protegida se pelo menos um dos dois componentes for resistente. O objetivo é proteger contra o cenário "capture agora, decifre depois", quando o tráfego é gravado em arquivo na expectativa de um futuro computador quântico.

Cronologia da implementação nos clientes:

• Chrome 124 (abril de 2024) — a troca híbrida pós-quântica é ativada por padrão; nos patches curl-impersonate, isso é registrado como "curvas X25519Kyber768/X25519MLKEM, introduzidas no Chrome 124 e 130".
• Firefox 132 (novembro de 2024) — suporte ativado.
• Safari no iOS e macOS — a troca pós-quântica chegou em outubro de 2025.
• OpenSSL 3.5.0 (abril de 2025) — grupos híbridos X25519MLKEM768, SecP256r1MLKEM768 e SecP384r1MLKEM1024 foram incluídos na lista padrão de grupos TLS.
• Go 1.24 (fevereiro de 2025) — X25519MLKEM768 é incluído em crypto/tls por padrão, a menos que Config.CurvePreferences seja explicitamente definido.

Do lado da infraestrutura, a situação é ainda mais clara. O Cloudflare Radar em abril de 2026 mostrava cerca de 67% do tráfego HTTPS humano com criptografia pós-quântica — em comparação com 32% em janeiro de 2025. A Akamai tornou a troca de chaves pós-quântica o padrão para todas as conexões de clientes em 31 de janeiro de 2026, completando a implementação na rede em março. Segundo medições do setor, cerca de 57,4% de todas as transações de navegador já estão prontas para o pós-quântico, com a participação do Chrome capaz de PQ em cerca de 93%.

Note a assimetria: o suporte do lado dos servidores de origem cresce muito mais lentamente (no Cloudflare, cerca de 9%). Ou seja, a pós-quanticidade hoje é, em primeiro lugar, uma característica do cliente. Exatamente o que interessa ao anti-bot.

Critério 1: tamanho do key share e estrutura do ClientHello

O key share pós-quântico não é "apenas mais uma bandeira na extensão". Ele é fisicamente grande: cerca de 1124 bytes em comparação com 36 bytes do clássico X25519. As consequências são visíveis a olho nu no nível dos pacotes.

O ClientHello com o key share pós-quântico ultrapassa 1400 bytes e deixa de caber em um único segmento TCP. Ele é dividido em dois ou mais pacotes. E então começa a parte mais interessante para a detecção: o padrão de fragmentação varia entre diferentes implementações. Como exatamente a pilha divide o grande ClientHello, em que ordem os segmentos são enviados, com quais tempos — esse é um comportamento observável que não é derivado do hash JA4 e que quase ninguém dos autores de ferramentas de scraping reproduz conscientemente.

Conclusão prática: o anti-bot ganhou uma camada que opera abaixo da impressão digital habitual. Você pode reunir perfeitamente uma lista de cifras e extensões, mas se entregar pelo jeito que sua pilha coloca bytes no socket.

Critério 2: consistência com a versão do navegador declarada

A principal armadilha de 2026 é a desincronização entre quem você se apresenta e o que seu stack TLS realmente faz.

As plataformas anti-bot mantêm bases de dados de ClientHello de referência. Um pedido que no User-Agent e no JA4 declara Chrome 131, mas chega sem o key share pós-quântico, não corresponde a nenhum Chrome 131 válido conhecido. Isso não é "suspeito" — é uma combinação logicamente impossível. Um verdadeiro Chrome dessa versão fisicamente não pode enviar um key share clássico com as configurações padrão.

O quão bem isso é separado pelo aprendizado de máquina também foi calculado. O classificador CatBoost com características JA4 em estudos mostra AUC 0,998 e precisão 0,9863; o tráfego pós-quântico se distingue do clássico com precisão de cerca de 98%. Isso não é "heurística com falsos positivos", é praticamente um sinal determinístico.

Critério 3: prontidão de pilhas específicas

Aqui é onde a verdadeira linha de divisão passa. Vamos dividir em grupos.

Enviam PQ key share por padrão

• Chrome 124+, Firefox 132+, Safari (iOS/macOS desde outubro de 2025) — referência com a qual você é comparado.
• Go 1.24+ — crypto/tls inclui X25519MLKEM768 automaticamente, a menos que você tenha redefinido CurvePreferences. Um detalhe importante: a pós-quanticidade existe, mas o JA4 do cliente Go puro ainda não é de navegador. Você obtém uma impressão "compatível com PQ, mas não parecida com Chrome".
• Node.js 24 — traz seu próprio OpenSSL 3.5, então a lista padrão de grupos já inclui o híbrido. Além disso, no node:crypto, apareceram ML-KEM através de crypto.encapsulate()/decapsulate() e ML-DSA em sign()/verify().

Dependem do que estão vinculados

• Python: requests, aiohttp, httpx — usam o módulo ssl, que utiliza o OpenSSL do sistema. No Ubuntu 24.04, o sistema tem o OpenSSL 3.0.x, onde não há grupos pós-quânticos. Para obter PQ, é necessário compilar o OpenSSL 3.5 a partir do código-fonte, configurá-lo através do LD_LIBRARY_PATH e, provavelmente, recompilar o próprio Python. Na prática, isso significa: um scraper Python típico em 2026 envia um key share clássico e parece uma anomalia para a Akamai.

Sabem, mas apenas se escolherem o perfil correto

• curl_cffi / curl-impersonate — o suporte para curvas pós-quânticas no fork existe e é declarado explicitamente. Mas a lista de alvos vai de chrome99 a chrome146 (no fork — até chrome150), e perfis antigos reproduzem o handshake de sua época, ou seja, sem PQ. Copiar impersonate="chrome116" do guia de dois anos atrás é um caminho direto para a detecção.
• uTLS — o mesmo princípio: perfis HelloChrome abaixo do 131 não contêm PQ key share. Além disso, na biblioteca de 2026, duas vulnerabilidades de impressão digital foram corrigidas: CVE-2026-26995 (versões 1.6.0–1.8.1) e CVE-2026-27017 (1.6.0–1.8.0, desincronização na escolha de cifra para GREASE ECH — o Chrome escolhe de forma determinística, enquanto o parrot no uTLS jogava uma moeda entre AES e ChaCha20, o que é impossível para um verdadeiro Chrome). É necessário atualizar para pelo menos 1.8.2.

O denominador comum: as ferramentas em sua maioria alcançaram. O problema não está nelas, mas no fato de que as configurações envelhecem mais rápido do que os navegadores. O perfil que era ideal em 2024 hoje funciona como um marcador.

Como verificar seu stack em cinco minutos

1. Envie uma solicitação com seu cliente de produção para https://tls.peet.ws/api/all ou ja4db.com — eles retornam JA3/JA4 ao vivo e a análise do ClientHello em JSON.
2. Encontre na análise a lista supported_groups e key_share. Procure por X25519MLKEM768 (ou X25519Kyber768 em perfis antigos). Se houver apenas x25519/secp256r1 — não há troca pós-quântica.
3. Compare isso com a versão do navegador que você está se apresentando. Declarar Chrome 131+ e não ver grupos PQ — a combinação é inválida, ajuste o perfil.
4. Observe o tamanho do ClientHello. Menos de ~1400 bytes com o Chrome recente declarado — é o mesmo sinal, apenas de outro lado.
5. Execute a verificação de cada nó de saída, e não apenas da máquina de trabalho: a inspeção SSL no gateway corporativo ou no provedor pode reescrever o handshake por você.

O que os proxies fazem aqui

É importante não misturar duas camadas independentes. O key share pós-quântico é sobre handshake, a reputação do endereço é sobre rede. O anti-bot considera-os separadamente e os soma.

Daqui surgem duas consequências práticas. Primeiro: um IP residencial ideal não salvará uma solicitação que, no nível TLS, se apresenta como Chrome 131 sem grupo PQ — você perderá antes mesmo que o servidor olhe para o endereço. Segundo, o oposto: um handshake pós-quântico bem formado não ajudará se uma centena de suas sessões vierem de uma sub-rede de datacenter com reputação danificada. É necessário corrigir ambas as camadas, e elas são corrigidas com ferramentas diferentes.

Distribuição prática por tarefas: para objetivos além da Akamai e Cloudflare, onde consideram tanto o handshake quanto a rede, é sensato usar proxies residenciais e, ao mesmo tempo, elevar o alvo impersonate para um Chrome recente. Para aplicativos móveis e plataformas onde o peso da reputação do IP é maior do que os requisitos de TLS, muitas vezes ganham proxies móveis. E para APIs próprias, exportações de parceiros e monitoramento interno, onde não há anti-bot, não faz sentido pagar a mais por residenciais — basta datacenter.

Se você está começando a entender a impressão digital do zero, comece pela base: como funciona o JA4 e o que ele inclui. E quando se trata não de um cliente HTTP, mas de um navegador completo, a comparação de compilações stealth e seus pontos fracos foi reunida separadamente — nodriver, Camoufox e Patchright em medições de 2026.

Conclusão

A troca de chaves pós-quânticas não foi concebida como um mecanismo anti-bot. Ela se tornou um indiretamente: os navegadores migraram rapidamente e em massa, a infraestrutura (Akamai — desde 31 de janeiro de 2026) a tornou o padrão, e as pilhas de scraping se dividiram em três grupos — aqueles que já migraram, aqueles que dependem do OpenSSL do sistema e aqueles que só conseguem se tiverem um perfil recente.

A verificação se resume a uma pergunta: seu cliente envia X25519MLKEM768 e isso é consistente com a versão do navegador que você está se apresentando? Se não — o JA4 correspondente não o salvará, porque agora comparam não apenas o hash, mas toda a forma do handshake como um todo: tamanho do key share, número de segmentos TCP e a ordem em que são enviados. A boa notícia é que isso pode ser corrigido na maioria dos casos atualizando o perfil e a versão da biblioteca, e não reescrevendo o scraper.