En resumen, MTA-STS es una forma de proteger adicionalmente los correos electrónicos de interceptaciones (es decir, ataques de intrusión entre dos partes, conocidos como MitM) durante la transmisión entre servidores de correo. Ayuda a abordar problemas arquitectónicos heredados de los protocolos de correo electrónico y está descrito en el estándar relativamente nuevo RFC 8461. Mail.ru es el primer gran servicio de correo en Runet que implementa este estándar. A continuación, se detalla más información.

¿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 permite su interceptación, por ejemplo, al acceder al canal de comunicación.

¿Cómo funciona el mecanismo de entrega de un correo de un usuario a otro?

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

El estándar 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 utilizadas cumplen con el RFC 8314, ha eliminado (en gran medida) la posibilidad de ataques Man-in-the-Middle entre el usuario y los servidores de correo.

Cumplir con las buenas prácticas comúnmente aceptadas (estándares RFC 8314) elimina el ataque cerca del usuario:

Los servidores de correo de Mail.ru ya cumplían con el RFC 8314 antes de la adopción del estándar; de hecho, simplemente documenta las prácticas que ya se estaban utilizando, y no tuvimos que realizar configuraciones adicionales. Pero, si su servidor de correo aún permite el acceso a los usuarios mediante protocolos inseguros, es esencial implementar las recomendaciones de este estándar, ya que es probable que al menos parte de sus usuarios trabajen con correo sin cifrado, incluso si usted lo soporta.

Un cliente de correo siempre trabaja con el mismo servidor de correo de la misma organización. Además, se puede forzar a todos los usuarios a conectarse de manera segura, impidiendo técnicamente las conexiones inseguras (esto es precisamente lo que requiere el RFC 8314). A veces es complicado, pero es factible. El tráfico entre los servidores de correo es aún más complicado. Los servidores pertenecen a diferentes organizaciones y a menudo se utilizan en modo "instalado y olvidado", lo que hace imposible un cambio instantáneo a un protocolo seguro sin interrumpir la conectividad. En SMTP, desde hace tiempo se ha previsto la extensión STARTTLS, que permite a los servidores que admiten cifrado cambiar a TLS. Sin embargo, un atacante que tiene la capacidad de influir en el tráfico puede "suprimir" la información sobre el soporte de este comando y forzar a los servidores a comunicarse mediante el protocolo de texto normal (esto se conoce como ataque de degradación). Por esta misma razón, generalmente no se verifica la validez del certificado para STARTTLS (un certificado no confiable puede proteger contra ataques pasivos, y eso no es peor que enviar un correo en texto plano). Por lo tanto, STARTTLS solo protege contra la escucha pasiva.

MTA-STS elimina en parte el problema de la interceptación de correos entre servidores de correo cuando un atacante tiene la oportunidad 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, enviará el correo solo a través de una conexión TLS, únicamente a los servidores especificados en la política, y solo tras verificar el certificado del servidor.

¿Por qué solo en parte? MTA-STS funciona únicamente si ambas partes han implementado este estándar, y MTA-STS no protege contra escenarios en los que un atacante logra obtener un certificado válido para el dominio de uno de los CA públicos.

Cómo funciona MTA-STS

Destinatario

1. Configura el soporte de STARTTLS con un certificado válido en el servidor de correo. 
2. Publica a través de HTTPS una política MTA-STS, utilizando un dominio especial mta-sts y una ruta well-known específica, por ejemplo 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 correos para este dominio.
3. Publica un registro TXT especial _mta-sts en DNS con la versión de la política. Cuando se actualiza la política, este registro debe ser modificado (esto indica al remitente que necesita volver 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, y si está disponible, realiza una solicitud de política a través de HTTPS (verificando el certificado). La política obtenida se almacena en caché (en caso de que un atacante bloquee el acceso a ella o sustituya el registro DNS).

Al enviar correos electrónicos, se verifica que:

• el servidor al que se entrega el correo está en la política;
• el servidor acepta el 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). No se requiere soporte de software especial para su implementación en el lado del receptor.

Desventajas de MTA-STS

Es necesario controlar la validez del certificado del servidor web y de correo, la correspondencia de nombres y la actualización oportuna. Problemas con el certificado llevarán a la imposibilidad de entregar el correo.

Del lado del remitente, se requiere un MTA que soporte políticas MTA-STS; actualmente, el soporte de MTA-STS no está disponible 'out of the box' en 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, un MitM cercano al servidor implica la posibilidad de emitir un certificado. Este tipo de ataque puede detectarse mediante Certificate Transparency. Por lo tanto, en general, MTA-STS mitiga, pero no elimina completamente la posibilidad de interceptar el 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 técnicamente confiable, es decir, para MTA-STS la probabilidad de que un correo no se entregue debido a problemas técnicos derivados de la implementación del estándar es baja.

El estándar competidor es DANE

DANE utiliza DNSSEC para publicar información sobre certificados y no requiere confianza en autoridades de certificación externas, lo que es mucho más seguro. Sin embargo, el uso de DNSSEC a menudo conduce a fallos técnicos, según la estadística de varios años de uso (aunque en términos de confiabilidad y soporte técnico de DNSSEC se observa una dinámica positiva en general). Para implementar DANE en SMTP del lado del receptor, es obligatorio tener DNSSEC para la zona DNS, y es esencial que DANE sea compatible con NSEC/NSEC3, con la que DNSSEC tiene problemas sistémicos.

Si DNSSEC está configurado incorrectamente, esto puede llevar a fallos en la entrega de correo si la parte emisora admite DANE, incluso si la parte receptora no conoce sobre él. Por lo tanto, a pesar de que DANE es un estándar más antiguo y seguro que ya es compatible con cierto software de servidor del lado del emisor, su penetración real sigue siendo insignificante; muchas organizaciones no están dispuestas a implementarlo debido a la necesidad de implementar DNSSEC, lo que ha retrasado significativamente la adopción de DANE durante todos los años que ha existido el estándar.

DANE y MTA-STS no son incompatibles y pueden ser utilizados en conjunto.

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

Mail.ru ha estado publicando políticas MTA-STS para todos los dominios principales desde hace bastante tiempo. Actualmente estamos trabajando en la implementación del lado del cliente del estándar. Al momento de escribir este artículo, las políticas se aplican en modo no bloqueante (si la entrega es bloqueada por la política, el correo será entregado a través de un servidor "alternativo" sin aplicar políticas), luego se forzará el modo bloqueante para una pequeña parte del tráfico SMTP saliente, y gradualmente se aplicará este modo para el 100% del tráfico.

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

Actualmente, aproximadamente el 0.05% de los dominios activos publican políticas MTA-STS, pero, no obstante, ya protegen un gran volumen de tráfico de correo, ya que estándares están respaldados por grandes actores como Google, Comcast y parcialmente Verizon (AOL, Yahoo). Muchos otros servicios de correo han declarado que implementarán el soporte del estándar en un futuro cercano.

¿Cómo me afectará esto?

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

¿Cómo implemento MTA-STS?

Soporte de MTA-STS en el lado del receptor

Basta con publicar la política a través de HTTPS y los registros en DNS, configurar un certificado válido de una de las CA de confianza (puede ser Let’s Encrypt) para STARTTLS en MTA (STARTTLS es compatible con todos los MTA modernos), no se requiere soporte específico por parte del MTA.

Paso a paso, se ve así:

1. Configure STARTTLS en el MTA utilizado (postfix, exim, sendmail, Microsoft Exchange, etc.).
2. Asegúrese de que se está utilizando un certificado válido (emitido por una CA de confianza, no esté caducado, el sujeto del certificado corresponda al registro MX por el cual se entrega correo a su dominio).
3. Configure un registro TLS-RPT, donde se enviarán los informes sobre la aplicación de políticas (servicios que admiten el envío de informes TLS). Ejemplo de registro (para el dominio example.com):

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

   Este registro instruye a los remitentes de correo a enviar informes estadísticos sobre el uso de TLS en SMTP a la dirección tlsrpt@exmple.com.

   Haga un seguimiento de los informes durante unos días, asegúrese 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 en la ubicación.

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

   Ejemplo de política:

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

   El campo version contiene la versión de la política (actualmente es STSv1), Mode establece el modo de aplicación de la política, testing — modo de prueba (la política no se aplica), enforce — modo 'producción'. Primero publique la política con mode: testing, si no hay problemas con la política en modo de prueba, después de un tiempo podrá cambiar a mode: enforce.

   En mx se establece la lista de todos los servidores de correo que pueden recibir correos para su dominio (cada servidor debe tener un certificado configurado, correspondiente al nombre indicado en mx). Max_age establece el tiempo de almacenamiento en caché de la política (una vez almacenada, la política se aplicará incluso si un atacante bloquea su salida o arruina los registros DNS durante el tiempo de caché; se puede sinalizar la necesidad de solicitar nuevamente la política mediante el cambio de registro mta-sts en DNS).

5. Publique un registro TXT en DNS: 

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

   En el campo id se puede utilizar un identificador arbitrario (como una marca de tiempo), al cambiar la política debe cambiarse, lo que permite a los remitentes entender que es necesario volver a solicitar la política en caché (si el identificador difiere del almacenado en caché).

Soporte MTA-STS del lado del remitente

Por ahora es deficiente, ya que el estándar es 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 del que se habla detalladamente en Habr https://habr.com/en/post/424961/

Como postdata sobre el «mandatory TLS»

Recientemente, los reguladores están prestando atención a la seguridad del correo (y eso es positivo). Por ejemplo, DMARC es obligatorio para todas las instituciones gubernamentales en EE. UU. y cada vez es más requerido en el sector financiero; en sectores regulados, la penetración del estándar alcanza el 90%. Ahora algunos reguladores exigen la implementación de «mandatory TLS» con dominios específicos, pero no se define el mecanismo para garantizar el «mandatory TLS» y en la práctica esta configuración a menudo se implementa de una manera que ni siquiera protege de manera mínima contra ataques reales, que ya se prevén en mecanismos como DANE o MTA-STS.

Si el regulador exige la implementación de «mandatory TLS» con dominios específicos, 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 con la implementación de la parte cliente de MTA-STS (mientras el protocolo no reciba un amplio soporte, es probable que lo tenga), se puede recomendar el siguiente enfoque:

1. Publique la política MTA-STS y/o registros DANE (DANE tiene sentido agregarlo solo si su dominio ya tiene habilitado DNSSEC, y MTA-STS en cualquier caso), esto protegerá el tráfico hacia su dirección y eliminará la necesidad de pedir a otros servicios de correo que configuren mandatory TLS para su dominio, si el servicio de correo ya admite MTA-STS y/o DANE.
2. Para los grandes servicios de correo, implemente un "análoga" de MTA-STS a través de configuraciones de transporte separadas para cada dominio, que fijarán el MX utilizado para el relevo de correo y requerirán la verificación obligatoria del certificado TLS. Si los dominios ya publican una política de MTA-STS, es probable que esto se pueda hacer sin dolor. La inclusión de TLS obligatorio para un dominio, sin fijar el relevo y verificar el certificado, no es eficaz en términos de seguridad y no añade nada a los mecanismos existentes de STARTTLS.

Fuente: habr.com