
Resumindo, o MTA-STS é uma maneira de proteger ainda mais os e-mails contra interceptação (ou seja, ataques de invasor intermediário, também conhecidos como MitM) quando são transmitidos entre servidores de e-mail. Resolve parcialmente os problemas arquitetônicos herdados dos protocolos de e-mail e é descrito no padrão RFC 8461 relativamente recente. Mail.ru Mail é o primeiro grande serviço postal na Internet russa a implementar esse padrão. E com mais detalhes, já está sob o corte.
Qual problema o MTA-STS resolve?
Historicamente, os protocolos de e-mail (SMTP, POP3, IMAP) transmitiam informações de forma clara, o que permite sua interceptação, por exemplo, ao acessar um canal de comunicação.
Qual é o mecanismo de entrega de uma carta de um usuário para outro:

Historicamente, o ataque MitM era possível em todos os lugares para onde ia o correio.
O RFC 8314 requer o uso obrigatório de TLS entre o programa de correio do usuário (MUA) e o servidor de correio. Se o seu servidor e os aplicativos de e-mail que você usa forem compatíveis com RFC 8314, você eliminou (em grande parte) a possibilidade de ataques man-in-the-middle entre o usuário e os servidores de e-mail.
A adesão a práticas comuns (padronizadas pela RFC 8314) elimina ataques de quase usuários:

Os servidores de correio Mail.ru cumpriam a RFC 8314 mesmo antes de o padrão ser adotado, na verdade, ele simplesmente captura as práticas já aceitas, e não tivemos que configurar mais nada. Mas, se o seu servidor de e-mail ainda permite usuários por meio de protocolos inseguros, certifique-se de implementar as recomendações deste padrão, porque provavelmente, pelo menos alguns de seus usuários trabalham com e-mail sem criptografia, mesmo se você oferecer suporte para isso.
O cliente de e-mail sempre trabalha com o mesmo servidor de e-mail da mesma organização. E você pode forçar todos os usuários a se conectarem de maneira segura e, em seguida, tornar tecnicamente impossível uma conexão insegura (é exatamente isso que a RFC 8314 exige). Às vezes é difícil, mas realizável. O tráfego entre servidores de e-mail é ainda mais complicado. Os servidores pertencem a diferentes organizações e são freqüentemente usados no modo "configure e esqueça", o que torna impossível mudar para um protocolo seguro de uma vez sem interromper a conectividade. Há muito que o SMTP fornece a extensão STARTTLS, que permite que os servidores que suportam criptografia mudem para TLS. Mas um invasor que tem a capacidade de influenciar o tráfegopode "cortar" informações sobre o suporte deste comando e forçar os servidores a se comunicarem usando um protocolo de texto simples (o chamado ataque de downgrade - um ataque para fazer o downgrade da versão do protocolo). Pelo mesmo motivo, para STARTTLS, a conformidade do certificado geralmente não é verificada (um certificado não confiável pode proteger contra ataques passivos, e isso não é pior do que enviar um e-mail em texto não criptografado). Portanto, STARTTLS protege apenas contra espionagem passiva.
O MTA-STS elimina parcialmente o problema de interceptar mensagens entre servidores de email, quando um invasor tem a capacidade de influenciar ativamente o tráfego. Se o domínio do destinatário publicar a política MTA-STS e o servidor do remetente suportar o MTA-STS, ele enviará o e-mail apenas por uma conexão TLS, apenas para os servidores definidos pela política e somente com o certificado do servidor verificado.
Por que parcialmente? O MTA-STS só funciona se ambas as partes implementaram esse padrão e o MTA-STS não oferece proteção contra cenários nos quais um invasor tem a oportunidade de obter um certificado de domínio válido em uma das CAs públicas.
Como funciona o MTA-STS
Destinatário
- Configura suporte para STARTTLS com um certificado válido no servidor de e-mail.
- Publica a política MTA-STS via HTTPS, um domínio mta-sts especial e um caminho especial bem conhecido, por exemplo, são usados para publicação
https://mta-sts.mail.ru/.well-known/mta-sts.txt
. A política contém uma lista de servidores de correio (mx) que têm o direito de receber correio para este domínio. - Publica um registro TXT _mta-sts especial no DNS com a versão da política. Quando a política muda, este registro deve ser atualizado (isso sinaliza ao remetente para solicitar novamente a política). Por exemplo,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Remetente O
remetente solicita o registro DNS _mta-sts, se disponível, faz uma solicitação de política via HTTPS (verificando o certificado). A política resultante é armazenada em cache (no caso de um invasor bloquear o acesso a ela ou alterar o registro DNS).
Ao enviar e-mail, é verificado se:
- o servidor para o qual o correio é entregue está na política;
- o servidor aceita correio usando TLS (STARTTLS) e possui um certificado válido.
Benefícios do MTA-STS
O MTA-STS usa tecnologias já implementadas na maioria das organizações (SMTP + STARTTLS, HTTPS, DNS). Para implementação no lado do destinatário, nenhum suporte de software especial para o padrão é necessário.
Desvantagens do MTA-STS
É necessário monitorar a validade do certificado do servidor web e de correio, a correspondência dos nomes, a renovação oportuna. Problemas com o certificado impossibilitarão a entrega de correspondência.
No lado do remetente, é necessário um MTA com suporte para políticas MTA-STS; atualmente, o MTA-STS não é compatível com o MTA.
O MTA-STS usa uma lista de CAs raiz confiáveis.
O MTA-STS não protege contra ataques nos quais o invasor usa um certificado válido. Na maioria dos casos, MitM perto do servidor implica a possibilidade de emissão de um certificado. Esse ataque pode ser detectado por meio de Transparência de certificado. Portanto, em geral, o MTA-STS atenua, 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 seguro tecnicamente, ou seja, para o MTA-STS, existe uma baixa probabilidade de que a carta não seja entregue devido a problemas técnicos causados pela implementação do padrão.
Padrão concorrente - DANE
O DANE usa DNSSEC para publicar informações de certificado e não exige confiança em CAs externas, o que é muito mais seguro. Mas o uso de DNSSEC tem uma probabilidade significativamente maior de levar a falhas técnicas, se você confiar em estatísticas por vários anos de uso (embora haja uma tendência positiva na confiabilidade do DNSSEC e seu suporte técnico em geral). Para implementar o DANE em SMTP no lado do destinatário, é obrigatória a presença de DNSSEC para a zona DNS, e para DANE, é essencial o suporte correto para NSEC / NSEC3, com o qual DNSSEC tem problemas sistémicos.
Se o DNSSEC estiver configurado com erros, pode levar a recusas de entrega de correio se o lado do remetente suportar o DANE, mesmo se o lado do receptor não souber nada sobre isso. Portanto, apesar do DANE ser um padrão mais antigo e seguro e já ser suportado em algum software de servidor do lado do remetente, na verdade sua penetração permanece insignificante, muitas organizações não estão prontas para implementá-lo devido à necessidade de implementar DNSSEC, isso retardou significativamente a implementação do DANE todos aqueles anos em que o padrão existiu.
DANE e MTA-STS não entram em conflito um com o outro e podem ser usados juntos.
O que há com suporte MTA-STS no Mail.ru Mail
Mail.ru tem publicado a política MTA-STS para todos os principais domínios já há algum tempo. No momento, estamos implementando o lado do cliente do padrão. No momento da redação deste artigo, as políticas são aplicadas em um modo sem bloqueio (se a entrega for bloqueada por uma política, a carta será entregue por meio de um servidor de "backup" sem aplicação de políticas), então o modo de bloqueio será forçado para uma pequena parte do tráfego SMTP de saída, gradualmente para 100% do tráfego a aplicação da política é suportada.
Quem mais apóia o padrão
Até agora, as políticas do MTA-STS publicam cerca de 0,05% dos domínios ativos, mas, mesmo assim, já protegem um grande volume de tráfego de e-mail, porque o padrão é suportado pelos principais players - Google, Comcast e parcialmente Verizon (AOL, Yahoo). Muitos outros serviços postais anunciaram que o suporte para o padrão será implementado em um futuro próximo.
Como isso vai me afetar?
Nada se o seu domínio não publicar a política MTA-STS. Se você publicar a política, as mensagens para os usuários do seu servidor de e-mail ficarão mais protegidas contra interceptação.
Como faço para implementar o MTA-STS?
Suporte MTA-STS no lado do destinatário
Basta publicar a política por meio de registros HTTPS e DNS, configurar um certificado válido de uma das CAs confiáveis (Vamos criptografar) para STARTTLS no MTA (STARTTLS é compatível com todos os MTAs modernos), suporte especial do MTA não é necessário ...
Passo a passo, fica assim:
- Configure STARTTLS no MTA que você está usando (postfix, exim, sendmail, Microsoft Exchange, etc.).
- , ( CA, , MX-, ).
- TLS-RPT , ( TLS). ( example.com):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:tlsrpt@example.com»
TLS SMTPtlsrpt@exmple.com
.
, . - MTA-STS HTTPS. CRLF .
https://mta-sts.example.com/.well-known/mta-sts.txt
:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400
version (STSv1
), Mode , testing — ( ), enforce — «» . mode: testing, , mode: enforce.
mx , ( , mx). Max_age ( DNS- , mta-sts DNS). - Publique o registro TXT no DNS:
_mta-sts.example.com. TXT “v=STSv1; id=someid;”
No campo id, você pode usar um identificador arbitrário (por exemplo, um carimbo de data / hora), ao alterar a política, ele deve mudar, isso permite que os remetentes entendam que eles precisam solicitar novamente a política em cache (se o identificador for diferente do armazenado em cache).
Suporte para MTA-STS no remetente
Embora seja ruim, porque o padrão é novo.
- Exim - sem suporte integrado, existe um script de terceiros https://github.com/Bobberty/MTASTS-EXIM-PERL
- Postfix - não há suporte embutido, há um script de terceiros que é descrito em detalhes em Habré https://habr.com/en/post/424961/
Como um posfácio em "TLS obrigatório"
Os reguladores têm se concentrado na segurança de e-mail recentemente (e isso é uma coisa boa). Por exemplo, o DMARC é obrigatório para todas as agências governamentais nos Estados Unidos e é cada vez mais exigido no setor financeiro; em áreas regulamentadas, a penetração do padrão chega a 90%. Agora, alguns reguladores exigem a implementação de "TLS obrigatório" com domínios separados, mas, ao mesmo tempo, o mecanismo para garantir "TLS obrigatório" não está definido e, na prática, essa configuração é muitas vezes implementada de uma forma que não protege minimamente contra ataques reais que já estão previstos em mecanismos como DANE ou MTA-STS.
Se o regulador exigir a implementação de "TLS obrigatório" com domínios separados, recomendamos considerar o MTA-STS ou seu equivalente parcial como o mecanismo mais adequado, pois elimina a necessidade de fazer configurações seguras para cada domínio separadamente. Se você tiver dificuldades com a implementação do lado do cliente do MTA-STS (até que o protocolo tenha recebido suporte generalizado, provavelmente o será), você pode recomendar esta abordagem:
- Publique a política MTA-STS e / ou registros DANE (faz sentido adicionar DANE apenas se DNSSEC já estiver habilitado para seu domínio, e MTA-STS em qualquer caso), isso protegerá o tráfego em sua direção e eliminará a necessidade de solicitar que outros serviços de correio configurem TLS obrigatório para o seu domínio se o serviço postal já suportar MTA-STS e / ou DANE.
- «» MTA-STS , MX TLS-. MTA-STS, , , . TLS STARTTLS.