2026-08-11 · INVESTIGAÇÃO · A equipa da Offensive Technology

SMTP TLS Downgrade: O Fosso de 92% por Trás do DMARC

Um ataque de SMTP TLS downgrade remove a encriptação do email enquanto este está em trânsito, e a maioria dos domínios não consegue impedi-lo. A encriptação clássica de SMTP é oportunista: os servidores oferecem STARTTLS, mas se um atacante posicionado na rede remover essa oferta, o servidor de envio recua silenciosamente para texto simples em vez de recusar. Os únicos registos que tornam o TLS obrigatório são MTA-STS e DANE. Resolvemos o DNS público dos 25.000 sites de topo do Tranco e lemos esses registos para os 18.012 domínios que recebem correio. O resultado é uma divisão nítida. A autenticação é comum: 79.3% publicam DMARC e 55.2% aplicam-no. A aplicação da encriptação em trânsito é rara: apenas 3.3% publicam uma política MTA-STS, 3.6% publicam um registo DANE, e apenas 6.5% publicam um dos dois. Juntando os dois, o fosso é evidente: dos domínios que aplicam DMARC, 92% não publicam MTA-STS nem DANE, pelo que o seu correio é autenticado contra falsificação mas continua degradável em trânsito.

O que é, na prática, um ataque de SMTP TLS downgrade

O SMTP entre servidores de correio começa em texto simples. O servidor recetor anuncia as suas capacidades, e se suportar encriptação lista STARTTLS entre elas. O servidor de envio emite então STARTTLS e os dois negoceiam uma sessão TLS. A fragilidade está na palavra oportunista. Se a capacidade STARTTLS não for anunciada, ou o handshake TLS falhar, ou o certificado não validar, o comportamento predefinido histórico não é abortar. É enviar o correio na mesma em texto simples, partindo do princípio de que entregar a mensagem importa mais do que encriptá-la.

Esse comportamento predefinido é o que um atacante explora. Um adversário com uma posição na rota da rede, um operador numa operadora de trânsito, alguém que comprometeu um router, um ator estatal numa fronteira, observa a troca inicial em texto simples e apaga a linha STARTTLS da lista de capacidades do recetor antes de esta chegar ao remetente. O remetente, não vendo oferta de encriptação, entrega em texto simples. Isto é o strip de STARTTLS, e é um downgrade e não uma quebra: nada é decifrado, o protocolo é simplesmente reconduzido ao seu fallback não encriptado. A mensagem, os seus anexos, e qualquer conteúdo de redefinição de palavra-passe ou fatura seguem pelo fio em claro. A comunidade operacional da APNIC tem uma explicação clara do mecanismo (SMTP downgrade attacks and MTA-STS) se quiser a visão ao nível dos pacotes.

Dois standards fecham o fallback. O MTA-STS (RFC 8461) permite que um domínio publique uma política que diz, na prática, "para o meu correio de entrada, é exigido TLS com um certificado válido, não recuar." Um remetente que tenha obtido e colocado em cache essa política recusará uma ligação com strip em vez de fazer downgrade. O DANE para SMTP (RFC 7672) faz o mesmo trabalho publicando um registo TLSA no DNS, autenticado por DNSSEC, que fixa que certificado o servidor de correio deve apresentar. Qualquer um dos dois transforma um downgrade silencioso numa entrega recusada. Nenhum está ativo por predefinição, e essa é toda a história dos números abaixo.

Porque é que o DMARC não ajuda aqui

Vale a pena ser preciso quanto a isto, porque os dois problemas são constantemente confundidos. DMARC, SPF e DKIM são autenticação. Permitem que um recetor decida se o endereço From visível é legítimo, e o DMARC diz ao recetor o que fazer quando não é. É assim que se impede alguém de forjar o seu domínio. Medimos essa camada num artigo anterior sobre o fosso entre publicar e aplicar DMARC, e isso importa. Mas autenticação e encriptação são ortogonais. O DMARC opera sobre quem a mensagem afirma ser o remetente. Um ataque de downgrade opera sobre o transporte que transporta a mensagem. Pode passar em todas as verificações de autenticação com distinção e ainda assim ter a ligação reduzida a texto simples, porque o DMARC nunca teve opinião sobre o transporte, para começar.

Assim, um domínio em p=reject com SPF e DKIM perfeitamente alinhados resolveu a falsificação e não fez nada quanto à interceção. O correio que chega é comprovadamente do remetente certo e foi legível por qualquer pessoa na rota. É essa a confusão que esta medição existe para corrigir: uma verificação DMARC verde não é um cadeado no envelope.

Os dados: autenticado, não encriptado

Eis o panorama de adoção nos 18.012 domínios recetores de correio da amostra. A barra da autenticação é alta. As duas barras que realmente impedem um downgrade são residuais.

Os mecanismos de segurança do transporte, discriminados, com o que cada um garante, estão abaixo. Leia as duas últimas linhas em conjunto: somando MTA-STS e DANE, apenas uma pequena minoria de domínios de correio tem alguma aplicação contra um downgrade, e quase nenhum executa os dois.

Um detalhe nessa tabela vale a pena analisar. O DANE (3.6%) é marginalmente mais comum do que o MTA-STS (3.3%), o que contraria a suposição habitual de que o MTA-STS venceria por não precisar de DNSSEC. Os dois quase não se sobrepõem: apenas 0.3% dos domínios de correio publicam ambos. Na prática, existem dois campos. Fornecedores e zonas de código de país que já assinam com DNSSEC inclinam-se para DANE, todos os outros que se preocupam sequer inclinam-se para MTA-STS, e a união dos dois esforços continua a deixar 93.5% dos domínios de correio sem qualquer aplicação.

O fosso de 92%

O número que vale a pena reter é o cruzamento. Dos 9.945 domínios que aplicam DMARC em quarantine ou reject, 9.192, ou 92%, não publicam MTA-STS nem registo DANE. Estes não são retardatários que ignoraram a segurança do correio. São os domínios que fizeram o trabalho mais difícil e mais visível de levar o DMARC até à aplicação, e depois pararam a uma camada de distância. Decidiram que um remetente forjado é inaceitável, o que está correto, deixando ao mesmo tempo a mensagem real legível em trânsito para qualquer um posicionado para fazer strip à sessão.

Vejamos isto da perspetiva do atacante, porque é essa perspetiva que decide se um controlo importa. Suponha que quer ler ou alterar correio que flui para um alvo, não forjá-lo. Está à procura de uma posição na rota e de um domínio que fará downgrade. Verifica o DNS do alvo tal como nós fizemos. Se o domínio publicar uma política MTA-STS em modo enforce, ou um registo DANE numa zona assinada, um servidor de envio que a respeite recusará entregar-lhe uma sessão em texto simples, e o seu downgrade falha logo no remetente. Se o domínio não publicar nenhum dos dois, o que descreve 92% do conjunto que aplica DMARC e 93.5% de todos os domínios de correio, o STARTTLS oportunista é a regra e um strip devolve texto simples. A postura de DMARC que também vê nessa consulta de DNS não altera nada neste resultado. Nunca ia forjar o remetente. Ia ler o correio.

O que torna este número digno de ser citado é a forma como foi produzido. Trata-se de medição passiva independente, não telemetria de fornecedor. Não reportámos sobre correio filtrado por algum produto nosso, nem extrapolámos a partir do fluxo de entrada de um único fornecedor. Lemos os registos de política pública que qualquer servidor de envio na internet lê, para uma amostra fixa numa data fixa. Levantamentos de adoção anteriores chegam à mesma conclusão a partir de pontos de observação diferentes: rastreadores independentes como o URIports MTA-STS survey situam a adoção em dígitos únicos baixos e a subir lentamente, o que está em linha com o que vemos no DNS bruto.

Como verificar e corrigir o seu próprio domínio

Não precisa de nenhuma ferramenta nem de registo. Uma consulta de DNS é uma leitura passiva de registos já públicos, pelo que pode executar isto contra o seu próprio domínio já.

• Verificar o MTA-STS. Execute dig TXT _mta-sts.yourdomain.com +short. Um registo que comece por v=STSv1 significa que anuncia uma política. Se estiver vazio, não tem MTA-STS. Note que o registo apenas aponta para uma política; o ficheiro de política em https://mta-sts.yourdomain.com/.well-known/mta-sts.txt tem de dizer mode: enforce para efetivamente bloquear, não mode: testing.
• Verificar o DANE. Primeiro encontre os seus servidores de correio com dig MX yourdomain.com +short, depois para cada host MX execute dig TLSA _25._tcp.that-mx-host +short. Um registo TLSA significa que o DANE está em jogo. O DANE só valida numa zona assinada com DNSSEC, por isso confirme a assinatura com dig DS yourdomain.com +short.
• Ativar os relatórios. Publique um registo TLS-RPT (RFC 8460) em _smtp._tls.yourdomain.com para que handshakes falhados e downgrades sejam reportados de volta a si em vez de permanecerem invisíveis. Não bloqueia nada, mas é assim que descobre que está a ocorrer um downgrade.

Se tanto a consulta de MTA-STS como a de TLSA voltarem vazias, o seu correio de entrada está protegido contra falsificação e exposto a interceção. A correção é publicar uma política MTA-STS em modo enforce, ou um registo TLSA de DANE numa zona assinada, ou ambos. Fazer qualquer um dos dois coloca-o na pequena minoria. O critério por trás de implementar um sem quebrar a entrega legítima é o mesmo critério por trás de saber quais dos outros controlos expostos realmente importam, o que é o objetivo de ler uma superfície da forma como um atacante o faz em vez de confiar nos indicadores verdes.

O que isto não prova

Limitações honestas, porque um número sem as suas ressalvas é marketing.

• O Tranco classifica por popularidade agregada, não por tráfego. A lista Tranco combina várias classificações de fornecedores para ser estável e difícil de manipular, mas não é um censo de tráfego. Leia estes números como uma fatia honesta da web popular, não a internet inteira.
• O MTA-STS é medido pelo sinal de DNS. Contámos um domínio como tendo MTA-STS se publicasse o registo _mta-sts. Deliberadamente não fomos buscar o ficheiro de política, o que implicaria contactar o servidor web do domínio, pelo que não conseguimos separar mode: enforce de mode: testing. A quota que efetivamente aplica está, portanto, em ou abaixo de 3.3%, o que torna o fosso mais largo, não mais estreito.
• O DANE é medido pela presença de TLSA. Verificámos a existência de um registo TLSA nos hosts MX, até cinco por domínio. Um registo publicado sinaliza intenção e configuração; não verificámos a cadeia de DNSSEC nem que todos os remetentes a validam, pelo que deve tratar 3.6% como o teto do DANE a funcionar corretamente.
• É uma fotografia instantânea. O DNS muda diariamente. Estes números descrevem 11 de agosto de 2026, não uma tendência, ainda que estejam de acordo com levantamentos independentes que mostram uma adoção baixa e a subir lentamente.
• A aplicação em trânsito continua a depender do remetente. O MTA-STS e o DANE só ajudam quando o servidor de envio os respeita. Um publicador faz a coisa certa ao anunciar a política; um remetente que a ignore ainda pode fazer downgrade. Os registos são necessários, mas não suficientes por si só.

Perguntas frequentes

O que é um ataque de STARTTLS downgrade?

É quando um atacante na rota de rede entre dois servidores de correio remove a oferta do servidor para mudar para TLS logo no início em texto simples da sessão SMTP. Como o STARTTLS oportunista recua para texto simples quando não é oferecido TLS, o remetente entrega então o correio sem encriptação e o atacante pode lê-lo ou alterá-lo. O MTA-STS e o DANE fecham este fallback dizendo ao remetente que o TLS é obrigatório.

O SMTP é encriptado em trânsito por predefinição?

Não, de forma fiável. A maioria dos servidores oferece STARTTLS, mas o TLS clássico de SMTP é oportunista: se a oferta faltar ou o certificado não validar, o remetente recua silenciosamente para texto simples. A encriptação acontece quando nada interfere, mas um atacante ativo pode removê-la. Apenas 6.5% dos domínios de correio que medimos tornam o TLS obrigatório com MTA-STS ou DANE.

O DMARC encripta o email em trânsito?

Não. O DMARC, com SPF e DKIM, autentica o remetente para que um recetor possa detetar um endereço From forjado. Não diz nada sobre se a ligação está encriptada. Um domínio pode aplicar DMARC em p=reject e continuar a ter o seu correio entregue em texto simples após um downgrade. Na nossa amostra, 92% dos domínios que aplicam DMARC não publicavam MTA-STS nem DANE.

O MTA-STS impede ataques de downgrade de TLS?

Sim, é essa a sua função. O MTA-STS publica uma política que diz aos servidores de envio que o seu domínio exige TLS com um certificado válido, pelo que um remetente que tenha colocado a política em cache recusa uma ligação com strip em vez de recuar. O seu único limite é o trust-on-first-use: um remetente que nunca tenha ido buscar a sua política ainda não está coberto, sendo aí que o DANE, ancorado em DNSSEC, é mais forte.

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

Ambos forçam TLS no SMTP de entrada mas ancoram a confiança de forma diferente. O MTA-STS assenta no sistema de certificados web mais trust-on-first-use e não precisa de DNSSEC. O DANE publica um registo TLSA autenticado por DNSSEC, o que elimina o intervalo de primeiro uso mas exige uma zona assinada. No nosso censo, foram adotados a uma taxa quase igualmente baixa, 3.3% e 3.6%, e apenas 0.3% dos domínios de correio publicaram ambos.

Que percentagem de domínios implementou o MTA-STS?

No nosso censo de agosto de 2026 da lista Tranco top 25.000, dos 18.012 domínios que recebem correio, 3.3% publicaram um registo MTA-STS. O DANE estava em 3.6% e o TLS-RPT em 3.9%. Contando qualquer um dos controlos de aplicação, 6.5% exigem TLS em trânsito, contra 79.3% que publicam DMARC.

Como verifico se o meu próprio domínio resiste a um downgrade de SMTP?

Execute dig TXT _mta-sts.yourdomain.com +short e procure por v=STSv1, e dig TLSA _25._tcp.your-mx-host +short para cada host MX. Se ambos estiverem vazios, o seu correio de entrada depende do STARTTLS oportunista e pode sofrer downgrade. Publicar uma política MTA-STS em modo enforce, ou um registo DANE numa zona assinada, fecha o fosso.

Leitura relacionada

• Publicar p=none é suficiente? Publicar DMARC não é o mesmo que aplicá-lo. A camada de autenticação junto à qual este artigo se situa.
• Quão expostos estão os domínios mais movimentados do mundo à falsificação de email? A questão da presença para o lado anti-falsificação.
• Quantos domínios de topo restringem quem pode emitir os seus certificados? O mesmo método de DNS passivo, aplicado a registos CAA.