O que é um ataque man-in-the-middle

Um ataque man-in-the-middle (MITM) é quando um atacante se posiciona entre duas partes se comunicando por uma rede, lendo ou modificando tráfego em ambas as direções sem que nenhuma das partes perceba que não estão falando uma com a outra diretamente.

Imagine: você conecta ao site do seu banco. Um atacante comprometeu a rede entre vocês. Eles interceptam sua conexão, apresentam o próprio certificado (fingindo ser o banco), e encaminham seu tráfego pro banco real — coletando senhas ou modificando transações no caminho.

Se TLS funciona corretamente, o certificado do atacante falha validação e seu navegador te avisa. Se TLS funciona incorretamente, você não percebe.

Onde ataques MITM acontecem

Alguns cenários realistas:

• Wi-Fi público. Redes de hotel, Wi-Fi de café, redes de aeroporto. O atacante pode ser o operador da rede ou qualquer outro na mesma rede. Veja VPN pra Wi-Fi público pra por que isso importa.
• Roteadores comprometidos. Roteadores domésticos com senhas default, roteadores fornecidos por provedor com backdoors. O atacante controla seu gateway; tudo passa por eles.
• Adversários a nível de estado. Alguns países operam MITM em escala via certificate authorities falsas emitidas de CAs compelidos. Menos comum desde que Certificate Transparency tornou misissuance visível, mas não acabou.
• CAs comprometidos. A chave intermediária de um CA é roubada; atacantes emitem certs aparentemente válidos pra domínios arbitrários. Aconteceu (DigiNotar, Comodo). Navegadores eventualmente desconfiam do CA afetado.

Como TLS defende contra MITM

TLS verifica a identidade do servidor através de certificados assinados por CAs confiáveis. Quando você conecta, o servidor apresenta seu certificado. Seu navegador checa: esse certificado é assinado por um CA em que confio? O hostname casa? Foi revogado?

Se qualquer checagem falha, o navegador recusa conectar ou te avisa. Se tudo passa, a sessão criptografada continua.

Pra isso defender contra MITM, três coisas têm que valer:

1. O sistema de CA tem que estar não comprometido. Um CA desonesto pode emitir certs válidos pra qualquer domínio.
2. Seu trust store tem que estar limpo. Se um atacante instalou o cert CA dele na sua máquina (redes corporativas, malware), pode emitir certs válidos em que você confiará.
3. Você tem que honrar o aviso. Navegadores avisam em erros de cert; usuários clicam pra passar mesmo assim.

Certificate pinning: defesa mais forte

Pra conexões de alto valor, validação CA regular não basta. Certificate pinning hard-coda qual certificado específico (ou CA) um cliente deve esperar. Se o certificado não casa com o pin, a conexão falha — mesmo se assinado por um CA "confiável".

Fexyn pina seu próprio intermediate CA no cliente desktop. O cliente recusa qualquer conexão VPN onde o cert do servidor não é assinado por aquele intermediário. Um CA público comprometido não pode ser usado pra MITM tráfego do Fexyn — o cliente não confia em CAs públicos pra conexões VPN, só no PKI interno do Fexyn.

Essa é uma das razões pelas quais ataques MITM contra Fexyn requerem comprometer a infraestrutura de assinatura do Fexyn especificamente, não só qualquer CA aleatório na internet.

O que VPN faz e não faz

VPN torna MITM na rede subjacente quase impossível. O túnel é criptografado entre seu dispositivo e o servidor VPN; ninguém no caminho consegue MITM o que está dentro.

VPN não protege contra MITM no destino — uma vez que seu tráfego sai do servidor VPN e vai pro alvo real, TLS normal é a única defesa. E VPN não protege contra MITM na origem — malware no seu dispositivo pode te MITM antes do tráfego entrar no túnel.

Leia mais na visão geral de segurança e no guia de Wi-Fi público.

Experimente o Fexyn grátis por 7 dias.