Detecção de vazamento de IP por WebRTC: de bug a recurso

O WebRTC — Web Real-Time Communication — foi projetado para permitir chamadas de vídeo, compartilhamento de arquivos e transferência de dados peer-to-peer diretamente no navegador. Para estabelecer essas conexões, os navegadores precisam descobrir suas próprias interfaces de rede e negociar a conectividade com peers remotos. Esse processo envolve servidores STUN (Session Traversal Utilities for NAT) e TURN (Traversal Using Relays around NAT), que ajudam os navegadores a descobrir seus endereços IP públicos e atravessar firewalls NAT.

O efeito colateral é poderoso: mesmo quando um usuário se conecta por meio de uma VPN, a pilha WebRTC do navegador pode revelar o endereço IP real por trás do túnel. Isso acontece porque os candidatos ICE (Interactive Connectivity Establishment) do WebRTC incluem endereços de interfaces de rede locais que a VPN não mascara.

Como funciona o vazamento

Quando um navegador cria uma RTCPeerConnection e reúne candidatos ICE, ele consulta servidores STUN para descobrir seu IP público. Mas ele também enumera as interfaces de rede locais — incluindo o IP privado do adaptador físico. Se a VPN só faz o túnel do tráfego na camada de IP, mas não configura a pilha WebRTC do navegador para usar exclusivamente a interface do túnel, o IP real vaza pelo candidato host.

No tracio.ai, sondamos esse comportamento com cuidado. Nosso sistema IP Intelligence cria uma requisição STUN controlada e analisa os candidatos ICE que o navegador retorna. Quando o IP público do STUN difere do IP que vemos no nosso servidor, sinalizamos uma VPN ou proxy. Quando o IP da interface local revela uma faixa de rede privada que contradiz a suposta localização geográfica, aumentamos o suspect score.

De bug a sinal de detecção

A maioria dos navegadores focados em privacidade corrigiu esse vazamento — o Chrome exige permissão explícita do usuário para o WebRTC, e o Firefox oferece configurações para desabilitar o UDP não-proxied. Mas a corrida armamentista continua: alguns clientes de VPN não configuram o WebRTC corretamente, versões mais antigas de navegador permanecem vulneráveis, e o próprio padrão comportamental de uma resposta WebRTC "corrigida" versus "vazando" já é um sinal útil.

Nossa abordagem trata a resposta do WebRTC como um sinal composto: a presença de candidatos host, o número de candidatos ICE retornados, os tipos de candidatos (host, srflx, relay) e o timing da resposta contribuem todos para a impressão digital do dispositivo. Mesmo quando nenhum IP vaza, o padrão do comportamento do WebRTC é distintivo.

Sondagem de servidor TURN

Além do STUN, também sondamos o comportamento do servidor TURN. Os relays TURN são normalmente usados quando conexões peer-to-peer diretas falham — comum em redes corporativas atrás de firewalls rígidos. A resposta de alocação TURN revela informações sobre o caminho do relay: o protocolo de transporte (UDP vs TCP vs TLS), o endereço do relay e o tempo de vida da alocação.

Nosso sistema SignalProbe envia requisições de alocação TURN cuidadosamente elaboradas para nossos próprios servidores de relay. O tempo de resposta, os transportes suportados e os padrões de sucesso/falha de alocação variam conforme o ambiente de rede e fornecem diversidade adicional de sinais para a impressão digital do dispositivo.

Considerações de privacidade

Queremos deixar claro: o tracio.ai não explora vazamentos de WebRTC para desanonimizar usuários. Nosso sistema detecta quando uma VPN está em uso e reporta isso como um sinal de risco. Nunca armazenamos nem expomos o endereço IP vazado. O sinal é binário: "VPN detectada com inconsistência de WebRTC" ou "comportamento de WebRTC consistente com conexão direta".

Essa abordagem dá às equipes de prevenção de fraudes a informação de que precisam — um visitante está mascarando sua localização real — sem comprometer a privacidade individual. O sinal ajuda a detectar ataques de fraude coordenados, em que múltiplas contas se originam da mesma localização oculta.