En resumo, MTA-STS é unha forma de protexer aínda máis os correos electrónicos da interceptación (é dicir, ataques man-in-the-middle, tamén coñecidos como MitM) cando se transmiten entre servidores de correo. Resolve parcialmente os problemas arquitectónicos legados dos protocolos de correo electrónico e descríbese no estándar relativamente recente RFC 8461. Mail.ru é o primeiro servizo de correo importante de RuNet que implementa este estándar. E descríbese con máis detalle baixo o corte.

Que problema resolve MTA-STS?

Históricamente, os protocolos de correo electrónico (SMTP, POP3, IMAP) transmitían información en texto claro, o que permitía interceptala, por exemplo, ao acceder a unha canle de comunicación.

Como é o mecanismo para enviar unha carta dun usuario a outro:

Historicamente, un ataque MitM era posible en todos os lugares onde circula o correo.

O RFC 8314 require o uso de TLS entre a aplicación de usuario de correo (MUA) e o servidor de correo. Se o seu servidor e as aplicacións de correo que utiliza son compatibles coa RFC 8314, entón eliminou (en gran parte) a posibilidade de ataques Man-in-the-Middle entre o usuario e os servidores de correo.

Seguir as prácticas xeralmente aceptadas (estandarizadas por RFC 8314) elimina o ataque preto do usuario:

Os servidores de correo de Mail.ru cumpriron coa RFC 8314 mesmo antes de que se adoptase o estándar; de feito, simplemente captura prácticas xa aceptadas e non tivemos que configurar nada adicional. Pero, se o seu servidor de correo aínda permite que os usuarios usen protocolos inseguros, asegúrese de implementar as recomendacións deste estándar, porque O máis probable é que polo menos algúns dos teus usuarios traballen co correo sen cifrado, aínda que o admitas.

O cliente de correo sempre traballa co mesmo servidor de correo da mesma organización. E pode obrigar a todos os usuarios a conectarse de forma segura e, a continuación, facer que sexa tecnicamente imposible que se conecten aos usuarios non seguros (isto é exactamente o que require a RFC 8314). Isto ás veces é difícil, pero factible. O tráfico entre servidores de correo aínda é máis complicado. Os servidores pertencen a organizacións diferentes e úsanse a miúdo nun modo "definir e esquecer", o que fai imposible cambiar a un protocolo seguro á vez sen romper a conectividade. SMTP proporciona desde hai tempo a extensión STARTTLS, que permite aos servidores compatibles con cifrado cambiar a TLS. Pero un atacante que teña a capacidade de influír no tráfico pode "cortar" a información sobre a compatibilidade con este comando e obrigar aos servidores a comunicarse mediante un protocolo de texto plano (o chamado ataque de downgrade). Polo mesmo motivo, STARTTLS normalmente non verifica a validez do certificado (un certificado non fiable pode protexer contra ataques pasivos, e isto non é peor que enviar unha mensaxe en texto claro). Polo tanto, STARTTLS só protexe contra as escoitas pasivas.

MTA-STS elimina parcialmente o problema de interceptar cartas entre servidores de correo, cando o atacante ten a capacidade de influír activamente no tráfico. Se o dominio do destinatario publica unha política MTA-STS e o servidor do remitente admite MTA-STS, só enviará o correo electrónico a través dunha conexión TLS, só aos servidores definidos pola política e só coa verificación do certificado do servidor.

Por que parcialmente? MTA-STS só funciona se ambas as partes se preocuparon de implementar este estándar, e MTA-STS non protexe contra escenarios nos que un atacante pode obter un certificado de dominio válido dunha das CA públicas.

Como funciona MTA-STS

beneficiario

Configura a compatibilidade con STARTTLS cun certificado válido no servidor de correo.
Publica a política MTA-STS a través de HTTPS; para a publicación utilízase un dominio especial mta-sts e unha ruta especial coñecida, por exemplo https://mta-sts.mail.ru/.well-known/mta-sts.txt. A política contén unha lista de servidores de correo (mx) que teñen dereito a recibir correo para este dominio.
Publica un rexistro TXT especial _mta-sts en DNS coa versión da política. Cando a política cambie, esta entrada debe actualizarse (isto indica ao remitente que volva consultar a política). Por exemplo, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Remitente

O remitente solicita o rexistro DNS _mta-sts e, se está dispoñible, fai unha solicitude de política a través de HTTPS (comprobando o certificado). A política resultante almacénase na caché (no caso de que un atacante bloquee o acceso a ela ou falsee o rexistro DNS).

Ao enviar correo, compróbase que:

o servidor ao que se envía o correo está na política;
o servidor acepta correo mediante TLS (STARTTLS) e ten un certificado válido.

Vantaxes de MTA-STS

MTA-STS utiliza tecnoloxías que xa están implementadas na maioría das organizacións (SMTP+STARTTLS, HTTPS, DNS). Para a implementación no lado do destinatario, non se precisa soporte de software especial para o estándar.

Desvantaxes de MTA-STS

É necesario supervisar a validez do certificado do servidor web e de correo, a correspondencia dos nomes e a renovación oportuna. Os problemas co certificado provocarán que o correo non se poida entregar.

No lado do remitente, é necesario un MTA con compatibilidade con políticas MTA-STS; actualmente, MTA-STS non é compatible de forma predeterminada no MTA.

MTA-STS usa unha lista de CA raíz de confianza.

MTA-STS non protexe contra ataques nos que o atacante utiliza un certificado válido. Na maioría dos casos, MitM preto do servidor implica a posibilidade de emitir un certificado. Este ataque pódese detectar mediante Certificate Transparency. Polo tanto, en xeral, MTA-STS mitiga, pero non elimina por completo, a posibilidade de interceptación do tráfico.

Os dous últimos puntos fan que MTA-STS sexa menos seguro que o estándar DANE da competencia para SMTP (RFC 7672), pero técnicamente máis fiable, é dicir. para MTA-STS hai unha baixa probabilidade de que a carta non se entregue debido a problemas técnicos causados pola implementación da norma.

Estándar competidor - DANE

DANE usa DNSSEC para publicar información de certificados e non require confianza en autoridades de certificación externas, o que é moito máis seguro. Pero o uso de DNSSEC con maior frecuencia leva a fallos técnicos, baseados nas estatísticas de varios anos de uso (aínda que en xeral hai unha tendencia positiva na fiabilidade de DNSSEC e o seu soporte técnico). Para implementar DANE en SMTP no lado do destinatario, é obrigatoria a presenza de DNSSEC para a zona DNS, e o soporte correcto para NSEC/NSEC3 é fundamental para DANE, co que existen problemas sistémicos en DNSSEC.

Se DNSSEC non está configurado correctamente, pode producirse erros na entrega de correo se o lado emisor admite DANE, aínda que o lado receptor non saiba nada diso. Polo tanto, a pesar de que DANE é un estándar máis antigo e seguro e xa está soportado nalgúns programas de servidor do lado do remitente, de feito a súa penetración segue sendo insignificante, moitas organizacións non están preparadas para implementalo debido á necesidade de implementar DNSSEC. isto freou significativamente a implantación de DANE todos eses anos que existe o estándar.

DANE e MTA-STS non entran en conflito entre si e pódense usar xuntos.

Que hai co soporte MTA-STS en Mail.ru Mail?

Mail.ru leva bastante tempo publicando unha política MTA-STS para todos os dominios principais. Actualmente estamos implementando a parte cliente do estándar. No momento de escribir este artigo, as políticas aplícanse nun modo sen bloqueo (se a entrega está bloqueada por unha política, a carta enviarase a través dun servidor "repuesto" sen aplicar políticas), entón o modo de bloqueo será forzado nunha pequena parte de tráfico SMTP saínte, gradualmente para o 100 % do tráfico será compatible coa aplicación das políticas.

Quen máis apoia o estándar?

Ata o momento, as políticas MTA-STS publican aproximadamente o 0.05% dos dominios activos, pero, con todo, xa protexen un gran volume de tráfico de correo, porque O estándar é compatible cos principais xogadores: Google, Comcast e en parte Verizon (AOL, Yahoo). Moitos outros servizos postais anunciaron que o soporte para o estándar se implementará nun futuro próximo.

Como me afectará isto?

Non a menos que o teu dominio publique unha política MTA-STS. Se publicas a política, os correos electrónicos dos usuarios do teu servidor de correo estarán mellor protexidos contra a interceptación.

Como implemento MTA-STS?

Soporte MTA-STS no lado do destinatario

Basta con publicar a política a través de HTTPS e rexistros en DNS, configurar un certificado válido dunha das CA de confianza (é posible cifrar) para STARTTLS no MTA (STARTTLS é compatible con todos os MTA modernos), sen soporte especial do Requírese MTA.

Paso a paso, vese así:

Configure STARTTLS no MTA que está a usar (postfix, exim, sendmail, Microsoft Exchange, etc.).
Asegúrate de que estás a usar un certificado válido (emitido por unha CA de confianza, non caducado, o asunto do certificado coincide co rexistro MX que entrega o correo para o teu dominio).
Configure un rexistro TLS-RPT a través do cal se entregarán os informes de aplicación de políticas (por servizos que admiten o envío de informes TLS). Exemplo de entrada (para o dominio example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Esta entrada indica aos remitentes de correo que envíen informes estatísticos sobre o uso de TLS en SMTP [email protected].

Supervisa os informes durante varios días para asegurarte de que non hai erros.
Publicar a política MTA-STS a través de HTTPS. A política publícase como un ficheiro de texto con terminadores de liña CRLF por localización.
```
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 de versión contén a versión da política (actualmente STSv1), Modo establece o modo de aplicación da política, proba — modo de proba (a política non se aplica), aplicar — modo “combate”. Primeiro publique a política co modo: proba, se non hai problemas coa política no modo de proba, despois dun tempo pode cambiar ao modo: aplicar.

En mx, especifícase unha lista de todos os servidores de correo que poden aceptar correo para o teu dominio (cada servidor debe ter un certificado configurado que coincida co nome especificado en mx). Max_age especifica o tempo de almacenamento na caché da política (unha vez que se aplique a política lembrada aínda que o atacante bloquee a súa entrega ou corrompa os rexistros DNS durante o tempo de almacenamento na caché, pode indicar a necesidade de solicitar a política de novo cambiando o DNS de mta-sts). rexistro).
Publicar un rexistro TXT en DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Podes usar un identificador arbitrario (por exemplo, unha marca de tempo) no campo ID; cando a política cambia, debería cambiar, isto permite aos remitentes entender que necesitan volver solicitar a política almacenada na caché (se o identificador é diferente do almacenado en caché).

Soporte MTA-STS no lado do remitente

Ata agora está mal con ela, porque... estándar fresco.

Exim: non hai soporte integrado, hai un script de terceiros https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix: non hai soporte integrado, hai un script de terceiros que se describe detalladamente en Habré https://habr.com/en/post/424961/

Como epílogo sobre "TLS obrigatorio"

Ultimamente, os reguladores están prestando atención á seguridade do correo electrónico (e iso é bo). Por exemplo, o DMARC é obrigatorio para todas as axencias gobernamentais dos Estados Unidos e é cada vez máis esixido no sector financeiro, xa que a penetración do estándar alcanza o 90 % nas áreas reguladas. Agora algúns reguladores requiren a implementación de "TLS obrigatorio" con dominios individuais, pero o mecanismo para garantir o "TLS obrigatorio" non está definido e, na práctica, esta configuración adoita implementarse dun xeito que nin sequera protexe mínimamente contra ataques reais que xa están previstos en mecanismos como DANE ou MTA-STS.

Se o regulador esixe a implementación de "TLS obrigatorios" con dominios separados, recomendamos considerar MTA-STS ou o seu análogo parcial como o mecanismo máis adecuado, elimina a necesidade de realizar configuracións seguras para cada dominio por separado. Se tes dificultades para implementar a parte cliente de MTA-STS (ata que o protocolo reciba un apoio xeneralizado, probablemente o farán), podemos recomendar este enfoque:

Publica unha política MTA-STS e/ou rexistros DANE (DANE só ten sentido se DNSSEC xa está habilitado para o teu dominio e MTA-STS en calquera caso), isto protexerá o tráfico na túa dirección e eliminará a necesidade de preguntar a outros servizos de correo electrónico. para configurar TLS obrigatorio para o teu dominio se o servizo de correo xa admite MTA-STS e/ou DANE.
Para servizos de correo electrónico grandes, implemente un "análogo" de MTA-STS mediante configuracións de transporte separadas para cada dominio, que corrixirá o MX utilizado para a retransmisión de correo e requirirá a verificación obrigatoria dun certificado TLS para el. Se os dominios xa publican unha política MTA-STS, é probable que isto se faga sen dor. Por si só, habilitar TLS obrigatorio para un dominio sen arranxar o relé e verificar o certificado para el é ineficaz desde o punto de vista da seguridade e non engade nada aos mecanismos STARTTLS existentes.

Fonte: www.habr.com

O correo de Mail.ru comeza a aplicar políticas MTA-STS no modo de proba