Em resumo, MTA-STS é uma maneira de proteger ainda mais os e-mails contra interceptações (ou seja, ataques de homem-no-meio, conhecido como MitM) durante a transmissão entre servidores de e-mail. Ele resolve parcialmente problemas arquitetônicos herdados dos protocolos de e-mail e está descrito em um padrão relativamente recente, o RFC 8461. O Mail.ru é o primeiro grande serviço de e-mail na Runet a implementar esse padrão. Uma explicação mais detalhada pode ser encontrada abaixo.

Qual problema o MTA-STS resolve?

Historicamente, os protocolos de e-mail (SMTP, POP3, IMAP) transmitiam informações em texto claro, o que permite sua interceptação, por exemplo, ao acessar um canal de comunicação.

Como funciona o mecanismo de entrega de e-mail de um usuário para outro:

Historicamente, ataques MitM eram possíveis em todos os locais onde circulam e-mails.

O padrão RFC 8314 exige o uso obrigatório de TLS entre o cliente de e-mail do usuário (MUA) e o servidor de e-mail. Se seu servidor e os aplicativos de e-mail utilizados estiverem em conformidade com o RFC 8314, você (em grande medida) eliminou a possibilidade de ataques Man-in-the-Middle entre o usuário e os servidores de e-mail.

O cumprimento de práticas estabelecidas (os RFC 8314 padronizados) elimina ataques próximos ao usuário:

Os servidores de e-mail do Mail.ru já estavam em conformidade com o RFC 8314 antes mesmo da aceitação do padrão; na verdade, ele apenas documenta práticas já adotadas, e não foi necessário fazer ajustes adicionais. Mas, se seu servidor de e-mail ainda permite acesso a usuários através de protocolos inseguros, implemente obrigatoriamente as recomendações deste padrão, pois é provável que, pelo menos, parte de seus usuários utilize a e-mail sem criptografia, mesmo que você a suporte.

O cliente de e-mail sempre trabalha com o mesmo servidor de e-mail da mesma organização. E é possível forçar todos os usuários a se conectarem de maneira segura, tornando tecnicamente impossível a conexão insegura (isso é exatamente o que RFC 8314 exige). Isso às vezes é complicado, mas viável. Com o tráfego entre os servidores de e-mail, a situação é ainda mais complexa. Os servidores pertencem a diferentes organizações e muitas vezes são usados no modo 'instalou e esqueceu', o que torna impossível a mudança simultânea para um protocolo seguro sem comprometer a conectividade. No SMTP, já existe há bastante tempo a extensão STARTTLS, que permite que servidores que suportem criptografia migrem para TLS. Mas um atacante que tem a capacidade de influenciar o tráfego pode 'cortar' as informações sobre o suporte a esse comando e forçar os servidores a se comunicarem pelo protocolo de texto simples (o chamado downgrade attack — ataque de rebaixamento de versão do protocolo). Por essa razão, a conformidade do certificado normalmente não é verificada para o STARTTLS (um certificado não confiável pode proteger contra ataques passivos, e isso não é pior do que enviar uma mensagem em texto simples). Portanto, o STARTTLS protege apenas contra a escuta passiva.

O MTA-STS elimina parcialmente o problema da interceptação de e-mails entre servidores de e-mail, quando o atacante tem a capacidade de influenciar ativamente o tráfego. Se o domínio do destinatário publica uma política MTA-STS, e o servidor do remetente suporta MTA-STS, ele enviará a mensagem apenas através de uma conexão TLS, somente para servidores determinados pela política, e apenas com verificação do certificado do servidor.

Por que parcialmente? O MTA-STS funciona apenas se ambas as partes se preocuparem em implementar este padrão, e o MTA-STS não protege contra cenários em que o atacante tem a capacidade de obter um certificado válido de domínio em uma das CA públicas.

Como funciona o MTA-STS

Destinatário

Configura o suporte ao STARTTLS com um certificado válido no servidor de e-mail.
Publica a política MTA-STS via HTTPS, utilizando um domínio especial mta-sts e um caminho especial well-known, por exemplo https://mta-sts.mail.ru/.well-known/mta-sts.txt. A política contém uma lista de servidores de e-mail (mx) que têm permissão para receber e-mails para esse domínio.
Publica um registro TXT especial _mta-sts no DNS com a versão da política. Quando a política é alterada, esse registro deve ser atualizado (isso sinaliza ao remetente a necessidade de solicitar a política novamente). Por exemplo, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Remetente

O remetente solicita o registro DNS _mta-sts e, se disponível, faz um pedido da política via HTTPS (verificando o certificado). A política recebida é armazenada em cache (caso o invasor bloqueie o acesso a ela ou substitua o registro DNS).

Ao enviar um e-mail, verifica-se que:

o servidor para o qual o e-mail é entregue está na política;
o servidor aceita e-mails usando TLS (STARTTLS) e possui um certificado válido.

Vantagens do MTA-STS

O MTA-STS utiliza tecnologias que já estão implementadas na maioria das organizações (SMTP+STARTTLS, HTTPS, DNS). Para implementação no lado do receptor não é necessária suporte de software especial ao padrão.

Desvantagens do MTA-STS

É necessário monitorar a validade do certificado do servidor web e de e-mail, a conformidade dos nomes e a atualização oportuna. Problemas com o certificado resultarão na impossibilidade de entregar o e-mail.

Do lado do remetente, é necessário um MTA que suporte políticas MTA-STS, no momento, não é suportado 'out of the box' no MTA.

O MTA-STS utiliza uma lista de CAs raiz confiáveis.

O MTA-STS não protege contra ataques em que o invasor utiliza um certificado válido. Na maioria dos casos, um MitM próximo ao servidor implica a possibilidade de emitir um certificado. Esse tipo de ataque pode ser detectado por meio da Transparência de Certificados. Portanto, de modo geral, o MTA-STS mitiga, mas não elimina completamente a possibilidade de interceptação de tráfego.

Os dois últimos pontos tornam o MTA-STS menos seguro do que o padrão concorrente DANE para SMTP (RFC 7672), mas mais tecnicamente confiável, ou seja, para o MTA-STS, a probabilidade de que uma mensagem não seja entregue devido a problemas técnicos causados pela implementação do padrão é baixa.

Padrão concorrente — DANE

O DANE utiliza DNSSEC para publicar informações sobre certificados e não requer confiança em autoridades certificadoras externas, o que é muito mais seguro. No entanto, o uso de DNSSEC frequentemente resulta em falhas técnicas, com base nas estatísticas de vários anos de uso (embora a confiabilidade do DNSSEC e seu suporte técnico, em geral, demonstrem uma tendência positiva). Para implementar o DANE no SMTP do lado do destinatário, a presença do DNSSEC na zona DNS é obrigatória, sendo crucial que o NSEC/NSEC3 seja suportado corretamente, uma vez que existem problemas sistêmicos com o DNSSEC.

Se o DNSSEC estiver configurado incorretamente, isso pode levar a falhas na entrega de e-mails, caso o remetente suporte DANE, mesmo que o destinatário não tenha conhecimento disso. Assim, apesar de o DANE ser um padrão mais antigo e seguro, já suportado por alguns softwares de servidor no lado do remetente, sua adoção real permanece insignificante. Muitas organizações não estão prontas para implementá-lo devido à necessidade de implementar o DNSSEC, o que tem desacelerado significativamente a adoção do DANE ao longo de todos esses anos de existência do padrão.

O DANE e o MTA-STS não entram em conflito e podem ser usados juntos.

Qual é o suporte ao MTA-STS no Mail.ru?

O Mail.ru já publica a política MTA-STS para todos os principais domínios há bastante tempo. No momento, estamos implementando a parte do cliente do padrão. No momento em que este artigo foi escrito, as políticas estão sendo aplicadas em modo não bloqueante (caso a entrega seja bloqueada pela política, o e-mail será entregue através de um servidor 'de backup' sem a aplicação das políticas); posteriormente, um modo bloqueante será forçado para uma pequena parte do tráfego SMTP de saída, e gradualmente, a aplicação das políticas será suportada para 100% do tráfego.

Quem mais suporta o padrão?

Atualmente, cerca de 0,05% dos domínios ativos publicam políticas MTA-STS, mas, no entanto, eles já protegem um grande volume de tráfego de e-mail, pois o padrão é suportado por grandes jogadores — Google, Comcast e parcialmente Verizon (AOL, Yahoo). Muitos outros serviços de e-mail anunciaram que o suporte ao padrão será implementado em um futuro próximo.

Como isso me afetará?

Nenhuma, se o seu domínio não publicar uma política MTA-STS. Se você publicar a política, os e-mails para os usuários do seu servidor de e-mails estarão melhor protegidos contra interceptação.

Como posso implementar o MTA-STS?

Suporte ao MTA-STS do lado do destinatário

Basta publicar a política através de HTTPS e registros DNS, configurar um certificado válido de uma das CA confiáveis (pode ser Let’s Encrypt) para STARTTLS no MTA (STARTTLS é suportado em todos os MTA modernos), nenhum suporte especial do MTA é necessário.

Passo a passo, isso se parece com:

Configure o STARTTLS no MTA utilizado (postfix, exim, sendmail, Microsoft Exchange, etc.).
Certifique-se de que um certificado válido está sendo utilizado (emitido por uma CA confiável, não expirado, o assunto do certificado corresponde ao registro MX pelo qual os e-mails são entregues para seu domínio).
Configure um registro TLS-RPT, pelo qual os relatórios sobre a aplicação das políticas serão entregues (por serviços que suportam o envio de relatórios TLS). Um exemplo de registro (para o domínio example.com):
```
smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"
```
Esse registro instrui os remetentes de e-mails a enviar relatórios estatísticos sobre o uso de TLS no SMTP para o endereço tlsrpt@exmple.com.
Acompanhe os relatórios por alguns dias, certifique-se de que não há erros.
Publique a política MTA-STS através de HTTPS. A política é publicada como um arquivo de texto com terminais de linha CRLF em sua localização.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Exemplo de política:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
O campo version contém a versão da política (agora é STSv1), Mode define o modo de aplicação da política, testing — modo de teste (política não aplicada), enforce — modo "real". Primeiro, publique a política com mode: testing, se não houver problemas com a política no modo de teste, após algum tempo você pode mudar para mode: enforce.
No mx é especificada a lista de todos os servidores de correio que podem receber e-mails para seu domínio (cada servidor deve estar configurado com um certificado correspondente ao nome definido no mx). Max_age define o tempo de cache da política (uma vez gravada, a política será aplicada mesmo que um atacante bloqueie sua entrega ou altere os registros DNS durante o tempo de cache, sinalizar a necessidade de solicitar a política novamente pode ser feito alterando o registro mta-sts DNS).
Publique um registro TXT no DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
No campo id, você pode usar um identificador arbitrário (como a marca de tempo), que deve mudar quando a política mudar. Isso permite que os remetentes entendam que precisam reenviar a política em cache (se o identificador for diferente do cache).

Suporte MTA-STS do lado do remetente

Ainda está ruim, já que o padrão é recente.

Exim — não há suporte embutido, existe um script de terceiros. https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix — não há suporte embutido, existe um script que é descrito em detalhes no Habr. https://habr.com/en/post/424961/

Como um pós-escrito sobre "mandatory TLS"

Recentemente, os reguladores têm prestado atenção à segurança do e-mail (e isso é bom). Por exemplo, DMARC é obrigatório para todas as instituições governamentais nos EUA e está se tornando cada vez mais exigido no setor financeiro. Em setores regulamentados, a adoção do padrão alcança 90%. Agora, alguns reguladores exigem a implementação de "mandatory TLS" com domínios separados, mas, ao mesmo tempo, o mecanismo de garantia de "mandatory TLS" não é definido, e na prática essa configuração é frequentemente implementada de uma forma que nem mesmo protege minimamente contra ataques reais, que já são previstos em mecanismos como DANE ou MTA-STS.

Se o regulador exigir a implementação de "mandatory TLS" com domínios separados, recomendamos considerar o MTA-STS ou seu análogo parcial como o mecanismo mais adequado, pois ele elimina a necessidade de fazer configurações seguras para cada domínio individualmente. Se você tiver dificuldades para implementar a parte cliente do MTA-STS (já que o protocolo ainda não tem ampla adoção, provavelmente haverá problemas), pode-se recomendar a seguinte abordagem:

Publique a política MTA-STS e/ou as entradas DANE (DANE faz sentido adicionar apenas se o seu domínio já tiver DNSSEC habilitado, e MTA-STS de qualquer forma), isso protegerá o tráfego em sua direção e eliminará a necessidade de pedir que outros serviços de e-mail configurem o mandatory TLS para o seu domínio, se o serviço de e-mail já suporta MTA-STS e/ou DANE.
Para grandes provedores de email, implemente um 'análogo' do MTA-STS por meio de configurações de transporte separadas para cada domínio, que fixem o MX usado para o encaminhamento de emails e exijam a verificação obrigatória do certificado TLS. Se os domínios já publicam uma política MTA-STS, isso provavelmente pode ser feito sem problemas. A ativação da obrigatoriedade do TLS para um domínio, sem a fixação do relay e a verificação do certificado, é ineficaz em termos de segurança e não adiciona nada aos mecanismos existentes do STARTTLS.

Fonte: habr.com