Man-in-the-middle: por que HTTPS não é opcional
Todo cookie, token e senha que sua aplicação manda passa por uma rede que você não controla — a pergunta é só quem mais está olhando.
Man-in-the-middle (MITM) é o cenário em que alguém se posiciona entre o seu navegador e o servidor de destino, capaz de ler — e às vezes até alterar — o tráfego que passa por ali, sem que nenhum dos dois lados perceba nada de diferente. Não é um ataque contra o código da sua aplicação; é um ataque contra a rede que carrega os dados dela.
O cenário mais comum: Wi-Fi público
A situação clássica é um Wi-Fi público sem senha (aeroporto, cafeteria). Qualquer outro dispositivo na mesma rede — inclusive um notebook de um atacante rodando uma ferramenta de captura de pacotes — consegue ver o tráfego de rede de todo mundo conectado ali, porque é assim que esse tipo de rede compartilhada funciona fisicamente.
Clique em “Reproduzir fluxo” para ver a requisição passo a passo.
Repare que o atacante não precisa "invadir" nada — ele só precisa estar na mesma rede e rodar uma ferramenta de captura. Sem criptografia, ele lê o header Cookie, o header Authorization: Bearer ..., o corpo de um formulário de login com senha em texto puro — qualquer coisa que sua aplicação mande sem proteção.
Como o TLS impede isso — sem reexplicar o handshake do zero
O como o TLS estabelece uma chave de criptografia compartilhada sem os dois lados já se conhecerem de antes, e como o certificado prova a identidade do servidor, já foi coberto em profundidade na trilha de Networking. O ponto que importa aqui é o efeito: depois do handshake, todo o tráfego HTTP vira uma sequência de bytes criptografados que só cliente e servidor conseguem decifrar — um atacante capturando o mesmo tráfego na mesma rede vê só ruído, mesmo capturando exatamente os mesmos pacotes que veria sem HTTPS.
O que muda quando o atacante também consegue alterar, não só ler
Um MITM ativo não se limita a espionar — em uma conexão sem TLS, ele também pode modificar a resposta antes dela chegar até você: trocar um link de download por um malware, injetar um script na página (uma via adicional de XSS, dessa vez vinda da rede em vez do servidor), ou redirecionar um formulário de login pra uma página falsa idêntica à original. HTTPS impede isso da mesma forma que impede a leitura — qualquer alteração no tráfego criptografado quebra a verificação de integridade da conexão, e o navegador recusa a resposta adulterada.
O que o cadeado não resolve sozinho
Vale reforçar uma distinção que a trilha de Networking já faz: HTTPS garante que a conexão está protegida contra interceptação de rede — não protege contra XSS, SQL injection, senha fraca ou qualquer uma das outras lições desta trilha. Um site com HTTPS perfeito ainda pode ter todas essas vulnerabilidades; MITM é só um dos vários pontos do diagrama da lição 1, não o único.
Exercício
Um app mobile faz login contra uma API usando HTTP puro (sem TLS) "porque é mais rápido em desenvolvimento", com plano de trocar pra HTTPS antes do lançamento. Um colega argumenta que, como o app só é testado em rede interna da empresa, o risco é baixo. O que está sendo ignorado nesse raciocínio?