Resumindo, o MTA-STS é uma forma de proteger ainda mais os e-mails contra interceptação (ou seja, ataques man-in-the-middle, também conhecidos como MitM) quando transmitidos entre servidores de e-mail. Ele resolve parcialmente os problemas arquitetônicos legados dos protocolos de e-mail e é descrito no padrão relativamente recente RFC 8461. Mail.ru é o primeiro grande serviço de correio no RuNet a implementar esse padrão. E é descrito com mais detalhes no corte.

Que problema o MTA-STS resolve?

Historicamente, os protocolos de e-mail (SMTP, POP3, IMAP) transmitiam informações em texto não criptografado, o que permitia interceptá-las, por exemplo, ao acessar um canal de comunicação.

Como é o mecanismo para entregar uma carta de um usuário para outro:

Historicamente, um ataque MitM era possível em todos os locais por onde circulava correspondência.

A RFC 8314 requer o uso de TLS entre o aplicativo de usuário de email (MUA) e o servidor de email. 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.

Seguir práticas geralmente aceitas (padronizadas pela RFC 8314) elimina o ataque próximo ao usuário:

Os servidores de e-mail Mail.ru estavam em conformidade com a RFC 8314 antes mesmo da adoção do padrão; na verdade, ele simplesmente captura práticas já aceitas e não precisamos configurar nada adicional. Mas, se o seu servidor de e-mail ainda permite usuários que utilizam protocolos inseguros, não deixe de implementar as recomendações deste padrão, pois Provavelmente, pelo menos alguns de seus usuários trabalham com e-mail sem criptografia, mesmo que você ofereça suporte.

O cliente de email sempre funciona com o mesmo servidor de email 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 a conexão de usuários não seguros (isso é exatamente o que a RFC 8314 exige). Isso às vezes é difícil, mas factível. O tráfego entre servidores de correio é ainda mais complicado. Os servidores pertencem a organizações diferentes e são frequentemente usados no modo “configure e esqueça”, o que torna impossível mudar para um protocolo seguro de uma só vez sem interromper a conectividade. O SMTP fornece há muito tempo a extensão STARTTLS, que permite que servidores que suportam criptografia mudem para TLS. Mas um invasor que tenha a capacidade de influenciar o tráfego pode “cortar” informações sobre o suporte a esse comando e forçar os servidores a se comunicarem usando um protocolo de texto simples (o chamado ataque de downgrade). Pela mesma razão, o STARTTLS geralmente não verifica a validade do certificado (um certificado não confiável pode proteger contra ataques passivos, e isso não é pior do que enviar uma mensagem em texto não criptografado). Portanto, o STARTTLS protege apenas contra escuta passiva.

O MTA-STS elimina parcialmente o problema de interceptação de cartas entre servidores de correio, quando o invasor tem a capacidade de influenciar ativamente o tráfego. Se o domínio do destinatário publicar uma política MTA-STS e o servidor do remetente suportar MTA-STS, ele enviará o e-mail apenas por uma conexão TLS, apenas para servidores definidos pela política e apenas com verificação do certificado do servidor.

Por que parcialmente? O MTA-STS só funciona se ambas as partes tiverem o cuidado de implementar este padrão, e o MTA-STS não protege contra cenários em que um invasor consiga obter um certificado de domínio válido de uma das CAs públicas.

Como funciona o MTA-STS

beneficiário

Configura o suporte STARTTLS com um certificado válido no servidor de email.
Publica a política MTA-STS via HTTPS; um domínio mta-sts especial e um caminho especial conhecido são usados para publicação, por exemplo 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 especial _mta-sts no DNS com a versão da política. Quando a política for alterada, esta entrada deverá ser atualizada (isso sinaliza ao remetente para consultar novamente a política). Por exemplo, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Remetente

O remetente solicita o registro DNS _mta-sts e, caso esteja disponível, faz uma solicitação de política via HTTPS (verificando o certificado). A política resultante é armazenada em cache (caso um invasor bloqueie o acesso a ela ou falsifique o registro DNS).

Ao enviar correio, verifica-se que:

o servidor ao qual a correspondência é entregue está na política;
o servidor aceita correio 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 destinatário, não é necessário suporte de software especial para o padrão.

Desvantagens do MTA-STS

É necessário monitorar a validade do certificado do servidor web e de e-mail, a correspondência de nomes e a renovação oportuna. Problemas com o certificado resultarão na impossibilidade de entrega da correspondência.

Do lado do remetente, é necessário um MTA com suporte para políticas MTA-STS; atualmente, o MTA-STS não é suportado imediatamente no MTA.

O MTA-STS usa 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, o MitM próximo ao servidor implica a capacidade de emitir um certificado. Tal ataque pode ser detectado usando a Transparência de Certificados. 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 confiável tecnicamente, ou seja, mais confiável do ponto de vista técnico. para o MTA-STS há baixa probabilidade de a carta não ser entregue devido a problemas técnicos causados pela implementação da norma.

Padrão concorrente - DANE

DANE usa DNSSEC para publicar informações de certificados e não exige confiança em autoridades de certificação externas, o que é muito mais seguro. Mas a utilização do DNSSEC conduz significativamente mais frequentemente a falhas técnicas, com base em estatísticas ao longo de vários anos de utilização (embora haja geralmente uma tendência positiva na fiabilidade do DNSSEC e no seu suporte técnico). Para implementar DANE em SMTP no lado do destinatário, a presença de DNSSEC para a zona DNS é obrigatória, e o suporte correto para NSEC/NSEC3 é essencial para DANE, com o qual existem problemas sistêmicos em DNSSEC.

Se o DNSSEC não estiver configurado corretamente, poderá resultar em falhas na entrega de mensagens se o lado remetente oferecer suporte a DANE, mesmo que o lado destinatário não saiba nada sobre isso. Portanto, apesar de o DANE ser um padrão mais antigo e seguro e já ser suportado em alguns softwares de servidor do lado do remetente, na verdade sua penetração permanece insignificante, muitas organizações não estão preparadas para implementá-lo devido à necessidade de implementar DNSSEC, isso retardou significativamente a implementação do DANE durante todos os anos em que o padrão existiu.

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

O que há com suporte MTA-STS no Mail.ru Mail?

Mail.ru publica uma política MTA-STS para todos os principais domínios há algum tempo. No momento, estamos implementando a parte do cliente do padrão. No momento em que este artigo foi escrito, as políticas eram aplicadas em modo sem bloqueio (se a entrega for bloqueada por uma política, a carta será entregue através de um servidor “sobressalente” 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 será suportada a aplicação de políticas.

Quem mais apoia o padrão?

Até o momento, as políticas MTA-STS publicam aproximadamente 0.05% dos domínios ativos, mas, mesmo assim, já protegem um grande volume de tráfego de correio, pois O padrão é apoiado pelos principais players - Google, Comcast e parcialmente Verizon (AOL, Yahoo). Muitos outros serviços postais anunciaram que o suporte ao padrão será implementado num futuro próximo.

Como isso me afetará?

Não, a menos que seu domínio publique uma política MTA-STS. Se você publicar a política, os e-mails dos usuários do seu servidor de e-mail estarão mais protegidos contra interceptação.

Como implementar o MTA-STS?

Suporte MTA-STS do lado do destinatário

Basta publicar a política via HTTPS e registros em DNS, configurar um certificado válido de uma das CAs confiáveis (vamos criptografar é possível) para STARTTLS no MTA (STARTTLS é suportado em todos os MTAs modernos), sem suporte especial do O MTA é obrigatório.

Passo a passo, fica assim:

Configure o STARTTLS no MTA que você está usando (postfix, exim, sendmail, Microsoft Exchange, etc.).
Certifique-se de estar usando um certificado válido (emitido por uma CA confiável, não expirado, o assunto do certificado corresponde ao registro MX que entrega mensagens para o seu domínio).
Configure um registro TLS-RPT por meio do qual os relatórios de aplicação de política serão entregues (por serviços que suportam o envio de relatórios TLS). Entrada de exemplo (para o domínio example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Esta entrada instrui os remetentes de e-mail a enviar relatórios estatísticos sobre o uso de TLS em SMTP para [email protected].

Monitore os relatórios por vários dias para garantir que não haja erros.
Publique a política MTA-STS por HTTPS. A política é publicada como um arquivo de texto com terminadores de linha CRLF por local.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Política de exemplo:
```
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 (atualmente STSv1), Modo define o modo de aplicação da política, teste — modo de teste (a política não é aplicada), impor — modo de “combate”. Primeiro publique a política com mode:testing, se não houver problemas com a política no modo de teste, depois de um tempo você pode mudar para mode:force.

Em mx, é especificada uma lista de todos os servidores de correio que podem aceitar correio para o seu domínio (cada servidor deve ter um certificado configurado que corresponda ao nome especificado em mx). Max_age especifica o tempo de cache da política (uma vez que a política lembrada será aplicada mesmo que o invasor bloqueie sua entrega ou corrompa os registros DNS durante o tempo de cache, você pode sinalizar a necessidade de solicitar a política novamente alterando o DNS mta-sts registro).
Publique um registro TXT no DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Um identificador arbitrário (por exemplo, um carimbo de data e hora) pode ser usado no campo id; quando a política muda, ela deve mudar, isso permite que os remetentes entendam que precisam solicitar novamente a política em cache (se o identificador for diferente do armazenado em cache).

Suporte MTA-STS no lado do remetente

Até agora está ruim com ela, porque... novo padrão.

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

Como posfácio sobre “TLS obrigatório”

Ultimamente, os reguladores têm prestado atenção à segurança do e-mail (e isso é bom). Por exemplo, o DMARC é obrigatório para todas as agências governamentais nos Estados Unidos e é cada vez mais exigido no sector financeiro, com a penetração da norma a atingir 90% em áreas regulamentadas. Agora, alguns reguladores exigem a implementação de “TLS obrigatório” com domínios individuais, mas o mecanismo para garantir o “TLS obrigatório” não está definido e na prática esta configuração é muitas vezes implementada de uma forma que não protege nem minimamente contra ataques reais que já são previstos em mecanismos como DANE ou MTA-STS.

Caso o regulador exija a implementação de “TLS obrigatório” com domínios separados, recomendamos considerar o MTA-STS ou seu análogo parcial como o mecanismo mais adequado, pois elimina a necessidade de fazer configurações seguras para cada domínio separadamente. Se você tiver dificuldades para implementar a parte cliente do MTA-STS (até que o protocolo receba amplo suporte, provavelmente isso acontecerá), podemos recomendar esta abordagem:

Publique uma política MTA-STS e/ou registros DANE (DANE só faz sentido se o DNSSEC já estiver habilitado para o seu domínio, e MTA-STS em qualquer caso), isso protegerá o tráfego em sua direção e eliminará a necessidade de solicitar outros serviços de correio para configurar o TLS obrigatório para o seu domínio se o serviço de correio já suportar MTA-STS e/ou DANE.
Para grandes serviços de e-mail, implemente um “análogo” do MTA-STS por meio de configurações de transporte separadas para cada domínio, o que corrigirá o MX usado para retransmissão de correio e exigirá a verificação obrigatória de um certificado TLS para ele. Se os domínios já publicam uma política MTA-STS, isso provavelmente poderá ser feito sem problemas. Por si só, habilitar o TLS obrigatório para um domínio sem consertar a retransmissão e verificar o certificado para ele é ineficaz do ponto de vista da segurança e não acrescenta nada aos mecanismos STARTTLS existentes.

Fonte: habr.com

Mail.ru mail começa a aplicar políticas MTA-STS em modo de teste