WebRTC Leak: o Vazamento que Entrega Seu IP Real com o Proxy Ligado

Por que um proxy bom não impede um vazamento de WebRTC

Proxy configurado no navegador tem um trabalho estreito: pegar as requisições HTTP e HTTPS que o navegador faz e mandar primeiro para outro lugar. Ele faz bem esse trabalho. O mal-entendido é supor que esse trabalho cobre tudo o que o navegador faz em rede, e não cobre.

WebRTC é o padrão que permite dois navegadores trocarem áudio, vídeo e dados diretamente, sem um servidor no meio repassando cada pacote. Videochamada que roda dentro da aba, widget de atendimento ao vivo, sala de reunião pelo navegador — tudo isso é WebRTC. Conexão direta é o propósito inteiro da tecnologia, e conexão direta exige que cada lado saiba onde pode de fato ser alcançado. Então, antes de qualquer chamada começar, o WebRTC sai procurando os endereços que descrevem onde você está na rede.

Essa descoberta não pede autorização à configuração de proxy do navegador e normalmente acontece em UDP, que a maior parte dos proxies HTTP não carrega. O resultado são duas realidades paralelas dentro do mesmo navegador: o tráfego da página chega ao site vindo do proxy, enquanto o WebRTC descobriu e publicou por conta própria o endereço da máquina que está de fato rodando o navegador. As duas coisas são verdade ao mesmo tempo, e um site que lê as duas enxerga a contradição na hora.

O que é WebRTC e por que ele entrega o seu IP real?

Dois computadores atrás de roteadores domésticos não conseguem simplesmente se endereçar. Cada um enxerga um endereço privado na própria rede e não faz ideia do que o mundo vê. O WebRTC resolve isso com um procedimento chamado ICE, que reúne todas as formas plausíveis de chegar até você e oferece a lista para o outro lado, para os dois escolherem um caminho que funcione.

A lista tem três tipos de entrada. Candidatos host são os endereços das suas próprias interfaces de rede, vistos por dentro. Candidatos reflexivos de servidorsão o que um servidor STUN na internet devolve depois que você o contata — na prática, o navegador perguntando a um estranho "de que endereço meu pacote chegou?" e recebendo de volta o seu IP público. Candidatos de relay são endereços num servidor TURN que aceita encaminhar tráfego no seu lugar.

O segundo tipo é onde mora o vazamento. Uma consulta STUN é uma troca pequena em UDP com um servidor público, e a resposta é o endereço que o mundo enxerga para a conexão que o navegador realmente usou — a de verdade, não a do proxy. Essa resposta entra na lista de candidatos, e a lista de candidatos é legível pelo JavaScript. Não há exploração de falha nenhuma. A página simplesmente lê um valor que o navegador já calculou e deixou disponível.

Os dois IPs em jogo, e o que já foi resolvido

A maioria dos testes de vazamento mostra duas coisas, e elas merecem níveis bem diferentes de preocupação.

O IP local é o seu endereço na rede de casa ou do escritório, aquele da faixa privada. Ele vazava livremente e era de fato útil para rastrear, porque contava ao site alguma coisa sobre o formato da sua rede. O Chrome fechou isso na versão 76, substituindo endereços privados por um nome mDNS gerado aleatoriamente — uma sequência de caracteres hexadecimais terminada em .local. Ver esse nome num teste hoje não é vazamento. É a mitigação funcionando.

O IP público é o que importa, e é o que continua exposto pela etapa STUN descrita acima. Se um teste de vazamento mostra um IP público que não é o do seu proxy, o achado é esse. Todo o resto da página é secundário.

Como o navegador alcança a rede por fora do proxy

Vale ser concreto, porque o mecanismo explica todas as mitigações que vêm depois. Quando a coleta ICE começa, o navegador enumera as interfaces de rede e tenta contatar os servidores STUN configurados. Essas tentativas são datagramas UDP. Um proxy HTTP fala HTTP; não tem mecanismo para carregar um datagrama UDP cru, então o navegador nem tenta mandar por ali. Um proxy SOCKS5 pode carregar UDP em tese, mas essa capacidade muitas vezes não está habilitada pelo fornecedor nem é usada pelo navegador nesse caminho.

O datagrama então sai pela rota padrão — a sua conexão de verdade. O servidor STUN responde honestamente. O navegador registra a resposta como candidato válido, porque do ponto de vista dele acabou de descobrir um caminho funcional até a internet, que é exatamente o que pediram para ele encontrar.

O Chrome expõe uma política para isso que vale conhecer pelo nome, porque é o vocabulário que toda ferramenta pega emprestado: WebRtcIPHandling. Os valores vão de default, que usa toda interface disponível, passando por default_public_interface_only, que impede interfaces privadas de serem oferecidas, até disable_non_proxied_udp, que obriga o WebRTC a usar UDP por um proxy SOCKS ou cair para TCP. Esse último valor é a opção mais forte quando você está deliberadamente forçando tráfego por um proxy — e é o antepassado do quinto modo da próxima seção.

Os cinco modos de tratar WebRTC e o que cada um faz de verdade

As ferramentas anti-detect costumam apresentar os mesmos cinco modos com nomes um pouco diferentes. Abaixo, o que está por trás de cada um, descrito pelo mecanismo e não pelo rótulo.

A distinção que passa batido é entre bloquear e substituir. Bloquear remove a capacidade; substituir mantém a capacidade e higieniza o que ela reporta. Do ponto de vista de detecção, são decisões opostas. Um perfil que diz ser Chrome e não consegue construir um RTCPeerConnection se contradisse, e essa contradição é tão barata de detectar quanto ler o user agent — a mesma classe de problema que descrevemos no artigo sobre ruído em canvas e WebGL: a defesa que remove um sinal muitas vezes cria um mais barulhento.

Qual modo usar em cada situação

• Conta de trabalho em marketplace, plataforma de anúncio ou rede social. Substituir. O site nunca vai precisar de conexão ponto a ponto, e o perfil mantém uma superfície de API completa e de aparência comum.
• Perfil que precisa fazer ou receber chamadas. Encaminhar, com um servidor TURN que você controla ou assina. É o único modo em que a mídia funciona e ao mesmo tempo fica atrás do seu relay.
• Perfil endurecido em que nenhum site vai usar mídia. Bloquear é defensável, desde que você aceite que a ausência da API já é um sinal.
• Perfil sem proxy nenhum, na sua própria conexão. Real. Se não há o que esconder, esconder cria anomalia sem benefício.
• SOCKS5 no lugar e postura mais rígida possível. Desabilitar UDP, para nada tentar um caminho de datagrama direto por fora do proxy.

Vale também ser honesto sobre quanto um vazamento custa, porque o nicho costuma descrever isso como catástrofe instantânea e normalmente não é. Um IP público vazado não fecha uma conta sozinho. O que ele faz é bem mais silencioso: entrega à plataforma um vínculo durável entre contas que deveriam não ter relação. Três perfis em três proxies diferentes que uma vez reportaram o mesmo endereço residencial são três contas que a plataforma consegue agrupar, e esse agrupamento não expira quando você corrige a configuração. O dano é retroativo e permanente, e é exatamente por isso que isso se testa antes de a operação crescer, não depois de dar errado.

Teste agora e leia o seu próprio resultado

Leva menos de um minuto e não exige instalar nada. Abra o teste de vazamento de WebRTC no navegador ou perfil que você usa para trabalhar, com o proxy ligado, e compare quatro linhas.

• IP público reportado pela requisição da página. Esse tem que ser o do seu proxy. Se não for, o problema está antes do WebRTC e você resolve isso primeiro com a checagem de IP e proxy.
• IP público descoberto pelo WebRTC. É esse o achado. Igual à linha de cima significa nenhum vazamento. Diferente, e especificamente o seu endereço de casa ou do escritório, significa vazamento.
• Endereço local. Uma sequência hexadecimal terminada em .local é o resultado esperado e saudável no Chrome atual. Um endereço de faixa privada indica que a mitigação mDNS não está em ação.
• Se o RTCPeerConnection sequer existe. Se o teste diz que a API está ausente enquanto o seu perfil afirma ser Chrome, você não está vazando — está anunciando que alguma coisa modifica o navegador.

Rode duas vezes: uma no seu navegador normal com o proxy ligado, outra no perfil que você pretende usar. A comparação ensina mais que qualquer um dos resultados sozinho, porque separa duas perguntas que costumam ser confundidas: se o seu proxy está roteando alguma coisa, e se o seu navegador está vazando por fora dele. Navegador comum com proxy configurado tipicamente passa na primeira e reprova na segunda, e ver os dois resultados lado a lado torna a distinção concreta como explicação nenhuma consegue. Para uma varredura de todos os outros sinais na mesma sentada, nosso roteiro de teste de 60 segundos cobre o resto das camadas.

Como o AlterAntiX trata WebRTC por perfil

No AlterAntiX a política de WebRTC é um campo do perfil, escolhido entre os cinco modos acima e aplicado quando o perfil abre, então dois perfis abertos ao mesmo tempo podem estar sob políticas diferentes. Perfis novos nascem no modo de substituição, que é o padrão porque é a resposta certa para a maioria das contas de trabalho, não porque seja o mais rígido.

O modo de substituição faz duas coisas juntas. Esvazia a lista de servidores ICE, para o navegador nunca perguntar a um STUN qual é o seu endereço público. E intercepta a descrição de sessão e o fluxo de candidatos, reescrevendo para 0.0.0.0 qualquer endereço real que apareça antes de a página ler — deixando em paz o loopback e o endereço não especificado, já que reescrever esses dois seria por si só uma anomalia. O modo de encaminhamento, em vez disso, filtra a lista de servidores para deixar só entradas TURN, e o modo de desabilitar UDP força a conexão para transporte só de relay.

Vale ser claro sobre o limite. Tratar WebRTC direito fecha um buraco específico. Não faz nada pelo fingerprint do navegador, e nada pelo handshake TLS que sai antes de tudo isso — um perfil pode passar num teste de WebRTC com nota máxima e ainda ser identificado por um JA3 ou JA4 que contradiz o próprio user agent. As camadas são independentes, e é por isso que a gente trata as duas como um trabalho só, não como uma opção. O AlterAntiX é download gratuito para desktop em Windows e Linux; a versão de macOS ainda não existe.