En resumen, MTA-STS es una forma de proteger aún más los correos electrónicos contra la interceptación (es decir, ataques de intermediario, también conocidos como MitM) cuando se transmiten entre servidores de correo. Resuelve parcialmente los problemas arquitectónicos heredados de los protocolos de correo electrónico y se describe en el estándar relativamente reciente RFC 8461. Mail.ru es el primer servicio de correo importante en RuNet que implementa este estándar. Y se describe con más detalle debajo del corte.

¿Qué problema resuelve MTA-STS?

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

¿Cómo es el mecanismo para entregar una carta de un usuario a otro?

Históricamente, un ataque MitM era posible en todos los lugares por donde circula el correo.

RFC 8314 requiere el uso de TLS entre la aplicación de usuario de correo (MUA) y el servidor de correo. Si su servidor y las aplicaciones de correo que utiliza cumplen con RFC 8314, entonces ha eliminado (en gran medida) la posibilidad de ataques Man-in-the-Middle entre el usuario y los servidores de correo.

Seguir las prácticas generalmente aceptadas (estandarizadas por RFC 8314) elimina el ataque cerca del usuario:

Los servidores de correo Mail.ru cumplían 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 adicional. Pero, si su servidor de correo aún permite que los usuarios utilicen 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 que los usuarios no seguros se conecten (esto es exactamente lo que requiere RFC 8314). Esto a veces es difícil, pero factible. 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 inmediato sin interrumpir la conectividad. SMTP ha proporcionado durante mucho tiempo la extensión STARTTLS, que permite que los servidores que admiten cifrado cambien a TLS. Pero un atacante que tiene la capacidad de influir en el tráfico puede "cortar" información sobre la compatibilidad con este comando y obligar a los servidores a comunicarse mediante un protocolo de texto plano (el llamado ataque de degradación). Por la misma razón, STARTTLS generalmente no verifica la validez del certificado (un certificado que no es de confianza puede proteger contra ataques pasivos, y esto no es peor que enviar un mensaje en texto claro). Por lo tanto, STARTTLS sólo protege contra escuchas pasivas.

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

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

Cómo funciona MTA-STS

beneficiario

1. Configura el soporte de STARTTLS con un certificado válido en el servidor de correo. 
2. Publica la política MTA-STS a través de HTTPS; para la publicación se utilizan, por ejemplo, un dominio mta-sts especial y una ruta especial conocida 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 especial _mta-sts en DNS con la versión de la política. Cuando la política cambia, esta entrada debe actualizarse (esto le indica al remitente que vuelva a consultar la política). Por ejemplo, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Remitente

El remitente solicita el registro DNS _mta-sts y, 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 falsifique 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.

Ventajas 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 destinatario no se requiere ningún soporte de software especial para el estándar.

Desventajas de MTA-STS

Es necesario monitorear la validez del certificado del servidor web y de correo, la correspondencia de nombres y la renovación oportuna. Los problemas con el certificado provocarán que no se pueda entregar el correo.

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

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

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 mediante la transparencia del certificado. Por lo tanto, en general, MTA-STS mitiga, pero no elimina por completo, la posibilidad de interceptación del tráfico.

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

Estándar de la competencia - DANE

El DANE utiliza DNSSEC para publicar información de certificados y no requiere confianza en autoridades certificadoras externas, lo cual es mucho más seguro. Pero el uso de DNSSEC conduce con mucha más frecuencia a fallas técnicas, según las estadísticas de varios años de uso (aunque en general hay una tendencia positiva en la confiabilidad de DNSSEC y su soporte técnico). Para implementar DANE en SMTP en el lado del destinatario, la presencia de DNSSEC para la zona DNS es obligatoria, y el soporte correcto para NSEC/NSEC3 es esencial para DANE, con lo cual existen problemas sistémicos en DNSSEC.

Si DNSSEC no está configurado correctamente, puede provocar fallas en la entrega de correo si el lado emisor 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 algunos software de servidor del lado 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 ha ralentizado significativamente la implementación del DANE en todos estos años que lleva existiendo la norma.

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 lleva bastante tiempo publicando una política MTA-STS para todos los dominios principales. Actualmente estamos implementando la parte del cliente del estándar. Al momento de escribir este artículo, las políticas se aplican en un modo sin bloqueo (si una política bloquea la entrega, la carta se entregará a través de un servidor "de repuesto" sin aplicar políticas), luego el modo de bloqueo se forzará en una pequeña parte. del tráfico SMTP saliente, gradualmente para el 100% del tráfico se admitirá la aplicación de políticas.

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

Hasta ahora, las políticas MTA-STS publican aproximadamente el 0.05% de los dominios activos, pero, sin embargo, ya protegen un gran volumen de tráfico de correo, porque El estándar cuenta con el apoyo de los principales actores: Google, Comcast y, en parte, Verizon (AOL, Yahoo). Muchos otros servicios postales han anunciado que implementarán el soporte para el estándar en un futuro próximo.

¿Cómo me afectará esto?

No, a menos que su dominio publique una política MTA-STS. Si publica la política, los correos electrónicos de los usuarios de su servidor de correo estarán mejor protegidos contra la interceptación.

¿Cómo implemento MTA-STS?

Soporte MTA-STS en el lado del destinatario

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

Paso a paso, se ve así:

1. Configure STARTTLS en el MTA que esté utilizando (postfix, exim, sendmail, Microsoft Exchange, etc.).
2. Asegúrese de estar utilizando un certificado válido (emitido por una CA confiable, no vencido, el asunto del certificado coincide con el registro MX que entrega el correo para su dominio).
3. Configure un registro TLS-RPT a través del cual se entregarán los informes de aplicación de políticas (mediante servicios que admiten el envío de informes TLS). Entrada de ejemplo (para el dominio ejemplo.com):

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»

   Esta entrada indica a los remitentes de correo que envíen informes estadísticos sobre el uso de TLS en SMTP a [email protected].

   Supervise los informes durante varios días para asegurarse de que no haya errores.

4. Publique la política MTA-STS a través de HTTPS. La política se publica como un archivo de texto con terminadores de línea CRLF por ubicación.

   https://mta-sts.example.com/.well-known/mta-sts.txt
   

   Política de ejemplo:

   version: STSv1
   mode: enforce
   mx: mxs.mail.ru
   mx: emx.mail.ru
   mx: mx2.corp.mail.ru
   max_age: 86400
   

   El campo de versión contiene la versión de la política (actualmente STSv1), Modo establece el modo de aplicación de la política, prueba: modo de prueba (la política no se aplica), aplicación: modo “combate”. Primero publique la política con el modo: prueba, si no hay problemas con la política en el modo de prueba, después de un tiempo puede cambiar al modo: aplicar.

   En mx, se especifica una lista de todos los servidores de correo que pueden aceptar correo para su dominio (cada servidor debe tener un certificado configurado que coincida con el nombre especificado en mx). Max_age especifica el tiempo de almacenamiento en caché de la política (una vez que se aplicará la política recordada, incluso si el atacante bloquea su entrega o corrompe los registros DNS durante el tiempo de almacenamiento en caché, puede indicar la necesidad de solicitar la política nuevamente cambiando el DNS de mta-sts registro).

5. Publicar un registro TXT en DNS: 

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

   Se puede usar un identificador arbitrario (por ejemplo, una marca de tiempo) en el campo id; cuando la política cambia, debería cambiar, esto permite a los remitentes comprender que necesitan volver a solicitar la política almacenada en caché (si el identificador es diferente del uno almacenado en caché).

Soporte MTA-STS en el lado del remitente

Hasta ahora le va mal, porque... estándar nuevo.

• Exim: no hay 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 sobre “TLS obligatorio”

Últimamente, los reguladores han estado prestando atención a la seguridad del correo electrónico (y eso es bueno). Por ejemplo, DMARC es obligatorio para todas las agencias gubernamentales en los Estados Unidos y cada vez se requiere más en el sector financiero, con una penetración del estándar que alcanza el 90% en áreas reguladas. Ahora algunos reguladores exigen la implementación de "TLS obligatorio" con dominios individuales, pero 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 no protege ni siquiera mínimamente contra ataques reales que ya están previsto en mecanismos como el DANE o el MTA-STS.

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

1. Publicar una política MTA-STS y/o registros DANE (DANE tiene sentido 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 preguntar a otros servicios de correo. para configurar TLS obligatorio para su dominio si el servicio de correo ya soporta MTA-STS y/o DANE.
2. Para servicios de correo electrónico grandes, implemente un "análogo" de MTA-STS a través de configuraciones de transporte separadas para cada dominio, lo que arreglará el MX utilizado para la retransmisión de correo y requerirá la verificación obligatoria de un certificado TLS para ello. Si los dominios ya publican una política MTA-STS, es probable que esto se pueda hacer sin problemas. Por sí solo, habilitar TLS obligatorio para un dominio sin arreglar el relé y verificar el certificado es ineficaz desde el punto de vista de la seguridad y no agrega nada a los mecanismos STARTTLS existentes.

Fuente: habr.com