Ataques de downgrade SMTP: como funcionam e como se proteger

⚡TL;DR

• SMTP transmite e-mails em texto claro por padrão. STARTTLS adiciona criptografia, mas permanece vulnerável a ataques de downgrade (STARTTLS stripping)
• Um atacante posicionado na rede pode remover a opção STARTTLS da resposta do servidor, forçando o envio em texto claro sem que o remetente detecte
• MTA-STS (RFC 8461) e DANE/TLSA (RFC 7672) impõem a criptografia TLS obrigatória e bloqueiam esses ataques
• Hospede sua política MTA-STS gratuitamente com CaptainDNS: dois registros DNS são suficientes para proteger seus domínios em menos de 5 minutos

Todos os dias, bilhões de e-mails circulam entre servidores SMTP. A maioria utiliza STARTTLS para criptografar a conexão. Mas essa criptografia é oportunista: se o servidor remoto não responde à criptografia, a mensagem é enviada em texto claro. Um atacante posicionado na rede pode forçar esse comportamento com um simples pacote de rede.

Os ataques de downgrade SMTP, também chamados de STARTTLS stripping, exploram essa fragilidade. Eles permitem interceptar e-mails em texto claro, mesmo quando os dois servidores suportam criptografia TLS. O problema: nem o remetente nem o destinatário são informados do ataque.

Este artigo detalha o mecanismo técnico desses ataques, suas variantes, seu impacto real com base nos dados do Google, e as soluções concretas para proteger seus domínios. Se você gerencia servidores de e-mail ou a segurança de um domínio, este guia é para você.

Como o SMTP transmite seus e-mails

SMTP (Simple Mail Transfer Protocol, RFC 5321) é o protocolo usado para encaminhar e-mails entre servidores. Projetado em 1982, ele não prevê nenhuma criptografia nativa. Cada mensagem transita em texto claro entre o servidor remetente e o servidor destinatário.

STARTTLS: uma criptografia oportunista

Em 2002, a RFC 3207 introduz o STARTTLS. Esse mecanismo permite que dois servidores SMTP negociem uma conexão TLS após o estabelecimento da conexão inicial em texto claro.

O processo ocorre assim:

1. O servidor remetente abre uma conexão TCP na porta 25
2. O servidor destinatário responde com suas capacidades, incluindo 250 STARTTLS
3. O servidor remetente envia o comando STARTTLS
4. Os dois servidores negociam uma conexão TLS
5. O e-mail é transmitido de forma criptografada

S: 220 mx.captaindns.com ESMTP
C: EHLO mail.captaindns.com
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250-STARTTLS        ← o servidor anuncia o suporte TLS
S: 250 OK
C: STARTTLS            ← o cliente solicita a criptografia
S: 220 Ready to start TLS
[Negociação TLS]
C: EHLO mail.captaindns.com
[Transmissão criptografada do e-mail]

Por que "oportunista" é um problema

A palavra-chave é oportunista. Se o comando STARTTLS falha ou não é oferecido, o servidor remetente envia o e-mail em texto claro sem avisar ninguém. É uma escolha de design: a RFC 3207 prioriza a entrega da mensagem em relação à sua confidencialidade.

Essa decisão cria a falha explorada pelos ataques de downgrade.

Anatomia de um ataque de downgrade SMTP

Um ataque de downgrade SMTP, ou STARTTLS stripping, consiste em impedir a negociação TLS entre dois servidores de e-mail. O atacante força o retorno a uma conexão em texto claro.

Como funciona o STARTTLS stripping?

O atacante precisa se posicionar no caminho de rede entre os dois servidores (man-in-the-middle). Ele intercepta os pacotes TCP e modifica a resposta do servidor destinatário:

1. O servidor remetente envia EHLO ao servidor destinatário
2. O servidor destinatário responde com 250 STARTTLS em suas capacidades
3. O atacante intercepta essa resposta e remove a linha 250 STARTTLS
4. O servidor remetente recebe uma resposta sem menção ao STARTTLS
5. O servidor remetente conclui que o destinatário não suporta criptografia
6. O e-mail é enviado em texto claro
7. O atacante lê o conteúdo da mensagem

[Resposta original do servidor destinatário]
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250-STARTTLS        ← presente
S: 250 OK

[Resposta modificada pelo atacante]
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250 OK              ← STARTTLS removido

O ataque é invisível para os dois servidores. O servidor remetente pensa que o destinatário não suporta TLS. O servidor destinatário não sabe que um e-mail foi enviado em texto claro.

Quem pode realizar esse ataque?

Qualquer entidade posicionada no caminho de rede:

• Provedores de acesso à internet (ISPs): controlam o roteamento do tráfego
• Operadores de redes intermediárias: pontos de troca de internet (IXP)
• Atacantes na rede local: Wi-Fi público, rede corporativa comprometida
• Atores estatais: vigilância em massa documentada em certos países

Variantes de ataques ao transporte de e-mail

O STARTTLS stripping é a variante mais conhecida, mas outros ataques visam o transporte de e-mail.

Spoofing DNS dos registros MX

O atacante falsifica a resposta DNS para os registros MX do domínio destinatário. O servidor remetente então envia o e-mail para um servidor falso controlado pelo atacante.

; Resposta DNS legítima
captaindns.com. MX 10 mx.captaindns.com.

; Resposta DNS falsificada pelo atacante
captaindns.com. MX 10 mx.atacante.com.

DNSSEC protege contra esse ataque assinando criptograficamente as respostas DNS.

Ataque ao certificado TLS

Mesmo que STARTTLS seja negociado, SMTP não valida o certificado do servidor destinatário por padrão. Um atacante pode apresentar um certificado autoassinado ou inválido, e o servidor remetente aceitará a conexão sem verificação.

MTA-STS e DANE impõem a validação do certificado, bloqueando essa variante.

Sequestro BGP

Um atacante anuncia rotas BGP falsas para redirecionar o tráfego de rede para seus próprios equipamentos. Esse ataque visa a infraestrutura de rede e pode afetar todo o tráfego, não apenas os e-mails.

Impacto real: quem é afetado?

Os dados do Google

O Transparency Report do Google sobre a criptografia de e-mails em trânsito revela dados concretos:

• Mais de 90% dos e-mails recebidos pelo Gmail são criptografados com TLS
• Mais de 90% dos e-mails enviados pelo Gmail utilizam TLS
• Certas regiões e certos provedores permanecem abaixo de 70%

Esses dados mostram que a criptografia SMTP avançou, mas que lacunas persistem. Cada e-mail não criptografado representa uma oportunidade para um ataque de downgrade.

Setores mais expostos

Setor	Risco	Razão
Saúde	Elevado	Dados de pacientes, conformidade HIPAA/LGPD
Finanças	Elevado	Informações financeiras sensíveis
Jurídico	Elevado	Sigilo profissional, confidencialidade do cliente
Administração	Médio	Dados de cidadãos, processos internos
PMEs	Médio	Infraestrutura de e-mail frequentemente subconfigurada

Ataques documentados

Pesquisas publicadas pela EFF e APNIC documentaram casos de STARTTLS stripping em larga escala por operadores de rede em vários países. Esses ataques não visam um domínio específico: eles interceptam todo o tráfego SMTP que transita pela infraestrutura comprometida.

Como se proteger contra ataques de downgrade

Quatro mecanismos complementares permitem proteger o transporte de e-mail.

MTA-STS (RFC 8461): a criptografia TLS obrigatória

MTA-STS permite que um domínio publique uma política que impõe a criptografia TLS aos servidores remetentes. A política é hospedada em um servidor HTTPS, um canal separado e autenticado que o atacante não pode comprometer com STARTTLS stripping.

Funcionamento:

1. O servidor remetente descobre o registro TXT _mta-sts.captaindns.com
2. Ele baixa a política de https://mta-sts.captaindns.com/.well-known/mta-sts.txt
3. A política indica os servidores MX autorizados e o modo (testing/enforce)
4. Em modo enforce, o servidor recusa enviar em texto claro

Vantagem: não requer DNSSEC. Funciona com qualquer registrar.

Limitação: a primeira solicitação (antes do cache) permanece vulnerável (TOFU, Trust On First Use).

DANE/TLSA (RFC 7672): o certificado ancorado no DNS

DANE publica a impressão digital do certificado TLS diretamente em um registro TLSA do DNS. O servidor remetente verifica que o certificado apresentado corresponde ao declarado no DNS.

Vantagem: sem TOFU. A verificação é imediata desde a primeira conexão.

Limitação: requer DNSSEC em toda a cadeia DNS, o que limita a adoção.

TLS-RPT (RFC 8460): a visibilidade sobre as falhas

TLS-RPT não bloqueia ataques, mas os torna visíveis. Os servidores remetentes que suportam TLS-RPT enviam relatórios diários sobre falhas de negociação TLS.

Esses relatórios permitem detectar:

• Tentativas de downgrade
• Certificados expirados ou inválidos
• Problemas de configuração em seus servidores MX

Configure TLS-RPT com nosso gerador TLS-RPT para receber esses relatórios.

DNSSEC: a proteção do DNS

DNSSEC assina criptograficamente as respostas DNS, impedindo o spoofing dos registros MX. É a base do DANE, mas também reforça a segurança do MTA-STS protegendo a resolução do registro _mta-sts.

🎯 Plano de ação recomendado

1. Verifique sua configuração atual: utilize o verificador MTA-STS para analisar o estado do seu domínio
2. Ative MTA-STS em modo testing: hospede sua política gratuitamente com CaptainDNS e monitore os relatórios TLS-RPT durante 1 a 2 semanas
3. Configure TLS-RPT: receba os relatórios de falhas TLS para detectar problemas antes que impactem seus e-mails
4. Passe para o modo enforce: quando os relatórios confirmarem que tudo funciona, ative o modo enforce para bloquear conexões não criptografadas
5. Avalie o DANE: se seu registrar e seu provedor DNS suportam DNSSEC, adicione registros TLSA para uma proteção sem TOFU

---

Proteja seus e-mails contra ataques de downgrade agora: hospede sua política MTA-STS gratuitamente com CaptainDNS. Dois registros DNS, zero servidores web para gerenciar.

---

FAQ

O que é um ataque de downgrade SMTP?

Um ataque de downgrade SMTP (ou STARTTLS stripping) consiste em impedir a negociação da criptografia TLS entre dois servidores de e-mail. O atacante, posicionado na rede, remove a opção STARTTLS da resposta do servidor destinatário. O servidor remetente então envia o e-mail em texto claro, permitindo que o atacante leia o conteúdo da mensagem.

Como detectar um ataque de downgrade nos meus e-mails?

Configure TLS-RPT (RFC 8460) para seu domínio. Os servidores remetentes compatíveis enviarão relatórios diários listando falhas de negociação TLS. Um aumento repentino de falhas pode indicar uma tentativa de downgrade. Ative também MTA-STS em modo testing para receber relatórios sem bloquear a entrega.

MTA-STS protege contra todos os ataques de downgrade?

MTA-STS protege contra STARTTLS stripping e ataques a certificados TLS. Ele não protege contra spoofing DNS dos registros MX (use DNSSEC para isso) nem contra sequestro BGP. Para proteção completa, combine MTA-STS com DNSSEC e, se possível, DANE/TLSA.

Qual é a diferença entre MTA-STS e DANE?

MTA-STS publica uma política via HTTPS e funciona sem DNSSEC. DANE ancora o certificado TLS no DNS via registros TLSA e requer DNSSEC. MTA-STS sofre do problema TOFU (a primeira solicitação não é protegida). DANE oferece verificação imediata. Os dois são complementares.

STARTTLS é suficiente para proteger meus e-mails?

Não. STARTTLS criptografa a conexão de forma oportunista, mas não protege contra ataques de downgrade nem contra certificados inválidos. Um atacante de rede pode remover a opção STARTTLS ou apresentar um certificado falso. MTA-STS ou DANE são necessários para impor a criptografia TLS.

Os grandes provedores como Gmail e Outlook são vulneráveis?

Gmail e Microsoft 365 suportam MTA-STS como servidores remetentes: eles verificam e respeitam as políticas MTA-STS dos domínios destinatários. Se seu domínio publica uma política MTA-STS em modo enforce, Gmail e Outlook recusarão enviar em texto claro para seus servidores, mesmo em caso de tentativa de downgrade.

É necessário ativar MTA-STS e DANE ao mesmo tempo?

Não é obrigatório, mas é recomendado se sua infraestrutura permitir. MTA-STS é mais simples de implantar (não precisa de DNSSEC) e cobre a maioria dos servidores remetentes. DANE oferece segurança adicional (sem TOFU) para servidores que o suportam. Os dois mecanismos coexistem sem conflito.

📖 Glossário

• STARTTLS: extensão SMTP (RFC 3207) que permite negociar uma conexão TLS após o estabelecimento de uma conexão em texto claro na porta 25.
• STARTTLS stripping: ataque que consiste em remover o anúncio STARTTLS da resposta do servidor para impedir a criptografia.
• MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Política HTTPS que impõe a criptografia TLS para a recepção de e-mails.
• DANE: DNS-Based Authentication of Named Entities (RFC 7672). Mecanismo que ancora o certificado TLS no DNS via registros TLSA.
• TLS-RPT: SMTP TLS Reporting (RFC 8460). Mecanismo de relatórios sobre falhas de negociação TLS entre servidores de e-mail.
• TOFU: Trust On First Use. Modelo de segurança onde a primeira conexão não é verificada, mas as conexões seguintes são validadas em relação à primeira.
• DNSSEC: DNS Security Extensions. Sistema de assinaturas criptográficas que autentica as respostas DNS e impede sua falsificação.

📚 Guias relacionados sobre segurança do transporte de e-mail

• MTA-STS vs DANE: qual protocolo escolher para proteger o transporte de e-mail? (em breve)
• De testing a enforce: estratégia de implantação progressiva do MTA-STS (em breve)

Fontes

• RFC 5321 - Simple Mail Transfer Protocol
• RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security
• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities
• Google Transparency Report - Email encryption in transit