Vazamentos de WebRTC: por que seu endereço real pode aparecer mesmo atrás de um proxy
O WebRTC existe para que os navegadores conversem diretamente entre si em chamadas e compartilhamento de tela. Para isso, eles precisam descobrir os endereços pelos quais podem ser alcançados, e esse processo de descoberta é o que se chama de “vazamento de WebRTC”.
Candidatos ICE em um parágrafo
Quando uma página cria um RTCPeerConnection e inicia uma oferta, o navegador reúne candidatos: maneiras pelas quais outro par poderia alcançá-lo. Um candidato host é o endereço de uma interface local. Um candidato server-reflexive (srflx) é o endereço público que um servidor STUN viu a requisição chegar. Um candidato relay é o endereço de um servidor TURN. Cada candidato é entregue à página em uma linha de texto que contém o endereço, e é assim que um script consegue lê-lo, sem que nenhuma chamada chegue a ser feita.
Onde está o vazamento
O candidato srflx é o que importa. Para obtê-lo, o navegador envia um pequeno pacote UDP a um servidor STUN, que responde com o endereço que viu. Se o seu tráfego HTTP passa por um proxy mas o UDP não, o servidor STUN vê a sua conexão real, e a página passa a ter um endereço que discorda do que o servidor web viu. Essa discordância é o vazamento clássico. Uma página de diagnóstico pode mostrá-lo comparando os dois.
Observe o que está e o que não está acontecendo. Nenhuma mídia é capturada. Nenhuma permissão de microfone ou câmera está envolvida. O pacote vai para o servidor STUN que a página indicou, então esse servidor, como qualquer servidor que você contata, vê o seu endereço.
O que os navegadores mudaram
Os candidatos host costumavam expor endereços privados da rede local, como 192.168.1.23, úteis para fazer o fingerprint de uma rede doméstica. Os navegadores modernos os substituem por nomes mDNS gerados aleatoriamente, terminados em .local, de modo que a página vê um nome opaco em vez de um endereço. Um diagnóstico que informa “mascarado pelo navegador” está descrevendo esses nomes. O Firefox e o Brave também oferecem configurações que impedem a coleta de candidatos fora do proxy, e algumas extensões bloqueiam o WebRTC por completo.
Configurações seguras para proxy
Três abordagens funcionam, com custos diferentes. Desativar o WebRTC impede o vazamento e quebra todo site que o utiliza. Forçar o WebRTC a usar apenas a rota do proxy (o modo “proxy-safe” de alguns navegadores) mantém as chamadas funcionando quando o proxy oferece suporte a UDP ou TURN e, caso contrário, não gera nenhum candidato público. Deixar o WebRTC se comportar normalmente só é correto quando o proxy transporta todo o tráfego, como costuma fazer uma VPN em nível de sistema.
Qual é a certa depende do trabalho. Para um perfil de navegador isolado que precisa parecer estar em um único lugar, a regra é simples: o endereço que o WebRTC expõe deve ser o mesmo que o servidor web vê, ou nenhum. Qualquer outra coisa é uma contradição que um site pode notar sem nenhuma ferramenta especial.
Lendo o resultado
Um diagnóstico mostra os candidatos observados em poucos segundos e compara qualquer um público com o endereço pelo qual a página foi acessada. “Nenhum exposto”, com alguns candidatos mascarados, é um resultado normal e saudável para um navegador que mantém o WebRTC dentro do proxy. Um endereço público diferente do endereço da página é o que precisa ser corrigido.
