Perigos do Wi-Fi público (mesmo com HTTPS em todo lugar)

Alguns anos atrás, o conselho para usar a rede de uma cafeteria era simples e sombrio: presuma que alguém está lendo seu tráfego. Então o HTTPS virou padrão em quase todo lugar, os navegadores começaram a gritar sobre sites em texto puro, e muita gente, em silêncio, parou de se preocupar.

Essa segunda parte é o problema. Os perigos do Wi-Fi público não desapareceram quando o HTTPS venceu — eles mudaram de lugar. O bisbilhoteiro passivo que farejava sua senha do Gmail no ar foi, em grande parte, tirado de cena pelo custo. O que resta é mais interessante, mais direcionado e mais difícil de notar, porque o ícone de cadeado faz tudo parecer em ordem.

Este texto percorre o que o HTTPS de fato resolveu, o que não resolveu, e o punhado de hábitos que mudam de forma significativa sua exposição em redes que não são suas.

O que o HTTPS realmente resolveu

Mérito a quem tem mérito. O HTTPS — a versão criptografada do protocolo da web — de fato resolveu a maior e mais tola versão do problema do Wi-Fi público.

Em 2014, alguém na mesma rede de aeroporto que você podia rodar uma ferramenta gratuita, ver seu navegador carregar o Facebook e ir embora com o cookie da sua sessão. Essa classe de ataque está praticamente morta. A combinação de HTTPS por padrão, HSTS (um sinalizador que diz aos navegadores “nunca mais carregue este site por HTTP simples”) e regras de cookie mais rígidas faz com que o farejamento passivo casual de sites populares não renda muita coisa.

Se o seu modelo de ameaça é “não quero que um adolescente entediado três mesas adiante leia meu e-mail”, o HTTPS te levou até lá.

O modelo de ameaça um degrau acima é onde fica mais honesto.

O que o HTTPS não cobre

O HTTPS criptografa o conteúdo da sua conexão com um servidor específico. Ele não protege as etapas antes de essa conexão ser estabelecida, e não protege você de si mesmo quando algo parece um pouco fora do lugar. É aqui que os perigos do Wi-Fi público ainda vivem.

Injeção no portal de captura

A página de “aceite nossos termos” que surge no Wi-Fi de hotel e aeroporto se chama portal de captura. Para funcionar, a rede tem que interceptar sua primeira requisição web e redirecioná-la para onde ela quiser. Isso é um homem-no-meio por design. Autorizado, mas ainda assim um homem-no-meio.

Um portal de captura bem administrado é inofensivo. Um mal administrado (ou um deliberadamente hostil) pode te servir JavaScript, empurrar atualizações falsas de software ou, em silêncio, traçar o perfil de cada aparelho que entra na rede. Seu telefone costuma exibir o portal em um navegador simplificado, sem a barra de endereço completa, o que dificulta saber o que você está vendo de fato.

Sequestro de DNS em resolvedores frágeis

Quando você digita bank.com, seu aparelho pergunta ao resolvedor DNS da rede “qual é o endereço IP disso?” Em uma rede pública, esse resolvedor é operado por quem for dono do ponto de acesso.

Um resolvedor mal configurado ou malicioso pode mentir. Ele pode te mandar para um servidor que não é o do seu banco e então apresentar o próprio certificado. Os navegadores modernos vão avisar — mas só se o certificado estiver errado, e só se você ler o aviso em vez de clicar para passar adiante.

SSL stripping em sites mal configurados

O SSL stripping é um truque antigo que ainda funciona em casos específicos. O atacante se posiciona entre você e o site que você tenta acessar. Você digita example.com (sem o prefixo https://), a rede intercepta, busca ela mesma a página HTTPS real e te serve uma cópia em HTTP simples.

Sites que usam pré-carregamento de HSTS são imunes. Sites que não usam (em geral serviços menores, ferramentas internas, ou qualquer coisa que você acessa por um favorito antigo) não são. A barra de endereço vai, discretamente, mostrar http:// em vez do ícone de cadeado, e a maioria das pessoas não olha.

Pontos de acesso falsos e evil twins

Este é o que vale entender direito, porque ele contorna a maior parte das defesas acima.

Seu telefone lembra das redes. Quando ele vê um beacon (um pequeno pacote de broadcast que anuncia um nome de Wi-Fi) que combina com uma à qual já se conectou antes, ele pode conectar automaticamente. Um atacante com equipamento comum pode transmitir um beacon afirmando ser Starbucks WiFi ou Hotel Guest, enviar um quadro de desautenticação para derrubar seu telefone da rede legítima, e ver seu aparelho pular para a dele sem você tocar em nada.

A partir daí, o atacante é a rede. Ele controla o DNS. Ele opera o portal de captura. Ele vê quais apps do seu aparelho estão tentando alcançar quais servidores, mesmo que o conteúdo esteja criptografado. Ele pode servir as próprias páginas de portal de captura, tentar SSL stripping em tudo que não tenha pré-carregamento, e pedir credenciais dentro do que parece um fluxo de login normal.

O nome técnico é “evil twin”, e a parte silenciosa é que nada te avisa que isso está acontecendo. Seu telefone só mostra o ícone familiar de Wi-Fi.

Condicionamento aos avisos de certificado

Os navegadores ficaram bons em avisos. Os usuários ficaram bons em ignorá-los.

Quando você vê um aviso de certificado vermelho em tela cheia, quase sempre significa que há algo errado com a conexão. Às vezes de forma inofensiva (um certificado vencido), às vezes não (um homem-no-meio ativo). A solução é não clicar para passar adiante. Na prática, anos de redes corporativas mal configuradas treinaram as pessoas a apertar o botão de “prosseguir mesmo assim” sem ler.

Na rede de uma cafeteria, esse botão pode ser o ataque inteiro.

Como um ataque evil twin funciona de fato

Se você quer uma imagem concreta de como tudo isso se encaixa, o ataque evil twin é o exemplo mais claro.

O atacante leva um notebook ou um pequeno aparelho portátil para uma cafeteria. Ele roda um software que faz três coisas em sequência.

Primeiro, varre o ar em busca de redes Wi-Fi próximas e anota o nome (o SSID) da legítima. Digamos que seja Cafe Guest. Em seguida começa a transmitir os próprios quadros de beacon com o mesmo nome, muitas vezes com mais potência, para que os aparelhos a prefiram.

Segundo, envia quadros de desautenticação aos clientes já conectados à rede real. Quadros de desautenticação são uma parte normal de como o Wi-Fi funciona — eles dizem a um aparelho “você foi desconectado, por favor reconecte”. Na maioria das redes eles não são autenticados, o que significa que qualquer um pode enviá-los. Os telefones na rede real são derrubados e procuram algum lugar para reconectar.

Terceiro, o atacante apresenta um portal de captura. Ele pode pedir um e-mail e uma senha “para acessar o Wi-Fi grátis”. Pode imitar a página de login do hotel. Pode simplesmente te deixar passar em silêncio, rotear seu tráfego pela própria conexão e registrar tudo. Da perspectiva do seu telefone, você está on-line. Da perspectiva do atacante, ele agora é o seu provedor.

A defesa não é ler cabeçalhos de pacote. É tornar o ataque sem graça — não entrando automaticamente em redes desconhecidas, roteando seu tráfego sensível por algo que a rede local não consiga enxergar, e não inserindo credenciais em páginas para as quais você não navegou de propósito.

O Wi-Fi público é seguro em 2026?

Resposta honesta: seguro o bastante para a maioria das coisas, não seguro o bastante para tudo.

Ler as notícias, procurar uma receita, rolar a rede social — tudo bem. O custo de errar com esse tráfego é baixo, e as proteções dos navegadores modernos são reais.

Entrar na conta do seu banco, acessar um painel administrativo do trabalho, aprovar uma transferência, ou entrar em um serviço novo que te envia um código de recuperação por SMS — esses são momentos de maior valor, em que a distância entre “provavelmente tudo bem” e “com certeza tudo bem” importa. A resposta barata para fechar essa distância é não fazer essas coisas em redes que você não controla.

Cinco passos práticos

Nenhum deles exige pensar em quadros de pacote. São hábitos.

1. Desative a entrada automática em redes desconhecidas.No iPhone, isso fica em Ajustes → Wi-Fi → Entrada Auto. em Ponto de Acesso, e por rede em Wi-Fi → (nome da rede) → Entrada Automática. A ideia é fazer seu aparelho perguntar antes de entrar em algo com um nome familiar. Veja nosso passo a passo de configuração de VPN no iPhone para etapas relacionadas.
2. Prefira a rede móvel ou seu próprio ponto de acesso quando der. Uma conexão 5G não é perfeitamente privada, mas tem um operador único e responsável, e não há um jeito fácil de um estranho se inserir no meio dela. Para qualquer coisa sensível em viagem, o ponto de acesso do seu telefone costuma ser uma resposta melhor do que a rede do hotel.
3. Use uma VPN para os momentos que importam. Uma VPN, sigla para rede privada virtual, roteia seu tráfego por um túnel criptografado até um servidor em que você confia, de modo que a rede local só vê essa única conexão e nada sobre para onde ela vai. Isso neutraliza a maioria das categorias acima: o portal de captura ainda pode te encher, mas não consegue ver suas consultas de DNS, não consegue fazer SSL stripping nos sites que você visita, e não consegue traçar o perfil de quais apps você está usando. Se a ideia é nova para você, nossa introdução sobre o que uma VPN realmente é cobre o básico, e nosso guia de VPNs na estrada entra nos detalhes. O Snap é uma opção construída em torno dessa postura, mas o hábito mais amplo importa mais do que a marca.
4. Nunca clique para passar por avisos de certificado em redes públicas. Se você vir um aviso de navegador em tela cheia sobre um certificado, feche a aba. Na sua rede de casa quase sempre é um site mal configurado; no Wi-Fi de uma cafeteria pode ser alguém ativamente no meio. O custo de errar é alto o suficiente para que “tente de novo mais tarde” seja o padrão correto.
5. Guarde logins e transações sensíveis para redes confiáveis. Banco, redefinição de senha, qualquer coisa que envolva um código de recuperação ou fluxo de dois fatores — isso vale a pequena fricção de esperar até você voltar para a rede móvel ou o Wi-Fi de casa. O ganho de comodidade de fazer isso no aeroporto não compensa a assimetria do que pode dar errado.

O que uma VPN resolve e o que não resolve

Há muito barulho nesse ponto, então vale ser específico.

Uma VPN resolve:

• A capacidade da rede local de ver suas consultas de DNS
• SSL stripping (seu tráfego não atravessa a rede hostil em texto claro)
• A traçagem de perfil pelo portal de captura depois que você passou por ele
• A capacidade de um ponto de acesso falso de descobrir qualquer coisa útil sobre sua atividade

Uma VPN não resolve:

• Um aviso de certificado que você clica para passar mesmo assim
• Páginas de phishing nas quais você ativamente faz login
• Malware que já está no seu aparelho
• O fato de que os sites que você visita ainda conseguem te identificar por meio de contas e cookies

É uma ferramenta afiada para uma classe específica de perigos do Wi-Fi público. Não é um escudo mágico, e produtos que a vendem como tal exageram o que ela faz. Nosso apanhado de mitos comuns sobre VPN entra em mais detalhes sobre a distância entre marketing e realidade.

Conclusão

O HTTPS resolveu a versão fácil do problema. A versão mais difícil, a camada abaixo da conexão onde vivem o DNS, os portais de captura e os pontos de acesso falsos, é em grande parte invisível até algo dar errado.

Você não precisa virar engenheiro de redes para ser sensato com isso. Desative a entrada automática, desconfie dos portais de captura, não clique para passar por avisos de certificado, e use a rede móvel ou uma VPN quando o que está em jogo for real.

Se você quer a parte da VPN resolvida de forma limpa no iOS — sem e-mail no cadastro, sem registros de tráfego, assinatura cobrada discretamente pelo seu Apple ID — o Snap é construído exatamente em torno dessa postura. O macOS está a caminho. De todo modo, o mais importante não é qual app você instala; é parar de tratar a rede da cafeteria como se fosse a sua.