Ataques de downgrade SMTP: como funcionam e como se proteger

⚡TL;DR

• SMTP transmite e-mails em texto claro por predefinição. STARTTLS adiciona encriptação, 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 detete
• MTA-STS (RFC 8461) e DANE/TLSA (RFC 7672) impõem a encriptação TLS obrigatória e bloqueiam esses ataques
• Aloje a sua política MTA-STS com CaptainDNS (primeira ferramenta gratuita, depois 3 €/mês sem IVA): dois registos DNS são suficientes para proteger os seus domínios em menos de 5 minutos

Todos os dias, mil milhões de e-mails circulam entre servidores SMTP. A maioria utiliza STARTTLS para encriptar a ligação. Mas essa encriptação é oportunista: se o servidor remoto não responde à encriptação, 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 encriptação TLS. O problema: nem o remetente nem o destinatário são informados do ataque.

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

Como o SMTP transmite os seus e-mails

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

STARTTLS: uma encriptação oportunista

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

O processo ocorre assim:

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

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 encriptação
S: 220 Ready to start TLS
[Negociação TLS]
C: EHLO mail.captaindns.com
[Transmissão encriptada do e-mail]

Porque "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 ligaçã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 nas 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 encriptação
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:

• Fornecedores 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 registos MX

O atacante falsifica a resposta DNS para os registos 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 predefinição. Um atacante pode apresentar um certificado autoassinado ou inválido, e o servidor remetente aceitará a ligaçã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 os 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 encriptação de e-mails em trânsito revela dados concretos:

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

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

Setores mais expostos

Setor	Risco	Razão
Saúde	Elevado	Dados de pacientes, conformidade HIPAA/RGPD
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 encriptação TLS obrigatória

MTA-STS permite que um domínio publique uma política que impõe a encriptação TLS aos servidores remetentes. A política é alojada 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 registo TXT _mta-sts.captaindns.com
2. Descarrega 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 registo 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 ligaçã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 detetar:

• Tentativas de downgrade
• Certificados expirados ou inválidos
• Problemas de configuração nos 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 registos MX. É a base do DANE, mas também reforça a segurança do MTA-STS protegendo a resolução do registo _mta-sts.

🎯 Plano de ação recomendado

1. Verifique a sua configuração atual: utilize o verificador MTA-STS para analisar o estado do seu domínio
2. Ative MTA-STS em modo testing: aloje a sua política com CaptainDNS (primeira ferramenta gratuita, depois 3 €/mês sem IVA) e monitorize os relatórios TLS-RPT durante 1 a 2 semanas
3. Configure TLS-RPT: receba os relatórios de falhas TLS para detetar problemas antes que impactem os seus e-mails
4. Passe para o modo enforce: quando os relatórios confirmarem que tudo funciona, ative o modo enforce para bloquear ligações não encriptadas
5. Avalie o DANE: se o seu registrar e o seu fornecedor DNS suportam DNSSEC, adicione registos TLSA para uma proteção sem TOFU

---

Proteja os seus e-mails contra ataques de downgrade agora: aloje a sua política MTA-STS (primeira ferramenta gratuita, depois 3 €/mês sem IVA) com CaptainDNS. Dois registos DNS, zero servidores web para gerir.

---

FAQ

O que é um ataque de downgrade SMTP?

Um ataque de downgrade SMTP (ou STARTTLS stripping) consiste em impedir a negociação da encriptação 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 detetar um ataque de downgrade nos meus e-mails?

Configure TLS-RPT (RFC 8460) para o 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 registos 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 registos 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 encripta a ligaçã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 encriptação TLS.

Os grandes fornecedores 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 o seu domínio publica uma política MTA-STS em modo enforce, Gmail e Outlook recusarão enviar em texto claro para os 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 a 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 ligação TLS após o estabelecimento de uma ligaçã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 encriptação.
• MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Política HTTPS que impõe a encriptação TLS para a receção de e-mails.
• DANE: DNS-Based Authentication of Named Entities (RFC 7672). Mecanismo que ancora o certificado TLS no DNS via registos 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 ligação não é verificada, mas as ligaçõ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 a 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?: comparação técnica e guia de escolha
• De testing a enforce: estratégia de implantação progressiva do MTA-STS: guia passo a passo da implantação progressiva

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