JA3 e JA4: o fingerprint TLS que seu anti-detect não esconde

O que é JA3 e JA4

Toda conexão HTTPS começa com um TLS handshake: seu navegador manda um pacote chamado ClientHello dizendo ao servidor quais cifras ele suporta, em que ordem, quais extensões usa, quais curvas elípticas aceita e qual protocolo de aplicação prefere (o ALPN). Esse pacote sai antes de qualquer HTML, cookie ou linha de JavaScript.

JA3 e o mais recente JA4 são formas de resumir esse ClientHello numa impressão digital. Pegam a lista de cifras, a ordem das extensões, as curvas e o ALPN, e transformam tudo num hash. Cada combinação de navegador + versão + sistema gera um JA3/JA4 característico — e o Chrome real tem um, o Firefox tem outro, e o Chromium empacotado dentro de um app Electron tem um terceiro, que grita "isto não é um navegador comum".

Por que o anti-detect comum não cobre isso

A maior parte dos navegadores anti-detecção é construída sobre o próprio Chromium (às vezes empacotado com Electron). Eles fazem um ótimo trabalho reescrevendo o que o site consegue ler via JavaScript. Só que oClientHello é montado pela biblioteca de TLS do runtime, não pelo JavaScript — e o JavaScript não tem como reescrevê-lo. Resultado: por mais que a aba pareça um Chrome perfeito, o pacote TLS que sai na rede tem a assinatura do motor que empacotou o navegador.

Rastreadores sérios — Akamai (usado pela Meta), Cloudflare, DataDome — coletam o JA3/JA4 no primeiro pacote. Se ele não bate com nenhum Chrome real, ou pior, se bate com uma assinatura conhecida de automação, você já entra marcado antes da página renderizar.

O erro que multiplica o problema: TLS e user-agent desalinhados

Existe uma armadilha ainda mais sutil, e ela pega até quem usa ferramentas quetentam mexer no TLS. Suponha que seu perfil anunciaChrome/126 no user-agent, mas o TLS que sai imita umChrome/131. Cada um, isolado, parece legítimo. O problema é que o detector lê os dois e compara: um Chrome 126 de verdade nunca emitiria o TLS de um Chrome 131. Essa contradição é um sinal forte de adulteração — e dispara os loops de reCAPTCHA, os desafios do Cloudflare e o "confirme que é você".

Como o AlterAntiX resolve

O AlterAntiX intercepta o tráfego HTTPS de cada perfil por um pequeno proxy local (um binário em Go) que re-emite o ClientHello usando a biblioteca utls — a mesma técnica usada por ferramentas sérias de impersonação. Em vez do TLS genérico do Chromium empacotado, o pacote que sai na rede reproduz cifras, ordem de extensões, ALPN e GREASE de um Chrome real.

E o mais importante: o preset de TLS é casado com a versão do Chrome do perfil. O AlterAntiX trabalha com presets exatos — Chrome 120, 131 e 133 — e mantém os user-agents alinhados a essas versões, justamente pra você nunca cair na contradição "UA diz uma coisa, TLS diz outra". Cada perfil roda seu próprio proxy, então perfis em países diferentes podem usar proxies e presets diferentes ao mesmo tempo.

Onde ainda existe limite (e por que ser honesto sobre isso importa)

Não vendemos mágica. O utls replica com fidelidade oClientHello, mas a ordem exata dos frames de SETTINGS do HTTP/2 não é reproduzida com 100% de fidelidade — e detectores de altíssimo nível, como o Akamai Bot Manager Enterprise, olham também pra isso. Na prática, pros alvos que a maioria enfrenta (Meta Ads, Google, e-commerce, verificações de conta), o TLS alinhado já elimina o sinal que derruba a sessão. Mas você merece saber onde fica a fronteira.

Nos nossos testes, um perfil Chrome 131 com o preset chrome_131 passa pelo bot-detector.rebrowser.net sem vazamentos, loga no Gmail normalmente e cria conta nova no Facebook sem cair no loop do reCAPTCHA Enterprise. É o resultado de alinhar as duas camadas — não de esconder uma e torcer.