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.

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.