MTA-STS, TLS-RPT e DANE: Segurança no Transporte de Email

SPF, DKIM e DMARC protegem quem envia. Mas o transporte entre servidores de email continua a ser SMTP oportunístico: o remetente pergunta “tens TLS?”, e se o destinatário responder mal ou um atacante no meio eliminar a resposta, a mensagem segue em texto claro. O MTA-STS, o TLS-RPT e o DANE fecham exactamente essa falha — e o Exchange Online já suporta os três.

O Problema: SMTP Oportunístico

O SMTP determina os servidores de destino através de DNS público, sem verificação de autenticidade. Um atacante posicionado no caminho pode responder ao MX com um servidor falso ou forçar a negociação para texto simples (downgrade). O resultado é interceptação de email sem qualquer indício para as partes.

MTA-STS: Política Obrigatória de TLS

O MTA-STS (RFC 8461) permite a um domínio declarar: “os meus servidores de email exigem TLS, com estes nomes e estes certificados”. A política publica-se em dois sítios — um registo DNS TXT _mta-sts e um ficheiro servido por HTTPS em https://mta-sts.<domínio>/.well-known/mta-sts.txt. O HTTPS é deliberado: o atacante teria de falsificar também o servidor web que publica a política.

Uma política mínima de teste:

version: STSv1
mode: testing
mx: pme-pt.mail.protection.outlook.com
max_age: 86400

Com o registo TXT correspondente:

_mta-sts.pme.pt. 3600 IN TXT v=STSv1; id=20260913080000Z;

Os três modos são testing (recupera a política e envia relatórios, sem bloquear), enforce (recusa entrega sem TLS válido) e none. A Microsoft recomenda semanas em testing a analisar os relatórios antes de mudar para enforce.

Do lado do Exchange Online, a validação de saída é automática: mensagens para domínios com MTA-STS em enforce que falhem a validação devolvem NDR com os códigos 5.4.8 (host MX fora da política) ou 5.7.5 (certificado inválido).

TLS-RPT: Relatórios de Falhas

O TLS-RPT (RFC 8460) é o companheiro de auditoria: um registo DNS que diz aos remetentes para onde enviar relatórios agregados de ligações TLS falhadas ou bem-sucedidas:

_smtp._tls.pme.pt. 3600 IN TXT v=TLSRPTv1; rua=mailto:[email protected];

Em conjunto com o MTA-STS em modo testing, é aqui que se confirmam os MX correctos e a validade dos certificados antes de activar a aplicação obrigatória. Falhas por validação aparecem nos relatórios com contagem por domínio.

DANE: A Âncora no DNSSEC

O DANE (RFC 7672) vai mais longe e elimina a dependência das CAs públicas: publica no DNS um registo TLSA que especifica qual o certificado — ou a chave — que o servidor de mail deve apresentar. Como os registos DNS são assinados com DNSSEC, o remetente valida o certificado do destinatário directamente contra o DNS autenticado, imune a spoofing e a downgrades.

O Exchange Online faz outbound DANE para domínios que publiquem TLSA com DNSSEC activo: valida o TLSA, estabelece TLS e, se falhar, repete 15 minutos depois, mais 15 minutos depois disso e só então passa a horária durante as 24 horas seguintes. Só depois de 24 horas de falha é gerado NDR. Do lado inbound, o domínio precisa de DNSSEC na zona e do registo TLSA associado aos hosts MX.

Para o sysadmin PME, o DANE tem dependências que exigem planeamento: DNSSEC na zona DNS tem de estar correcto antes de publicar o TLSA — uma zona DNSSEC mal assinada bloqueia a entrega em vez de a proteger.

Monitorizar no Exchange Admin Center

O relatório Outbound messages in transit security report no EAC mostra as mensagens enviadas para domínios protegidos com MTA-STS ou DANE, com o estado de validação (seguras, com falha ou com reencaminhamento). É a forma rápida de apanhar erros de política antes de os remetentes externos os apanhar por NDR.

Ordem de Implementação

  1. Publicar TLS-RPT (sem risco — só recolhe relatórios).
  2. Publicar MTA-STS em testing com os MX reais.
  3. Acompanhar os relatórios durante algumas semanas.
  4. Activar DNSSEC na zona e publicar o registo TLSA.
  5. Mudar MTA-STS para enforce.

Com o email a continuar como canal número um de phishing, prevenir campanhas no cliente é só metade do trabalho. A outra metade é garantir que o transporte não dá ao atacante a segunda oportunidade.

Artigos Relacionados