En resumen, MTA-STS es una forma de proteger adicionalmente los correos electrónicos de la interceptación (es decir, ataques de atacante en el medio, también conocidos como MitM) cuando se transfieren entre servidores de correo. Resuelve parcialmente los problemas arquitectónicos heredados de los protocolos de correo electrónico y se describe en el relativamente reciente estándar RFC 8461. Mail.ru Mail es el primer gran servicio postal de la Internet rusa en implementar este estándar. Y con más detalle ya está bajo el corte.

¿Qué problema resuelve MTA-STS?

Históricamente, los protocolos de correo electrónico (SMTP, POP3, IMAP) transmitían información en claro, lo que permite su interceptación, por ejemplo, al acceder a un canal de comunicación.



Cómo se ve el mecanismo para entregar una carta de un usuario a otro:







Históricamente, el ataque MitM era posible en todos los lugares adonde va el correo.



RFC 8314 requiere el uso obligatorio de TLS entre el programa de correo del usuario (MUA) y el servidor de correo. Si su servidor y las aplicaciones de correo que utiliza son compatibles con RFC 8314, entonces ha eliminado (en gran medida) la posibilidad de ataques de intermediario entre el usuario y los servidores de correo.



El cumplimiento de prácticas comunes (estandarizadas por RFC 8314) elimina los ataques de usuarios cercanos:







Los servidores de correo Mail.ru cumplieron con RFC 8314 incluso antes de que se adoptara el estándar, de hecho, simplemente captura las prácticas ya aceptadas y no tuvimos que configurar nada más. Pero, si su servidor de correo aún permite usuarios a través de protocolos inseguros, asegúrese de implementar las recomendaciones de este estándar, porque lo más probable es que al menos algunos de sus usuarios trabajen con correo sin cifrado, incluso si usted lo admite.



El cliente de correo siempre trabaja con el mismo servidor de correo de la misma organización. Y puede obligar a todos los usuarios a conectarse de forma segura, y luego hacer que sea técnicamente imposible conectarse de forma insegura (esto es exactamente lo que requiere RFC 8314). A veces es difícil, pero realizable. El tráfico entre servidores de correo es aún más complicado. Los servidores pertenecen a diferentes organizaciones y, a menudo, se utilizan en modo "configurar y olvidar", lo que hace imposible cambiar a un protocolo seguro de una vez sin interrumpir la conectividad. SMTP ha proporcionado durante mucho tiempo la extensión STARTTLS, que permite a los servidores que admiten el cifrado cambiar a TLS. Pero un atacante que tiene la capacidad de influir en el tráficopuede "cortar" información sobre el soporte de este comando y obligar a los servidores a comunicarse mediante un protocolo de texto sin formato (el llamado ataque de degradación, un ataque para degradar la versión del protocolo). Por la misma razón, para STARTTLS, el cumplimiento del certificado generalmente no se verifica (un certificado que no es de confianza puede proteger contra ataques pasivos, y esto no es peor que enviar un correo electrónico en texto sin cifrar). Por lo tanto, STARTTLS protege solo contra escuchas pasivas.



MTA-STS elimina parcialmente el problema de interceptar mensajes entre servidores de correo, cuando un atacante tiene la capacidad de influir activamente en el tráfico. Si el dominio del destinatario publica la política MTA-STS y el servidor del remitente es compatible con MTA-STS, solo enviará el correo electrónico a través de una conexión TLS, solo a los servidores definidos por la política, y solo con el certificado de servidor verificado.



¿Por qué parcialmente? MTA-STS solo funciona si ambas partes se han encargado de implementar este estándar, y MTA-STS no protege contra escenarios en los que un atacante tiene la oportunidad de obtener un certificado de dominio válido en una de las CA públicas.

Cómo funciona MTA-STS

Recipiente

1. Configura el soporte para STARTTLS con un certificado válido en el servidor de correo. 
2. Publica la política MTA-STS a través de HTTPS, un dominio especial mta-sts y una ruta especial conocida, por ejemplo, se utilizan para la publicación https://mta-sts.mail.ru/.well-known/mta-sts.txt. La política contiene una lista de servidores de correo (mx) que tienen derecho a recibir correo para este dominio.
3. Publica un registro TXT _mta-sts especial en DNS con la versión de la política. Cuando la política cambia, esta entrada debe actualizarse (esto indica al remitente que vuelva a solicitar la política). Por ejemplo,_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Remitente El



remitente solicita el registro DNS _mta-sts, si está disponible, realiza una solicitud de política a través de HTTPS (verificando el certificado). La política resultante se almacena en caché (en caso de que un atacante bloquee el acceso a ella o cambie el registro DNS).



Al enviar correo, se comprueba que:

• el servidor al que se entrega el correo está en la política;
• el servidor acepta correo usando TLS (STARTTLS) y tiene un certificado válido.

Beneficios de MTA-STS

MTA-STS utiliza tecnologías que ya están implementadas en la mayoría de las organizaciones (SMTP + STARTTLS, HTTPS, DNS). Para la implementación en el lado del receptor, no se requiere soporte de software especial para el estándar.

Desventajas de MTA-STS

Es necesario controlar la validez del certificado del servidor web y de correo, la correspondencia de los nombres y la renovación oportuna. Los problemas con el certificado harán imposible la entrega de correo.



En el lado del remitente, se requiere un MTA con soporte para políticas MTA-STS, actualmente MTA-STS no es compatible con el MTA.



MTA-STS utiliza una lista de CA raíz de confianza.



MTA-STS no protege contra ataques en los que el atacante utiliza un certificado válido. En la mayoría de los casos, MitM cerca del servidor implica la posibilidad de emitir un certificado. Un ataque de este tipo se puede detectar a través de la transparencia de certificados. Por lo tanto, en general, MTA-STS mitiga, pero no elimina completamente la posibilidad de interceptación de tráfico.



Los dos últimos puntos hacen que el MTA-STS sea menos seguro que el estándar DANE de la competencia para SMTP (RFC 7672), pero más seguro técnicamente, es decir, para MTA-STS, existe una baja probabilidad de que la carta no se entregue debido a problemas técnicos causados ​​por la implementación de la norma.

Estándar competitivo - DANE

DANE usa DNSSEC para publicar información de certificados y no requiere confianza en CA externas, lo cual es mucho más seguro. Pero es mucho más probable que el uso de DNSSEC conduzca a fallas técnicas, si confiamos en las estadísticas durante varios años de uso (aunque hay una tendencia positiva en la confiabilidad de DNSSEC y su soporte técnico en general). Para implementar DANE en SMTP en el lado del destinatario, la presencia de DNSSEC para la zona DNS es obligatoria, y para DANE es fundamental tener un soporte correcto para NSEC / NSEC3, con lo cual DNSSEC tiene problemas sistémicos.



Si DNSSEC está configurado con errores, puede conducir a denegaciones de entrega de correo si el lado remitente admite DANE, incluso si el lado receptor no sabe nada al respecto. Por lo tanto, a pesar de que DANE es un estándar más antiguo y seguro y ya es compatible con algún software de servidor por parte del remitente, de hecho su penetración sigue siendo insignificante, muchas organizaciones no están preparadas para implementarlo debido a la necesidad de implementar DNSSEC, esto ralentizó significativamente la implementación de DANE. todos esos años que ha existido el estándar.



DANE y MTA-STS no entran en conflicto entre sí y pueden usarse juntos.

¿Qué pasa con el soporte MTA-STS en Mail.ru Mail?

Mail.ru ha estado publicando la política MTA-STS para todos los dominios principales desde hace bastante tiempo. Actualmente estamos implementando el lado del cliente del estándar. En el momento de escribir este artículo, las políticas se aplican en un modo sin bloqueo (si la entrega está bloqueada por una política, la carta se entregará a través de un servidor de "respaldo" sin aplicar políticas), luego el modo de bloqueo se forzará para una pequeña parte del tráfico SMTP saliente, gradualmente para el 100% del tráfico. se admite la aplicación de políticas.

¿Quién más apoya el estándar?

Hasta ahora, las políticas de MTA-STS publican alrededor del 0.05% de los dominios activos, pero, sin embargo, ya están protegiendo un gran volumen de tráfico de correo, porque el estándar es compatible con los principales actores: Google, Comcast y parcialmente Verizon (AOL, Yahoo). Muchos otros servicios postales han anunciado que la compatibilidad con el estándar se implementará en un futuro próximo.

¿Cómo me afectará esto?

Nada si su dominio no publica la política MTA-STS. Si publica la política, los mensajes a los usuarios de su servidor de correo estarán mejor protegidos contra la interceptación.

¿Cómo implemento MTA-STS?

Compatibilidad con MTA-STS en el lado del destinatario



Es suficiente publicar la política a través de registros HTTPS y DNS, configurar un certificado válido de una de las CA confiables (cifremos) para STARTTLS en el MTA (STARTTLS es compatible con todos los MTA modernos), no se requiere soporte especial del MTA ...



Paso a paso, se ve así:

1. Configure STARTTLS en su MTA (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 el registro TXT en DNS: 
   
   
   
   

   _mta-sts.example.com. TXT “v=STSv1; id=someid;”
   

   
   
   En el campo id, puede usar un identificador arbitrario (por ejemplo, una marca de tiempo), al cambiar la política, debe cambiar, esto permite a los remitentes entender que necesitan volver a solicitar la política en caché (si el identificador es diferente del que está en caché).

Soporte para MTA-STS en el remitente



Si bien es malo, porque el estándar es fresco.

• Exim: sin soporte integrado, hay un script de terceros https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix: no hay soporte integrado, hay un script de terceros que se describe en detalle en Habré https://habr.com/en/post/424961/

Como epílogo de "TLS obligatorio"

Los reguladores se han centrado últimamente en la seguridad del correo (y eso es bueno). Por ejemplo, DMARC es obligatorio para todas las agencias gubernamentales en los Estados Unidos y se requiere cada vez más en el sector financiero; en áreas reguladas, la penetración del estándar alcanza el 90%. Ahora, algunos reguladores requieren la implementación de "TLS obligatorio" con dominios separados, pero al mismo tiempo, el mecanismo para garantizar el "TLS obligatorio" no está definido y, en la práctica, esta configuración a menudo se implementa de una manera que ni siquiera protege mínimamente contra ataques reales que ya están previstos en mecanismos tales como DANE o MTA-STS.



Si el regulador requiere la implementación de "TLS obligatorio" con dominios separados, recomendamos considerar MTA-STS o su equivalente parcial como el mecanismo más adecuado, ya que elimina la necesidad de realizar configuraciones seguras para cada dominio por separado. Si tiene dificultades con la implementación del lado del cliente de MTA-STS (hasta que el protocolo haya recibido un soporte generalizado, lo más probable es que lo sea), puede recomendar este enfoque:

1. Publique la política MTA-STS y / o registros DANE (tiene sentido agregar DANE solo si DNSSEC ya está habilitado para su dominio, y MTA-STS en cualquier caso), esto protegerá el tráfico en su dirección y eliminará la necesidad de pedir a otros servicios de correo que configuren TLS obligatorio para su dominio si el servicio postal ya admite MTA-STS y / o DANE.
2. «» MTA-STS , MX TLS-. MTA-STS, , , . TLS STARTTLS.