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





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



  1. Configura suporte para STARTTLS com um certificado válido no servidor de e-mail. 
  2. 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.
  3. 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:



  1. Configure STARTTLS no MTA que você está usando (postfix, exim, sendmail, Microsoft Exchange, etc.).
  2. , ( CA, , MX-, ).
  3. TLS-RPT , ( TLS). ( example.com):



    smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:tlsrpt@example.com»


    TLS SMTP tlsrpt@exmple.com.



    , .
  4. 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).
  5. 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.





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:



  1. 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.
  2. «» MTA-STS , MX TLS-. MTA-STS, , , . TLS STARTTLS.



All Articles