Riscos de Wi-Fi público em 2026

Riscos de Wi-Fi público: o artigo padrão sobre isso tem sido aproximadamente o mesmo desde 2014. Hackers em cafés! Sniffando seus pacotes! Roubando suas senhas de banco! Compre uma VPN! Maioria disso já não é precisa. Implantação de HTTPS matou os ataques fáceis. As ameaças que permanecem são reais e diferentes, e os conselhos prontos não acompanharam.

Esta é a visão de 2026 sobre riscos de Wi-Fi público. O que é genuinamente perigoso, o que é principalmente hype, onde WPA3 ajudou, o que HTTPS não protege, e as camadas defensivas reais. Menos alarmismo, mais precisão.

De onde os conselhos antigos vieram

Guias de ataque de Wi-Fi público de 2010-2016 assumiam algumas coisas que eram verdade na época:

• Maioria dos sites era HTTP por padrão. Um observador passivo na rede podia ler formulários de login, cookies, e conteúdos de página.
• Avisos de navegador sobre problemas HTTPS eram inconsistentes. Usuários clicavam por avisos de certificado rotineiramente.
• Ataques no nível de rede (envenenamento ARP, evil twin) eram fáceis com ferramentas prontas (Firesheep, o Pineapple). Qualquer um com notebook e software grátis podia montar.

Naquele ambiente, o conselho "use VPN em Wi-Fi público" era essencialmente correto. O risco autônomo era alto o suficiente que mesmo atacantes casuais causavam dano real.

O mundo mudou. No fim dos anos 2010, cobertura HTTPS da web aberta cruzou 80%. Navegadores pararam de deixar usuários clicarem por avisos de certificado sem override explícito. Bancos, redes sociais, provedores de e-mail todos foram pra apenas-HTTPS com HSTS. A superfície de ataque pra a versão fácil de sniffing de Wi-Fi público colapsou.

O que HTTPS lida agora

Em 2026, mais de 95% da web é HTTPS. Pra uma sessão típica de navegação em Wi-Fi público:

• Conteúdos de página são criptografados. Um observador de rede não pode ler a página que está vendo, o formulário que está submetendo, ou os cookies que manda.
• Tokens de autenticação são criptografados. Os cookies de sessão que teriam sido o roubo fácil na era Firesheep estão dentro de TLS. Lê-los do fio não é viável.
• Identidade do servidor é verificada. O handshake TLS autentica o destino. Um homem-no-meio teria que ou pegar certificado válido pro destino (difícil) ou enganar você a aceitar um inválido (navegadores não deixam mais fazer isso casualmente).

O enquadramento "veja sua senha do banco ser roubada" comum em anúncios velhos de VPN está principalmente obsoleto. Bancário é apenas-HTTPS. O navegador vai recusar conectar com certificado inválido. A superfície de ataque pra esse cenário específico encolheu dramaticamente.

O que HTTPS não lida

As ameaças são diferentes agora, não foram. Especificamente:

SNI é texto plano

O handshake TLS inclui o hostname de destino (Server Name Indication) em texto plano. Um observador de rede vê nytimes.com mesmo que não possa ler o artigo. Aprende quais sites você visita, quando, em que ordem, por quanto tempo.

Encrypted Client Hello (ECH) corrige isso. Cloudflare, Mozilla, e Google suportam. Maioria da web ainda não, em 2026. SNI é texto plano pra maioria dos sites que você visita.

DNS é texto plano

Antes do seu navegador poder conectar a um site, tem que resolver o nome. DNS texto plano vai pra qualquer resolver que o operador de rede configurou, geralmente o servidor DNS do operador. Veem todo domínio que você resolve. Alguns captive portals interceptam e modificam respostas DNS pra te redirecionar.

DNS-over-HTTPS (DoH) e DNS-over-TLS (DoT) corrigem isso. Firefox faz DoH por padrão em algumas regiões. Chrome faz pra resolvers conhecidos capazes de DoH. Maioria dos usuários na maioria das plataformas ainda manda DNS texto plano ao operador de rede.

Forma do tráfego

Mesmo com tudo mais criptografado, tamanhos de pacote e padrões de timing vazam informação. Carregar um vídeo específico do YouTube tem fingerprint reconhecível de requisições de segmento. Stream de episódio Netflix tem outro. Um observador sofisticado com ferramentas de análise de tráfego pode identificar sites específicos e até vídeos específicos da forma do tráfego, especialmente pra destinos de alto tráfego.

Isso é raro pra usuários individuais em Wi-Fi de café. É real pra adversários no nível de Estado em redes de escala nacional.

IP de destino

Mesmo DNS criptografado não esconde o IP de destino. Roteadores ao longo do caminho veem porque têm que encaminhar pacotes. Pra sites em infraestrutura dedicada, o mapeamento IP-pra-domínio é trivialmente derivável.

O que é realmente perigoso em Wi-Fi público em 2026

As ameaças realistas hoje, ranqueadas por probabilidade:

1. Pontos de acesso evil twin

Um ponto de acesso falso transmite um nome de rede idêntico a um legítimo ("Hotel-Guest", "Aeroporto-WiFi-Grátis", "Starbucks"). Seu dispositivo conecta, frequentemente automaticamente porque lembra o SSID de uma visita anterior. O atacante controla a rede e pode interceptar seu tráfego.

Por que ainda funciona em 2026: WPA3 mitiga alguns ataques mas não previne falsificação de SSID. Clientes Wi-Fi ainda confiam em SSIDs. Maioria das redes públicas é aberta ou baseada em PSK, nenhuma das quais previne falsificação. Wi-Fi corporativo moderno usa autenticação baseada em certificado que previne, mas Wi-Fi consumidor não.

O que um evil twin pode fazer: ver todo seu tráfego não criptografado (principalmente DNS), te servir um captive portal que injeta conteúdo, tentar MITM de conexões TLS (que principalmente falha por causa de validação de certificado, mas funciona contra clientes mal configurados), e logar todos metadados sobre sua atividade.

O que não pode fazer: ler seu conteúdo HTTPS, ler conteúdo do seu túnel VPN, ou substituir certificados TLS que você confia.

2. Captive portal MITM

Redes de hotel e aeroporto usam captive portals: redirecionamentos HTTP a uma página de aterrissagem onde você aceita termos ou paga por acesso. O mecanismo de captive portal inerentemente faz MITM em pelo menos uma conexão HTTP, porque é como o redirecionamento funciona.

Alguns captive portals vão além. Injetam scripts em páginas HTTP. Servem conteúdo modificado. Rodam analytics que logam todo domínio que você conecta. Foram documentados vendendo dados de navegação e revendendo dados de query DNS.

Uma VPN contorna captive portal MITM limpamente: uma vez que o túnel está ativo, o captive portal vê só bytes criptografados. O desafio é que captive portals geralmente requerem rede funcionando pra autenticar, e você precisa autenticar antes que a VPN possa estabelecer o túnel. Padrão padrão: conecte à rede, autentique no captive portal, depois imediatamente levante a VPN.

3. Coleta de dados pelo operador da rede

Redes de hotel, redes de aeroporto, e serviços de Wi-Fi público rotineiramente logam metadados de conexão: todo domínio resolvido, todo IP conectado, hora, duração, contagens de byte. Alguns vendem esses dados a data brokers. Alguns entregam a programas de vigilância governamental. Alguns só guardam indefinidamente sem política.

Isso não é hipotético. Exemplos documentados incluem:

• Grandes redes de hotel foram pegas rodando deep packet inspection que perfila tráfego de hóspede.
• Redes de aeroporto foram pegas logando DNS e SNI TLS pra parceiros de marketing e vigilância.
• Provedores de Wi-Fi de cafeteria (os contratantes da franquia, não as lojas individuais) têm práticas similares de dados.

Uma VPN move a fronteira de confiança do operador da rede pro seu provedor de VPN. Se isso é melhoria depende de quanto você confia em cada um. Pra maioria dos usuários, uma VPN paga com política de privacidade real é mais confiável que o operador aleatório de rede de hotel.

4. Tentativas de bypass de pinning de certificado pelo captive portal

Alguns captive portals tentam MITM HTTPS te fazendo instalar um certificado. Isso é raro em redes públicas (é uma red flag óbvia e maioria dos usuários recusa) mas acontece ocasionalmente em redes gerenciadas (redes de hotel, locais de conferência, redes de empregador). Se você instala o certificado, o operador de rede pode MITM todas suas conexões TLS. Não instale certificados de redes que você não controla.

5. Roteadores de consumidor comprometidos

Algum Wi-Fi público roda em roteadores de consumidor que foram comprometidos por malware. O malware redireciona DNS pra servidores de injeção de anúncios, redireciona domínios bancários específicos pra páginas de phishing, ou instala monitoramento persistente. Isso é mais comum em hotéis e apartamentos de aluguel onde o equipamento é mais velho e raramente atualizado.

Uma VPN contorna isso inteiramente uma vez que o túnel está ativo.

O que é principalmente hype

Alguns itens que são citados mas são menos risco real em 2026:

Sniffing de pacote de senhas texto plano

A demo clássica Firesheep / aircrack-ng era assustadora em 2010 porque maioria dos sites mandava dados de login em texto plano. Em 2026, os destinos que importam (bancos, e-mail, redes sociais, serviços de streaming) são apenas-HTTPS com HSTS. O ataque não funciona contra sites modernos.

Espionagem por Wireshark

Sim, Wireshark funciona. Captura tráfego. O que captura é principalmente criptografado por TLS, com o vazamento de metadados já discutido (SNI, DNS, IP). A demo "veja meu e-mail ser roubado em Wi-Fi público com Wireshark" não funciona mais contra serviços modernos. A versão de análise de tráfego disso é real mas requer mais sofisticação que um atacante casual traz.

"Hackers" no sentido casual

A imagem de alguém num moletom num café roubando seus dados com notebook está principalmente desatualizada. O atacante casual perdeu maior parte da superfície de ataque. As ameaças que permanecem são:

• Vigilância no nível de operador de rede (coleta de dados, MITM pelo próprio operador).
• Atacantes sofisticados (evil twin, análise de tráfego), que existem mas são raros.
• Adversários no nível de Estado, que existem pra alguns usuários mas não são o cenário do café com Wi-Fi público.

WPA3 e o que mudou

Status de implantação de WPA3 em 2026:

• WPA3 Enterprise está amplamente implantado em redes empresariais modernas (corporativas, universitárias, governamentais). Usa autenticação baseada em certificado e é significativamente mais segura que WPA2.
• WPA3-Personal pra casa e pequena empresa é menos universalmente implantado. Roteadores mais novos suportam. Clientes mais antigos (qualquer coisa pré-2019 tipicamente) não, então maioria das redes cai em modo misto WPA2.
• Hotspots públicos estão em grande parte ainda abertos ou WPA2-PSK em 2026. A transição foi lenta porque requer atualizações de roteador e cliente, e o mercado consumidor atualiza devagar.

O que WPA3 corrige que afeta Wi-Fi público: adiciona Simultaneous Authentication of Equals (SAE), que torna ataques offline contra a senha da rede muito mais difíceis. Pra redes genuinamente abertas (sem senha), WPA3 tem Opportunistic Wireless Encryption (OWE), que criptografa o link Wi-Fi mesmo em redes sem chave compartilhada.

O que WPA3 não corrige: falsificação de SSID (ataques evil twin), captive portal MITM, coleta de dados pelo operador da rede. WPA3 protege o link de rádio ao ponto de acesso. Não te protege contra o operador desse ponto de acesso.

As camadas defensivas que importam

Em ordem aproximada de importância pra Wi-Fi público em 2026:

1. HTTPS-Everywhere por padrão

Navegadores modernos (Firefox, Chrome, Safari, Edge) usam HTTPS por padrão. Alguns têm modo que recusa HTTP inteiramente. Habilite. Firefox tem "HTTPS-Only Mode". Chrome tem "Always Use Secure Connections". Safari tem embutido.

Isso lida com 95% da superfície fácil de ataque de Wi-Fi público de graça.

2. DNS-over-HTTPS

Criptografa suas queries DNS pra que o operador da rede não possa lê-las ou redirecioná-las. Firefox faz por padrão em algumas regiões. Chrome faz quando seu resolver configurado suporta DoH. Configure seu DNS do SO pra um resolver capaz de DoH (Cloudflare 1.1.1.1, Google 8.8.8.8, NextDNS, Quad9) pra proteção em todo o sistema.

Isso lida com o vetor de vazamento DNS e os ataques de redirecionamento DNS.

3. Uma VPN

Os vetores restantes (SNI texto plano, logging de tráfego no nível IP, ataques evil twin, vigilância pelo operador da rede, análise de forma de tráfego) são melhor mitigados por um túnel VPN. Uma vez que o túnel está ativo, o operador da rede vê só bytes criptografados fluindo pro servidor VPN.

Uma VPN é a única camada defensiva mais efetiva pra Wi-Fi público em 2026 porque cobre tudo que HTTPS não cobre. Temos uma peça em VPN pra Wi-Fi de hotel e avião que entra no caso de uso específico.

O kill switch importa aqui. Se a VPN cai, seu tráfego não deveria vazar. Temos uma peça mais profunda em kill switches explicados.

4. Senso comum sobre redes

Não conecte a redes que não reconhece. Não autoconfie numa rede só porque o SSID combina com lugar onde já esteve (ataques evil twin dependem disso). Verifique o nome da rede com o local se importa. Não instale certificados de redes que não controla.

Cenários específicos

Wi-Fi de hotel

Pior categoria. Redes de hotel têm histórico longo e documentado de: vigilância, vendas de dados, injeção de captive portal, deep packet inspection, e isolamento fraco de rede entre hóspedes. Use VPN. Temos uma peça mais profunda em Wi-Fi de hotel especificamente.

Wi-Fi de aeroporto e avião

Aeroporto: questões similares a hotel. Use VPN. Avião: mesmo plus a restrição de que conexões satélite podem ser lentas e o captive portal frequentemente bloqueia qualquer coisa além de HTTP e HTTPS em portas padrão. WireGuard sobre UDP frequentemente funciona. OpenVPN sobre TCP 443 é o fallback. VLESS Reality sobre TCP 443 também funciona e é o mais confiável em captive portals agressivos.

Wi-Fi de café

Risco mais baixo que hotel porque o operador de rede (o franqueado do café) geralmente é menos profissional sobre coleta de dados. Ainda: SNI é visível, DNS pode ser interceptado, e ataques evil twin são possíveis em áreas movimentadas. Uma VPN é razoável. HTTPS mais DoH é o mínimo.

Wi-Fi de conferência

Frequentemente bem gerenciado (Wi-Fi empresarial real com WPA3-Enterprise) ou terrivelmente gerenciado (quem rodou Ethernet a um ponto de acesso de consumidor). Difícil dizer de fora. Padrão pra uma VPN.

Wi-Fi de biblioteca e universidade

Frequentemente roda detecção de intrusão que pode sinalizar conexões VPN. A VPN ainda funciona na maioria dos casos. Se sua biblioteca ou universidade tem política de bloqueio de VPN e fiscaliza, isso é seu próprio problema pra navegar.

Setup prático

Pra maioria dos usuários, um setup defensivo razoável de Wi-Fi público se parece com:

1. Modo HTTPS-only do navegador habilitado.
2. DNS-over-HTTPS configurado no nível do SO (ou no Firefox se só navega).
3. Uma VPN com kill switch, configurada pra autoconectar em redes não confiáveis.
4. Suporte a cliente WPA3 habilitado (o SO lida; dispositivos modernos já fazem).
5. Seleção de rede desligada pra SSIDs públicos que não usa ativamente (pra que seu dispositivo não autoconecte a evil twins de "Starbucks" enquanto caminha pela rua).

Essa pilha lida essencialmente com todas ameaças realistas de Wi-Fi público em 2026. Nada disso é exótico.

Conclusões práticas

• Os ataques fáceis de Wi-Fi público de 2014 estão principalmente mortos. HTTPS matou.
• As ameaças que permanecem são reais mas diferentes: APs evil twin, captive portal MITM, vigilância pelo operador da rede, análise de tráfego.
• WPA3 ajuda mas não muda muito o quadro de ameaça de Wi-Fi público, porque maioria das redes públicas ainda é WPA2 ou aberta.
• HTTPS, DoH, e VPN são as três camadas que lidam com as ameaças reais de 2026.
• Um kill switch importa porque túneis caem, e janela de vazamento durante uma queda derrota a VPN.

Se está escolhendo VPN especificamente pra uso em Wi-Fi público, nossa peça preciso de uma VPN trata isso como o caso autônomo mais forte. O trial grátis de 7 dias te dá tempo de ver se funciona nas redes que você realmente usa.