Vazamento de WebRTC

Um Vazamento de WebRTC ocorre quando um navegador expõe informações de endereço de rede que você esperava que uma VPN, proxy ou configuração de privacidade ocultassem. O exemplo mais claro é o IP público do seu ISP aparecendo em vez da VPN ou IP proxy que você planejou usar.

O WebRTC em si não é um recurso prejudicial. Suporta videochamadas, chat de voz, compartilhamento de tela e dados em tempo real no navegador. A questão da privacidade vem da maneira como ele procura um caminho de rede funcional.

Em termos simples, um Vazamento de WebRTC significa que o navegador revela um endereço inesperado enquanto prepara uma conexão em tempo real.

O que é um Vazamento de WebRTC?

A palavra vazamento precisa de contexto. Um site normalmente vê o IP público usado para carregar a página. Um teste WebRTC também pode mostrar o mesmo endereço. Se ambos os resultados apontarem para a VPN ou proxy selecionado, pode não haver vazamento algum.

O problema começa quando o WebRTC revela um endereço fora da rota esperada. Você pode ver o IP da VPN em uma verificação de IP normal e, em seguida, encontrar o IP do seu ISP doméstico no resultado do WebRTC. Você também pode encontrar um endereço IPv6 exposto que não foi detectado no primeiro teste.

Não trato todas as linhas de um verificador de vazamentos como uma falha. Procuro um endereço que a configuração atual deveria ocultar.

Quando a exposição IP se torna um vazamento

Suponha que seu endereço normal de ISP seja em Londres. Você se conecta a um proxy em Nova York. Um verificador de IP padrão agora mostra o proxy de Nova York. Essa parte funciona conforme o esperado.

Em seguida, você executa um teste WebRTC. Se também mostrar o endereço de Nova York, os sinais da rede concordam. Se também mostrar o endereço original do ISP de Londres, o navegador expôs um caminho inesperado.

A mesma lógica se aplica a uma VPN. Também se aplica ao IPv6. Uma rota IPv4 protegida não ajuda muito se um endereço IPv6 separado ainda apontar para a rede original.

Por que o WebRTC precisa de endereços de rede

A comunicação em tempo real precisa de um caminho entre dois terminais. Esse caminho pode ser direto. Pode passar por um dispositivo NAT. Pode ser necessário um relé quando uma conexão direta não puder ser estabelecida.

O WebRTC reúne rotas possíveis para escolher aquela que funciona. Isso ajuda as chamadas a iniciarem mais rapidamente e reduz o atraso. Isso também significa que um aplicativo da Web pode aprender mais sobre a rede do que aprenderia com uma solicitação de página normal.

Este processo é separado do acesso à câmera e ao microfone. Uma página pode criar uma conexão peer ou canal de dados e começar a reunir candidatos a conexão. O acesso aos dispositivos de mídia ainda precisa da permissão relevante do navegador.

Como acontece um Vazamento de WebRTC?

O processo começa com RTCPeerConnection. Um aplicativo da web cria esse objeto quando precisa de uma conexão em tempo real. O navegador então usa o Estabelecimento de Conectividade Interativa, geralmente chamado de ICE, para reunir possíveis candidatos a conexão.

Esses candidatos descrevem como a conexão pode funcionar. A aplicação web pode ler as informações do candidato e compartilhá-las com o lado remoto por meio de seu sistema de sinalização.

Se o navegador incluir um endereço de ISP que deveria ter permanecido atrás de uma VPN ou proxy, o aplicativo poderá vê-lo. Isso pode acontecer com tunelamento dividido, uma interface de rede extra, uma rota IPv6 desprotegida ou um proxy de navegador que ainda permite que o WebRTC se conecte fora do caminho esperado.

Reunião de candidatos do ICE

O fluxo tem cinco etapas:

1. Uma página cria RTCPeerConnection.
2. O agente ICE verifica os caminhos de conexão disponíveis.
3. O navegador reúne candidatos a retransmissão host, derivados de STUN ou TURN.
4. A aplicação recebe os candidatos que pode ver.
5. O ICE testa pares de candidatos e seleciona um caminho de trabalho.

ICE não é um servidor. É o processo usado para encontrar e testar opções de conexão. STUN e TURN apoiam esse processo de diferentes maneiras.

Candidatos anfitriões, STUN e TURN

Cada tipo de candidato revela uma parte diferente da conexão.

Um relé TURN pode manter os endereços de endpoint diretos longe do ponto remoto. Também adiciona outro servidor ao caminho. Isso pode aumentar o atraso, o custo da largura de banda e a dependência operacional do relé.

Quando uma VPN ou proxy expõe um caminho inesperado

VPNs e proxies não devem ser tratados como a mesma ferramenta. Uma VPN de túnel completo pode rotear um amplo tráfego de dispositivos e usar regras de firewall para interromper o tráfego fora do túnel. Uma VPN de túnel dividido permite que o tráfego selecionado use outra rota.

Um proxy de navegador geralmente lida com solicitações da Web para um navegador ou perfil. Pode não controlar todos os caminhos WebRTC. SOCKS5 pode suportar UDP, mas o roteamento WebRTC real ainda depende do navegador e de sua configuração.

Proxies, VPNs e navegadores antidetecção controlam diferentes camadas. Um proxy roteia o tráfego selecionado. Uma VPN pode gerenciar um túnel criptografado mais amplo. Um Navegador antidetecção gerencia perfis de navegador e sinais do lado do navegador. Um não substitui automaticamente os outros.

Que informações o WebRTC pode expor?

A maioria das páginas de teste mostra mais de um campo. Os rótulos podem parecer alarmantes, especialmente quando os endereços locais e públicos aparecem juntos. Ajuda julgar cada tipo por conta própria.

Endereços IP públicos

Um IP público é visível na internet. Pode indicar um ISP, um ASN, uma localização ampla e o tipo de rede em uso.

Quando uma VPN ou proxy está ativo, o aviso mais importante é o aparecimento do IP público do ISP de linha de base. Pode ser um endereço IPv4, um endereço IPv6 ou ambos.

Um Endereço IP normalmente não revela um endereço residencial exato por si só. Ainda são informações de rede úteis. Também pode entrar em conflito com a localização e o provedor mostrados pelo IP de saída esperado.

Endereços IP locais e nomes mDNS

Os endereços locais geralmente começam com intervalos como 192.168 ou 10. Esses endereços são reutilizados em muitas redes privadas. Um IP local geralmente é menos revelador do que um endereço de ISP público.

Isso não torna a informação local sem sentido. Pode revelar parte de um layout de rede. Uma combinação estável de interfaces locais também pode adicionar outro sinal quando as sessões são comparadas.

Os navegadores modernos geralmente ocultam um endereço de host local atrás de um nome mDNS .local aleatório. Ver esse nome não significa que o IP público do seu ISP vazou. Isso significa que o navegador está evitando a exposição direta do endereço local. Também não remove todos os sinais WebRTC possíveis.

IPv6 e múltiplas interfaces de rede

Muitas pessoas verificam o IPv4 e param por aí. Isso é fácil de entender. IPv4 ainda é o endereço que a maioria dos usuários reconhece.

O IPv6 precisa de sua própria verificação. Uma VPN pode lidar corretamente com o IPv4 enquanto outra configuração deixa o IPv6 visível. Wi-Fi, Ethernet, adaptadores virtuais e interfaces VPN também podem criar vários candidatos.

Os resultados variam de acordo com navegador, sistema operacional, rede e política de privacidade. Um teste ao vivo na configuração que você usa informa mais do que uma lista geral de navegadores.

Como testar um Vazamento de WebRTC

Um teste limpo começa com uma linha de base. Sem ele, você poderá ver vários endereços e não ter uma maneira confiável de saber qual deles pertence à conexão original.

Teste passo a passo de Vazamento de WebRTC

1. Desconecte a VPN ou proxy.
2. Registre os endereços IPv4 e IPv6 públicos atuais.
3. Feche a página de teste.
4. Conecte a VPN ou proxy ou inicie o perfil do navegador que deseja verificar.
5. Use um verificador de IP normal para confirmar o IP de saída esperado.
6. Abra um verificador específico do WebRTC.
7. Compare os resultados públicos, locais, mDNS, IPv6 e retransmissão com a linha de base.
8. Altere a configuração relevante e teste novamente se o endereço ISP original aparecer.

Os controles do navegador mudam com o tempo. Um Teste de Vazamento de WebRTC cuidadoso é mais importante do que uma lista antiga de configurações supostamente seguras.

Como ler os resultados do teste

Um teste do BrowserLeaks da MoreLogin verificou o IP, o WebRTC, o fuso horário, o idioma, o Canvas, o WebGL e as fontes no mesmo perfil.

Foi um teste em uma configuração. Não deve ser lido como uma promessa para cada versão de navegador, dispositivo, proxy ou perfil.

Por que um resultado verde não é uma garantia permanente

Um resultado verde é reconfortante. Eu ainda não trataria isso como um certificado que nunca expira.

Teste novamente após qualquer alteração que possa afetar o navegador ou a rede:

• Uma atualização do navegador
• Um novo servidor VPN ou proxy
• Uma mudança de extensão
• Uma nova rede
• IPv6 sendo habilitado
• Um novo perfil de navegador
• Uma política WebRTC diferente

Um teste de vazamento é um instantâneo de um navegador, rede e configuração. Isso é suficiente para tomar uma decisão útil. Não é uma garantia permanente de privacidade.

Como prevenir ou corrigir um Vazamento de WebRTC

Não existe uma solução única que se adapte a todos os navegadores e a todos os fluxos de trabalho. A escolha certa depende se as funções WebRTC precisam permanecer disponíveis.

Use uma VPN com proteção contra vazamentos testada

Uma VPN em nível de sistema pode proteger o tráfego WebRTC por meio de regras de roteamento e firewall. Verifique se o túnel dividido está ativo. Verifique o IPv6 também. Em seguida, execute o teste em vez de confiar no status conectado no aplicativo.

A marca da VPN importa menos do que o resultado observado no dispositivo e navegador que você realmente usa.

Restrinja o tráfego sem proxy ou use WebRTC somente retransmissão

Outra opção é impedir que o WebRTC use um caminho fora do proxy. Alguns controles bloqueiam UDP sem proxy. Outros forçam o tráfego através do proxy configurado.

Se o UDP não puder usar essa rota, o WebRTC poderá recorrer ao TCP ou TURN. Também pode falhar. O resultado depende da implementação.

WebRTC somente retransmissão usa candidatos TURN. Ele pode manter os candidatos diretos longe do colega remoto, ao mesmo tempo que mantém a comunicação em tempo real. A compensação é mais latência, mais tráfego de retransmissão e uma dependência mais forte da disponibilidade do TURN.

Altere as configurações do navegador ou use uma extensão

O Firefox oferece preferências avançadas que podem limitar ou desativar o WebRTC. Os navegadores baseados em Chromium geralmente dependem de extensões, políticas corporativas ou controles de rede no nível do navegador.

Extensões podem ajudar. Eles também precisam de cuidados. Uma extensão desatualizada pode parar de funcionar após uma atualização do navegador. Pode solicitar permissões amplas. Ele também pode se comportar de maneira diferente nas versões do navegador.

Se você usar um, escolha uma fonte mantida e teste o resultado novamente. O ícone na barra de ferramentas não é a evidência. O resultado da rede é.

Use controles WebRTC por perfil

As configurações globais tornam-se estranhas quando vários perfis usam proxies ou locais de rede diferentes. Cada perfil precisa de uma atribuição de proxy clara e de uma política WebRTC adequada à tarefa.

Um perfil não está pronto apenas porque seu proxy se conecta. Depois de configurar proxies em MoreLogin, confirme o IP visível e execute uma verificação WebRTC separada.

O MoreLogin documentação da API do perfil do navegador lista Privacidade, Substituição, Real, Desativado e Encaminhamento como opções WebRTC por perfil. Ele não explica completamente como cada modo lida com candidatos de host, STUN, TURN, UDP, IPv4 e IPv6.

O rótulo do modo por si só não é suficiente. Verifique o comportamento selecionado na versão atual do produto.

Você deve desativar o WebRTC?

Desabilitar o WebRTC pode fechar esse caminho de exposição de endereço. É também a opção com maior probabilidade de afetar os recursos normais do navegador.

O que a desativação do WebRTC impede

Quando RTCPeerConnection não está disponível, uma página não pode usar essa API para reunir os mesmos candidatos a conexão. Isso pode evitar um vazamento de IP baseado em WebRTC.

Isso não impede vazamentos de DNS. Ele não esconde a impressão digital do navegador. Não remove cookies ou dados da conta.

O que pode parar de funcionar

Os sites podem perder recursos que dependem do WebRTC, incluindo:

• Videochamadas no navegador
• Bate-papo por voz
• Compartilhamento de tela
• Transferência de arquivos ponto a ponto
• Widgets de colaboração e suporte em tempo real

Alguns serviços podem oferecer outra rota. Outros podem falhar ou perder qualidade.

Desativar, restringir ou retransmitir

Desative o WebRTC quando o perfil não precisar de comunicação em tempo real. Restrinja ou retransmita quando a função precisar permanecer disponível e o caminho da rede puder ser verificado.

Vazamento de WebRTC vs. Vazamento de DNS

Vazamentos de WebRTC e DNS são fáceis de confundir porque ambos podem enfraquecer uma configuração de privacidade. Eles expõem informações diferentes.

Ambos podem acontecer ao mesmo tempo. Consertar um não prova que o outro se foi.

Vazamentos de WebRTC e perfis de navegador isolados

A identidade da rede e a identidade do navegador ficam em camadas diferentes. Esta distinção torna-se importante quando os perfis são reutilizados ao longo do tempo.

Um proxy ou VPN controla a rota da rede. Uma política WebRTC controla como os candidatos à conexão são expostos ou retransmitidos. Um perfil de navegador contém cookies, armazenamento local, configurações do navegador e outros sinais.

As informações do WebRTC podem se tornar parte de uma impressão digital do navegador mais ampla, juntamente com a versão do navegador, fuso horário, fontes, saída do Canvas e comportamento do WebGL.

Mantenha os sinais de rede de cada perfil consistentes

Antes de utilizar um perfil, verifique as partes que devem estar de acordo:

• O proxy esperado ou IP público VPN
• O IP público WebRTC
• Exposição IPv6
• Comportamento de IP local ou mDNS
• Fuso horário e geolocalização
• Idioma do navegador

A consistência não torna um perfil invisível. Reduz incompatibilidades evitáveis ​​e torna os problemas mais fáceis de diagnosticar.

Verifique o perfil antes de trabalhos importantes

É tentador parar quando a verificação normal do IP parece correta. Encontrar um vazamento dias depois é frustrante e mais difícil de resolver.

Em MoreLogin, um perfil de navegador de várias contas mantém configurações de proxy, configuração de WebRTC, cookies, armazenamento e outros sinais de navegador em um ambiente reutilizável. Isso torna a configuração mais fácil de revisar. O resultado ainda depende das configurações, rede e proxy selecionados.

Teste um novo perfil antes de usá-lo. Teste novamente quando o proxy, a versão do navegador ou a política WebRTC mudarem.

Principais conclusões

• Um Vazamento de WebRTC é uma exposição inesperada de endereço de rede, e não o aparecimento de qualquer IP em um teste.
• O ICE pode coletar candidatos a retransmissão hospedeiros, derivados de STUN e TURN.
• Um teste útil compara o IP de linha de base do ISP com o resultado de VPN, proxy ou perfil.
• Desativar, restringir, usar proxy e WebRTC somente retransmissão têm diferentes compromissos de privacidade e compatibilidade.

Perguntas frequentes sobre Vazamento de WebRTC

O WebRTC sempre vaza seu Endereço IP real?

Não. O resultado depende do navegador, rede, VPN ou rota proxy, configuração IPv6 e política WebRTC. Uma configuração roteada corretamente pode mostrar apenas a VPN ou o IP do proxy. Uma configuração somente relé pode mostrar um endereço TURN.

O WebRTC pode ignorar uma VPN ou proxy?

Ele pode expor um endereço adicional quando o navegador tem permissão para usar outro caminho de rede. O tunelamento dividido, uma rota IPv6 desprotegida ou um proxy de navegador que não controla o tráfego WebRTC podem contribuir para esse resultado.

Um Endereço IP local é um Vazamento de WebRTC?

É a exposição de informações da rede local. Geralmente é menos direto do que revelar o IP público de um ISP. Seu valor depende do endereço, de sua estabilidade, das demais interfaces presentes e da forma como as informações são combinadas.

O que significa um endereço .local em um teste WebRTC?

Um endereço .local aleatório geralmente é um nome de host mDNS. Os navegadores modernos usam-no para evitar mostrar diretamente o IP do host local. Isso não significa que o IP público do ISP vazou.

Um site pode verificar o WebRTC sem permissão da câmera?

Uma página pode criar uma conexão peer ou canal de dados e acionar a coleta de candidatos ICE. O acesso à câmera e ao microfone ainda requer permissão de mídia relevante.

Desativar o WebRTC danificará sites?

Isso pode afetar videochamadas, bate-papo por voz, compartilhamento de tela, transferência de arquivos e outros recursos em tempo real. Alguns sites podem fornecer uma alternativa. Outros podem perder a função ou trabalhar com qualidade reduzida.

Com que frequência devo testar vazamentos de WebRTC?

Teste após alterar o navegador, VPN, proxy, extensão, rede, configuração IPv6, perfil do navegador ou política WebRTC. Um novo teste rápido pode detectar uma rota que mudou sem um aviso óbvio.

Mantenha as configurações de WebRTC e proxy organizadas

A proteção WebRTC funciona melhor quando é tratada como parte de toda a configuração do perfil. O proxy, o IP visível, a rota IPv6, o fuso horário, o idioma e a política WebRTC devem fazer sentido juntos.

Experimente MoreLogin gratuitamente para criar perfis de navegador reutilizáveis, definir as configurações de rede e do navegador separadamente e verificar cada ambiente antes de usar.