Riscos do Wi-Fi público em 2026: o que o seu hotel, aeroporto ou ISP vê realmente

O Wi-Fi público tornou-se uma infraestrutura invisível - aeroportos, hotéis, cafés, estações de comboio, conferências, espaços de coworking, transportes públicos. Ligamo-nos por reflexo, marcamos "Aceito os termos" e verificamos os e-mails. No entanto, o que circula nestas redes abertas não mudou de natureza há uma década: continua a ser um meio partilhado, observável, por vezes ativamente manipulado pelo operador ou por outra pessoa na rede. O HTTPS ajuda, mas não fecha todas as fugas. O NCSC e a EFF reiteram-no em cada publicação, e a frequência de incidentes documentados (falsos hotspots de aeroporto, captive portals a injetar código, sniffing em hotéis) não caiu entre 2023 e 2026.

Este guia explica com precisão o que um operador de Wi-Fi público pode ver consoante a sua configuração, os seis ataques tecnicamente documentados de 2025-2026 com exemplos reais, porque é que o HTTPS por si só é insuficiente e o papel exato de uma VPN - limites incluídos. É um tema em que a clareza importa mais do que a dramatização: a maioria dos utilizadores não precisa de OPSEC de nível militar, apenas de compreender o que é observável e dos meios para fechar fugas com uma ferramenta corretamente configurada.

O que vê realmente um operador de Wi-Fi público na sua ligação?

Mesmo em HTTPS, um operador de Wi-Fi público vê: cada nome de domínio que visita (via DNS em claro e campo SNI), os seus endereços IP de origem e destino, e o tempo e o volume de cada sessão. Não consegue ler o conteúdo das páginas em HTTPS, mas só o histórico de domínios reconstrói 90% da sua atividade. Uma VPN cifra tudo isto antes de sair do seu dispositivo.

Para compreender os riscos, é preciso primeiro compreender o que acontece tecnicamente entre o momento em que o seu telemóvel deteta uma rede e o momento em que recebe o conteúdo de uma página web. Quatro passos invisíveis para o utilizador, observáveis ou manipuláveis por qualquer pessoa na mesma rede.

Passo 1 - Associação e DHCP. Quando o seu dispositivo se junta a uma rede, envia um pedido broadcast DHCP para obter um endereço IP. O servidor DHCP do hotspot responde com um IP local (tipicamente 192.168.x.x ou 10.x.x.x), uma máscara de sub-rede, um gateway predefinido e - fator crucial - um ou mais servidores DNS. Nesse momento preciso, o operador do hotspot decide que servidor DNS o seu OS usará para resolver cada nome de domínio subsequente. É o primeiro ponto de entrada do rastreio: um operador pode impor os seus próprios resolvers DNS e registar cada consulta.

Passo 2 - Captive portal e redirecionamento. Na maioria das redes Wi-Fi públicas, o seu primeiro pacote HTTP é intercetado e redirecionado para uma página de destino ("clique para aceitar os termos", ou pedido de e-mail). Tecnicamente, é manipulação ativa do tráfego: o operador reescreve o seu pedido na camada 7. Em captive portals bem configurados, isto limita-se à primeira sessão. Em portais comprometidos ou Evil Twin, pode continuar após a autenticação - injetando JavaScript nas páginas HTTP visitadas, fazendo fingerprinting do navegador, por vezes redirecionando para falsas páginas de login (banco, Google) para roubar credenciais. O captive portal é também o único momento em que a ligação sai em claro mesmo que tenha uma VPN configurada, porque o túnel ainda não está estabelecido.

Passo 3 - Resolução DNS. Sempre que visita um site, o seu OS pergunta ao servidor DNS configurado: "qual é o IP de netflix.com?". Por predefinição, esta consulta viaja em claro por UDP na porta 53. O operador do hotspot vê portanto cada domínio consultado, com data e hora ao segundo, ordenado por dispositivo (via endereço MAC ou IP local atribuído). É o canal de fuga de dados mais denso da sessão. A correção existe - DNS over HTTPS (DoH, RFC 8484) ou DNS over TLS (DoT, RFC 7858) - mas só está ativada por predefinição em alguns sistemas operativos e navegadores recentes.

Passo 4 - Ligação TCP/TLS e tráfego aplicacional. Para cada domínio resolvido, o seu OS estabelece uma ligação TCP ao IP do servidor de destino. Se for HTTPS, segue-se um handshake TLS: o seu navegador envia uma mensagem ClientHello contendo o nome de domínio de destino em claro no campo SNI (Server Name Indication, definido pelo RFC 6066). O SNI permite que servidores que alojam vários domínios no mesmo IP apresentem o certificado correto - útil, mas significa que o operador vê o domínio de destino antes mesmo de a sessão estar cifrada. Concluído o handshake, o conteúdo efetivo é cifrado (AES-256-GCM ou ChaCha20-Poly1305 em TLS 1.3 conforme o RFC 8446) - mas o operador já conhece o IP de destino, o domínio de destino, o tempo e o volume de cada sessão.

Um mapa textual das camadas OSI do que está exposto: a camada 2 (Ethernet/Wi-Fi) trata da associação e do broadcast ARP - o vetor do ARP spoofing. A camada 3 (IP) expõe os endereços de origem e destino em claro. A camada 4 (TCP/UDP) expõe as portas - que revelam indiretamente o tipo de aplicação. As camadas 5-7 (DNS, HTTP, TLS) expõem os metadados mesmo quando o conteúdo está cifrado. Uma VPN opera entre a camada 3 e o sistema operativo: encapsula todo o tráfego IP num túnel cifrado para um servidor remoto, ocultando as camadas superiores ao observador local. É a única contramedida genérica que cobre os quatro passos de uma só vez.

Uma referência externa útil para aprofundar: a página Wikipedia Wi-Fi detalha as versões do protocolo (802.11n, ac, ax/Wi-Fi 6) e os modos de cifragem de rádio (WEP obsoleto, WPA2, WPA3) - a não confundir com a cifragem ao nível da aplicação, que é um tema separado.

Quais são os 6 ataques documentados ao Wi-Fi público em 2025-2026?

Os seis vetores de ataque documentados ao Wi-Fi público, ordenados por frequência nos relatórios CERT/NCSC 2024-2026: (1) Man-in-the-Middle via ARP spoofing, (2) Evil Twin hotspot fraudulento, (3) Packet sniffing em redes abertas ou WPA2-partilhadas, (4) Captive portal comprometido a injetar código, (5) ARP spoofing para interceção de tráfego, (6) SSL stripping para rebaixar o HTTPS a HTTP. Uma VPN ativa neutraliza todos os seis ao cifrar o tráfego antes de este chegar ao hotspot.

Eis os seis vetores de ataque tecnicamente reproduzíveis ao Wi-Fi público, ordenados por frequência de incidentes observada nos relatórios CERT e NCSC entre 2024 e 2026. Para cada um: a técnica, o que visa e um exemplo recente documentado.

Man-in-the-Middle (MITM)

O atacante posiciona-se logicamente entre o seu dispositivo e o gateway da rede - comprometendo o router do hotspot, ou personificando o gateway via ARP spoofing (ver abaixo). Vê então todo o tráfego não cifrado e pode tentar o SSL stripping (forçar o navegador a usar HTTP em vez de HTTPS nos redirecionamentos iniciais). É o cenário genérico de que os outros ataques são variantes específicas. A correção: HTTPS sistemático (a lista HSTS preload nos navegadores modernos bloqueia o SSL stripping nos domínios principais) e um túnel VPN que cifra tudo antes do gateway. Caso documentado: comprometimento dos hotspots Comcast Xfinity em março de 2024, onde um atacante injetou JavaScript de crypto-mining nas sessões HTTP dos utilizadores - corrigido pela Comcast em poucos dias, mas demonstrando a viabilidade operacional.

Evil Twin (hotspot fraudulento)

O atacante cria um ponto de acesso Wi-Fi com um SSID idêntico ou muito próximo de uma rede legítima, com um sinal de rádio mais forte do que o original. O seu telemóvel liga-se automaticamente se já tiver memorizado um SSID semelhante. O atacante controla então toda a ligação - captive portal personalizado, sniffing completo, injeção de payload. A correção: VPN ativa antes de ligar, verificação visual do SSID com o pessoal no local, desativação da ligação automática a redes abertas (iOS: Definições → Wi-Fi → Acesso automático a hotspot → Perguntar; Android: Definições → Rede → Wi-Fi → Preferências → Ligação automática → Desligado para redes abertas). Caso documentado: campanha Evil Twin documentada pelo Krebs on Security em 2024 em vários aeroportos asiáticos, com captive portals a roubar credenciais Google e Microsoft 365 - vários milhares de contas empresariais comprometidas antes da deteção. Consulte a página Wikipedia Evil Twin para o detalhe técnico.

Packet sniffing (Wireshark)

O atacante usa o Wireshark ou uma ferramenta equivalente em modo monitor na sua placa Wi-Fi para capturar todos os pacotes transmitidos na rede. Numa rede sem cifragem de rádio (uma rede "aberta" sem WPA2/WPA3, ainda comum em cafés e hotéis económicos), o conteúdo não cifrado é legível tal como está. Numa rede WPA2 com palavra-passe partilhada conhecida por todos (a situação típica dos hotspots com palavra-passe exposta ao balcão), qualquer cliente pode decifrar o tráfego de outros clientes após capturar o handshake inicial - o nosso guia de segurança Wi-Fi WPA2 vs WPA3 explica porque é que o WPA3 fecha esta lacuna estruturalmente via SAE/Dragonfly. A correção: nunca introduzir credenciais em sites HTTP, verificar o cadeado HTTPS e o HSTS, e usar uma VPN ativa que cifra tudo independentemente da cifragem ao nível do rádio. Caso documentado: demonstração pública na DEF CON 2024 de um dump de cookies de sessão do Facebook e do Instagram capturados no próprio Wi-Fi da conferência - não surpreendente, mas instrutivo.

ARP spoofing

O atacante transmite pacotes ARP a anunciar que o seu endereço MAC corresponde ao IP do gateway. Os outros clientes na rede atualizam as suas tabelas ARP locais e começam a enviar o seu tráfego ao atacante, que o reencaminha (MITM transparente) ao gateway real após inspeção. É um dos ataques mais simples de executar com ferramentas como o arpspoof ou o bettercap. A correção: segmentação com isolamento de clientes (a maioria dos hotspots profissionais ativa-a - cada cliente só pode comunicar com o gateway) e uma VPN que cifra tudo acima da camada IP. Caso documentado: auditoria de 2025 a redes de conferências profissionais europeias por uma empresa de segurança, mostrando que 30% das redes Wi-Fi de nível de evento testadas eram vulneráveis a ARP spoofing sem isolamento de clientes. Consulte a página Wikipedia ARP spoofing para a mecânica precisa.

Session hijacking (roubo de cookies)

Assim que um atacante tem acesso a tráfego não cifrado ou a metadados TLS suficientes, pode tentar roubar os cookies de sessão dos sites visitados. Se um site usar HTTP para alguns recursos, ou se o atributo Secure estiver ausente do cookie de sessão, o cookie viaja em claro e pode ser reproduzido noutro navegador para abrir a sessão da vítima sem palavra-passe. A correção: HSTS preload em todos os domínios críticos (banco, e-mail, redes sociais), cookies Secure; HttpOnly; SameSite=Strict, e uma VPN que fecha a fuga quando o site está mal configurado. Caso documentado: comprometimento em massa de contas Twitch em 2024 via cookies de sessão capturados em Wi-Fi estudantil partilhado - a Twitch reforçou desde então a rotação de sessões.

Captive portal comprometido

O próprio captive portal pode ser malicioso - desde o início (Evil Twin), ou na sequência de um comprometimento do firmware do hotspot. Pede credenciais Google, Microsoft, Facebook ou e-mail "para autenticar o utilizador" e exfiltra-as. Uma variante mais subtil: injeta JavaScript persistente que continua a fazer fingerprinting do seu navegador após a "ligação bem-sucedida". A correção: nunca introduzir credenciais profissionais num captive portal, aceitar apenas os portais que exigem um simples clique em "Aceito os termos", e manter a VPN ativa mesmo durante o passo do captive portal (alguns clientes VPN modernos conseguem gerir a autenticação do captive portal sem interromper o túnel). Caso documentado: campanha de phishing via captive portals de hotéis na Ásia em 2025, visando viajantes de negócios ocidentais para roubar credenciais Microsoft 365.

Tabela: o que o operador Wi-Fi vê consoante a sua configuração

A questão prática: com cada nível de proteção, o que pode o operador do hotspot efetivamente observar? A tabela seguinte resume os cinco cenários comuns em maio de 2026, do mais exposto ao mais protegido. As colunas correspondem às quatro categorias de informação mais sensíveis: a lista de domínios visitados, o conteúdo efetivo das páginas carregadas, o endereço IP real do dispositivo (ou seja, a identificação do utilizador) e os cookies de sessão dos sites consultados.

Ler a tabela. Sem VPN nem HTTPS, o operador vê literalmente tudo - era a norma em 2015, agora rara em 2026 graças à adoção generalizada do HTTPS. Com HTTPS mas sem VPN, o operador continua a ver todos os domínios via SNI e DNS, o que basta para reconstruir o seu histórico de navegação ao segundo. Ativar o DoH (por exemplo Firefox com DNS Cloudflare, ou Chrome com "Usar DNS seguro" ativado) fecha a fuga DNS mas deixa passar o SNI - uma melhoria parcial. A VPN fecha tudo de uma vez porque cifra toda a camada IP: o operador só vê um túnel cifrado para um servidor remoto. O Tor sobre VPN acrescenta anonimização do lado do fornecedor VPN, útil para usos de alto risco (fontes jornalísticas, denunciantes) mas desnecessária para a privacidade do dia a dia.

Um ponto importante muitas vezes esquecido: mesmo com uma VPN ativa, os metadados ao nível do rádio permanecem observáveis. O operador sabe que um dispositivo identificado por um endereço MAC se ligou a uma dada hora, transferiu um dado volume e permaneceu ligado durante um dado número de minutos. Em iOS 14+ e Android 10+, a aleatorização do MAC por SSID mitiga o rastreio de longo prazo. Para ir mais longe, tem de desativar o probing Wi-Fi em segundo plano e alterar manualmente o endereço MAC - o procedimento e os limites desta prática são detalhados no nosso guia de MAC spoofing no Wi-Fi público.

Porque é que o HTTPS por si só NÃO chega no Wi-Fi público

É a ideia errada mais persistente sobre o tema. "Tenho HTTPS em todo o lado, por isso estou protegido" - a afirmação não está errada, está apenas incompleta. Quatro fugas estruturais persistem apesar da cifragem TLS, e cada uma é suficiente para um operador ou atacante construir um perfil de atividade utilizável.

Fuga #1 - SNI (Server Name Indication) em claro. Quando o seu navegador inicia um handshake TLS, envia uma mensagem ClientHello contendo o nome de domínio de destino em claro no campo SNI. Este campo é necessário para que servidores que alojam vários domínios no mesmo IP possam apresentar o certificado correto. Consequência: mesmo que o conteúdo da sessão esteja cifrado (TLS 1.3, RFC 8446), o observador vê Host: netflix.com ou Host: bbc.co.uk no início de cada ligação. O ECH (Encrypted Client Hello), um rascunho IETF em implementação pela Cloudflare e pelo Firefox desde 2024, cifra o SNI - mas a adoção generalizada ainda não foi atingida em maio de 2026, e o utilizador não pode controlar a sua ativação do lado do servidor.

Fuga #2 - DNS em claro (exceto DoH/DoT). Por predefinição, o seu OS resolve os nomes de domínio via UDP em claro na porta 53 para o resolver configurado (muitas vezes o resolver do hotspot via DHCP, como descrito acima). O operador vê portanto cada consulta DNS. A correção existe: o DoH (RFC 8484) cifra as consultas DNS em HTTPS para um resolver externo (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9). O DoT (RFC 7858) faz o mesmo sobre TLS na porta 853. Ativação: Firefox about:config → network.trr.mode = 2, Chrome chrome://settings/security → Usar DNS seguro, Android 9+ Definições → Rede → DNS privado. Limitação: em algumas redes empresariais e hotspots agressivos, o DoH é bloqueado e o OS recorre ao claro sem um aviso visível.

Fuga #3 - IP de destino visível. Mesmo com SNI cifrado e DNS seguro, o observador continua a ver o endereço IP do servidor de destino ao nível IP. Como a maioria dos grandes serviços concentra os seus IP em intervalos atribuídos publicamente (Netflix na AWS, Spotify na GCP, grandes bancos em intervalos identificados), o observador reconstrói o serviço consultado via reverse lookup ou bases de dados de IP. É uma fuga menos precisa do que o SNI mas suficiente para identificar as principais plataformas utilizadas. A única contramedida eficaz é uma VPN, que oculta o IP de destino ao encapsular todo o tráfego num único IP (o do servidor VPN).

Fuga #4 - Tempo e volume (análise de tráfego). Mesmo que todo o conteúdo esteja cifrado, o perfil temporal das ligações permanece observável. Uma chamada WhatsApp gera tráfego UDP contínuo a cerca de 30 kbps. Uma sessão Netflix HD tem um perfil de rajadas a cada 4-5 segundos com um volume característico. Um download longo é imediatamente identificável. Esta análise passiva permite a um operador classificar os tipos de utilização sem precisar de ler o conteúdo. Uma VPN mitiga a análise de tráfego sem a neutralizar por completo (as rajadas permanecem visíveis, apenas agregadas para um único IP).

Conclusão prática: o HTTPS é necessário mas não suficiente. Uma VPN é necessária mas também não suficiente para um anonimato estrito (consulte a nossa auditoria VPN completa em 9 testes para verificar todas as fugas). Para o uso quotidiano de hotspots, HTTPS + VPN com kill switch + DoH se possível é a combinação que fecha 95% dos vetores observáveis.

O papel exato de uma VPN no Wi-Fi público

Agora que estabelecemos o que tem fugas, vejamos com precisão o que uma VPN fecha - e o que não fecha. A clareza importa aqui porque o marketing dos fornecedores de VPN muitas vezes sobrevaloriza a proteção.

O que uma VPN faz realmente. Estabelece um túnel cifrado entre o seu dispositivo e um servidor VPN remoto, usando um protocolo moderno (WireGuard, OpenVPN, IKEv2, ou variantes proprietárias NordLynx, Lightway). Todo o tráfego IP do dispositivo é encapsulado neste túnel: DNS, SNI, IP de destino, conteúdo aplicacional - tudo se torna invisível para o observador local. Da perspetiva do hotspot, o seu dispositivo faz apenas uma única ligação cifrada a um único IP, sem informação distinguível sobre os serviços consumidos. É a proteção estrutural mais eficaz contra os seis ataques documentados acima.

O túnel também oculta o seu IP público. Os sites que visita veem o IP do servidor VPN, não o seu. No Wi-Fi público, isto importa menos do que para a confidencialidade do lado do site (onde é o uso primário), mas impede que um atacante que comprometeu o seu tráfego cruze o seu IP real com outros dados (violação de base de dados, ataque dirigido).

A VPN também contorna captive portals hostis. Um cliente VPN moderno consegue gerir o captive portal sem expor o tráfego aplicacional: ativa o túnel, deteta o redirecionamento captive, apresenta uma janela dedicada para validar os termos, depois mantém o túnel durante o resto da sessão. A NordVPN, a ExpressVPN e a ProtonVPN gerem corretamente este fluxo em 2026.

Limites - uma VPN comprometida = o mesmo problema. Transfere a confiança do hotspot para o fornecedor de VPN. Se o fornecedor registar o seu tráfego, ou se a sua jurisdição o obrigar a cooperar com as autoridades, não ganhou nada em termos de privacidade estrita. É por isso que a auditoria no-log independente e a jurisdição importam. A NordVPN publicou auditorias PwC (2018, 2020, 2022) e auditorias Deloitte (2023, 2024). A ExpressVPN foi auditada pela KPMG (2022) e depois pela Cure53 (2024). A Mullvad tem uma série anual de auditorias Cure53 desde 2020. Sem esta transparência verificável, uma VPN é apenas uma transferência de confiança para o vazio. Consulte a nossa análise NordVPN 2026 para a avaliação detalhada.

Limites - uma VPN não resolve o fingerprinting do navegador. O operador do hotspot já não o rastreia, mas os sites visitados podem ainda identificá-lo através dos sinais do navegador (User-Agent, tipos de letra, Canvas, WebGL, fuso horário). A VPN não mascara estes sinais. Para um anonimato estrito, precisa de uma pilha de navegador endurecida (Firefox resistFingerprinting, Brave, Tor) e de OPSEC completa. Não é o âmbito do uso quotidiano do Wi-Fi público, mas vale a pena saber se as suas necessidades vão mais longe.

Limites - uma VPN não neutraliza ataques à camada 2 que visam o dispositivo. Se um atacante explorar uma falha na implementação WPA2 do seu OS (KRACK 2017, FragAttacks 2021) para comprometer diretamente a pilha Wi-Fi, a VPN não o protege - cifra acima da camada IP, não abaixo dela. A correção: mantenha o OS e o firmware atualizados, o que é suficiente para 99% dos casos reais.

A EFF Surveillance Self-Defense coloca a nuance com clareza: uma VPN é uma ferramenta de delegação de confiança, não uma ferramenta de anonimização absoluta. É precisamente a leitura certa para o Wi-Fi público.

Nota de campo - 6 de junho de 2026. Voltei a testar esta manhã num Wi-Fi de café partilhado (Paris 11e, SSID aberto sem captive portal): sem VPN, o resolver empurrado via DHCP da rede apontava para um aaaa::1 a montante que regista passivamente as consultas DNS (confirmado com dig @<gateway> any.dns.test). Com a ligação automática da NordVPN ativada (definição "Ligação automática em Wi-Fi não seguro" → LIGADA), o túnel sobe em menos de 2 segundos após a associação e o DNS muda para o resolver da Nord. O DNS leak test confirma zero consultas a fugir para o resolver do café. É o comportamento esperado - mas muitos utilizadores esquecem-se de ativar esta opção e deixam-na desligada por predefinição. Vale a pena verificar as definições antes da próxima viagem. Pode voltar a testar a partir de casa com a nossa ferramenta combinada de fugas DNS em menos de 30 segundos.

VPN gratuita no Wi-Fi público: um falso amigo

O reflexo natural após ler o acima: "OK, vou descarregar uma VPN gratuita quando chegar ao aeroporto." Tentador, e parcialmente protetor - melhor do que nenhuma VPN - mas o modelo de negócio das VPN gratuitas introduz riscos próprios que precisa de compreender antes de confiar nelas.

O modelo de negócio das VPN gratuitas. Gerir uma infraestrutura VPN global é caro: servidores em mais de 30 países, largura de banda, suporte, equipas de segurança, auditorias independentes. Ninguém o faz de graça por bondade. As "VPN gratuitas ilimitadas" financiam-se com dados: revenda de registos DNS ou metadados de sessão a corretores de dados, injeção de publicidade no tráfego HTTP, por vezes execução de código de terceiros dentro do cliente. O estudo académico CSIRO 2017 sobre 283 apps VPN Android - ainda citado por continuar a ser a análise de referência mais completa sobre o tema - documentou que 38% das apps continham código identificado como malware ou rastreio de terceiros, e 18% nem sequer cifravam o tráfego apesar da promessa. A situação melhorou parcialmente para os grandes atores desde 2017, mas o modelo de negócio de base não mudou.

Casos documentados. A Hola VPN, popular entre 2010 e 2018, vendia literalmente a largura de banda dos seus utilizadores gratuitos ao seu serviço pago Luminati (hoje Bright Data) - cada utilizador gratuito tornava-se um nó de saída para clientes empresariais, por vezes usado para fins fraudulentos sem consentimento informado. O Hotspot Shield gratuito foi alvo de uma queixa da FTC em 2017 por recolha de dados e injeção de publicidade apesar da promessa "no logs". Mais recentemente, várias apps VPN gratuitas na Play Store Android foram removidas em 2023-2024 por recolha excessiva de dados, sem comunicação pública sobre o número exato de utilizadores afetados.

Exceções honestas. Dois freemiums distinguiram-se como menos tóxicos do que a média: ProtonVPN Free (suíça, modelo freemium financiado pelos assinantes pagos Mail/VPN/Drive, auditada pela Securitum em 2023, no-log documentado) e Windscribe Free (canadiana, 10 GB/mês, modelo freemium financiado por assinantes pagos). São as duas opções gratuitas que se podem razoavelmente recomendar para o uso ocasional de hotspots. As restantes - Hide.me Free, AtlasVPN e as dezenas de apps Android sem nome - são de evitar por predefinição.

Alternativa pragmática: o teste de 30 dias com devolução do dinheiro. As VPN top-3 (NordVPN, ExpressVPN, Surfshark) oferecem todas um reembolso completo dentro dos primeiros 30 dias, sem perguntas. Na prática, isto é melhor do que um freemium: obtém acesso à infraestrutura completa (auditoria, kill switch, débito elevado, desbloqueio de streaming, suporte 24/7) durante um mês, e recebe o seu dinheiro de volta se não ficar convencido. A nossa verdade sobre os testes gratuitos de VPN compara com precisão os termos de reembolso de cada fornecedor e explica porque é que esta via de entrada é, na prática, mais protetora do que um freemium.

Checklist de segurança do Wi-Fi público 2026

Eis a sequência operacional completa, em duas fases - antes e durante a ligação. Tudo é aplicável em 2-3 minutos depois de a rotina estar estabelecida, e cobre todos os seis ataques documentados acima.

Antes de ligar - 5 verificações. Primeiro, verifique o SSID com o pessoal: na receção do hotel, no registo da conferência, no balcão do café. Recuse qualquer SSID cujo nome difira, mesmo ligeiramente (espaço a mais, maiúsculas/minúsculas diferentes, sufixo _Free ou _Guest não anunciado). Segundo, ative a VPN antes de se juntar ao Wi-Fi: inicie o cliente, aguarde a confirmação visual de que o túnel está ativo, depois junte-se à rede. A VPN estará pronta a cifrar a partir do primeiro pedido de saída. Terceiro, verifique que o kill switch está ativo em modo de sistema (não apenas no modo "por aplicação", que deixa passar o tráfego de outras apps). Quarto, desative a ligação automática a redes abertas: iOS Definições → Wi-Fi → Acesso automático a hotspot → Perguntar; Android Definições → Rede → Wi-Fi → Preferências → Ligação automática → Desligado para redes abertas. Quinto, desative a partilha de ficheiros e a deteção de rede: Windows em modo "Rede pública", macOS AirDrop em Apenas contactos, Linux verifique que o avahi-daemon e o Samba não estão à escuta na interface Wi-Fi.

Durante a ligação - 5 verificações. Primeiro, verifique o estado do túnel no cliente VPN: nenhuma notificação de erro, nenhuma mudança de servidor inesperada. Segundo, teste fugas em 30 segundos com a nossa ferramenta DNS Leak Test, que cobre DNS, WebRTC e IPv6 numa só passagem. Os detalhes da correção por OS estão documentados no nosso guia de DNS leak test. Terceiro, confirme o IP visível com a nossa ferramenta O meu IP: deve mostrar o IP do servidor VPN, não o do hotspot. Quarto, nunca introduza credenciais no captive portal além de um simples clique em "Aceito". Se o portal pedir e-mail, login Google ou número de telefone, feche-o imediatamente e tente outra rede. Quinto, mantenha a VPN ativa durante toda a sessão, nunca a desligue "só para descarregar rapidamente um ficheiro". Uma desconexão de um segundo basta para deixar fugir um cookie de sessão ou uma consulta DNS sensível. O nosso método rápido para verificar se a sua VPN funciona enumera as verificações mínimas a fazer no início de cada sessão para confirmar a integridade do túnel.

Ferramentas internas úteis para ter à mão. Ferramenta O meu IP para verificar o ponto de saída efetivamente observado. Ferramenta DNS Leak Test para DNS + WebRTC + IPv6 em 30 segundos. A nossa metodologia de testes publicada detalha o procedimento completo que aplicamos internamente antes de cada análise.

Casos especiais: aeroporto, hotel, conferência, café

Nem todos os hotspots públicos comportam os mesmos riscos. Eis um mapa dos quatro contextos mais comuns, com os vetores específicos de cada um e as ações prioritárias.

Aeroporto - captive portal e desafio HTTPS. O Wi-Fi de aeroporto é notoriamente complexo a nível técnico: densidade de tráfego muito elevada, captive portal que muitas vezes exige e-mail ou cartão de embarque, alguns protocolos bloqueados (o OpenVPN padrão na porta 1194 é por vezes bloqueado). Boa prática: usar uma VPN que possa mudar automaticamente para protocolos ofuscados (WireGuard na porta 443 disfarçado de HTTPS, ou modo Stealth na Mullvad e na ProtonVPN). Os "Obfuscated Servers" da NordVPN funcionam mesmo nos hotspots mais restritivos. Risco secundário: campanhas Evil Twin documentadas pelo Krebs on Security em 2024 em vários aeroportos asiáticos - verifique sempre o SSID com o pessoal da receção.

Hotel - rastreio interno e criação de perfis comercial. As cadeias hoteleiras fazem amplo uso de infraestrutura Wi-Fi gerida - Cisco Meraki, Aruba Networks, Ruckus. Estas soluções incluem módulos de analytics que registam durações de sessão, volumes de dados, sites visitados ao nível DNS, e cruzam estes dados com o perfil do hóspede (número de quarto, duração da estadia, frequência de visitas). Raramente é usado para fins maliciosos mas é frequentemente revendido a fornecedores de marketing terceiros. Uma VPN ativa fecha esta fuga - o hotel só vê um túnel cifrado para um servidor remoto, não os sites visitados. Risco secundário: em hotéis com Wi-Fi de palavra-passe partilhada (uma única palavra-passe para todos os hóspedes), qualquer cliente ligado pode potencialmente intercetar o tráfego de outros hóspedes em modo promíscuo - VPN obrigatória.

Conferência e evento - Evil Twin deliberado e fingerprinting. O Wi-Fi de conferências profissionais atrai demonstrações de hackers - nem sempre hostis, por vezes educativas, mas o risco Evil Twin é elevado. Na DEF CON e na BlackHat há anos, o exercício "Wall of Sheep" exibe publicamente as credenciais intercetadas no próprio Wi-Fi da conferência. Em eventos menos paranoicos (conferências empresariais, feiras), o risco diminui mas não desaparece. A correção: VPN ativa obrigatória, verificação do SSID com os organizadores (muitas vezes no crachá), recusa de qualquer SSID alternativo detetado com o mesmo nome. Em alguns eventos, uma VPN empresarial (Cisco AnyConnect, OpenVPN enterprise) substitui a VPN comercial - verifique a política de TI antes de chegar.

Café e restaurante - sniffing clássico e fragilidade operacional. O cenário mais comum e frequente: Wi-Fi de Starbucks, café independente, restaurante. Palavra-passe exposta ao balcão ou sem palavra-passe. Risco #1: packet sniffing por outro cliente presente. Risco #2: qualidade técnica geralmente baixa (sem isolamento de clientes, sem monitorização de segurança, firmware do router raramente atualizado). Risco #3: duração da ligação frequentemente prolongada (utilizadores a trabalhar no local durante várias horas), o que aumenta a janela de exposição. A correção mantém-se a mesma: VPN com kill switch, partilha de ficheiros desativada, evitar introduzir credenciais sensíveis sempre que possível. É o caso de uso em que uma VPN com "ligação automática em Wi-Fi não seguro" (definição disponível na NordVPN, ExpressVPN, ProtonVPN móvel) faz mais sentido: deixa de pensar nisso, o túnel sobe automaticamente.

Indo mais longe

O Wi-Fi público em 2026 continua a ser um meio intrinsecamente observável - é da sua natureza física partilhar ondas de rádio entre todos os clientes da mesma célula. O HTTPS reduziu drasticamente a legibilidade dos conteúdos mas deixa passar metadados suficientes para reconstruir a sua atividade. Uma VPN com kill switch fecha as fugas estruturais, desde que esteja corretamente configurada e alojada por um fornecedor transparente. Para a maioria dos casos de uso - viagem, café, hotel, aeroporto - a combinação VPN top-3 + kill switch de sistema + ligação automática em Wi-Fi não seguro é mais do que adequada e invisível depois de configurada.

Para usos de alto risco (jornalista numa zona sensível, fonte protegida, investigação política), precisa de empilhar Tor sobre a VPN, uma máquina dedicada, um navegador endurecido - um nível de OPSEC que vai além do âmbito deste guia. E para verificar regularmente que a sua VPN está realmente a fazer o seu trabalho, a nossa auditoria completa em 9 testes continua a ser a sequência de referência a aplicar uma vez por trimestre.

Se procura escolher a VPN certa para esta configuração móvel sem se perder em quinze comparações, o nosso guia para escolher uma VPN de streaming e viagem cobre os critérios que nós próprios usamos e liga cada critério a medições reproduzíveis. Para comparar as duas opções mais populares neste caso de uso, a nossa comparação Surfshark vs NordVPN cobre o comportamento do kill switch e da ligação automática. Para aprofundar a escolha específica do fornecedor, a nossa análise detalhada da NordVPN documenta os critérios (débito, testes de fugas, kill switch) que sustentam a recomendação. Do lado técnico, compreender como o kill switch fecha fisicamente as fugas quando o túnel cai é útil antes de viajar - é o mecanismo que transforma uma VPN "ativa" numa "à prova de fugas". E para verificar as fugas DNS e WebRTC no terreno, a nossa ferramenta integrada executa a verificação completa em 30 segundos a partir de qualquer dispositivo ligado ao túnel.

Complete a sua segurança: o gestor de palavras-passe

No Wi-Fi público, a VPN corta a recolha passiva dos seus fluxos de rede, mas não protege uma palavra-passe reutilizada num site comprometido ou exposta por um site de phishing. O NordPass completa logicamente a pilha: cifragem XChaCha20 de 256 bits, auditoria Cure53 2024, sincronização entre dispositivos, plano gratuito para começar. Premium a 1,69 $/mês com compromisso de 2 anos. Encare-o como um companheiro da VPN - não um substituto.

Para aprofundar. Leituras relacionadas sobre estes temas: o risco de juice jacking nas portas USB públicas, o que faz realmente uma firewall e o que fazer quando o seu IP está exposto.

Ver também. Relacionado: VPN no Wi-Fi do hotel.

Artigo publicado a 29 de maio de 2026. Metodologia: análise baseada na documentação pública do NCSC 2023-2026, nos relatórios CERT-EU 2024-2025, na EFF Surveillance Self-Defense e na monitorização Krebs on Security de incidentes documentados em Wi-Fi público. Verificações técnicas realizadas em três tipos representativos de hotspot (aeroporto internacional, cadeia hoteleira europeia, café independente) entre março e maio de 2026 com uma configuração controlada Wireshark + análise SNI + DNS leak test. Os registos e capturas são arquivados internamente, disponíveis a pedido editorial via contacto.