Como tecnología de comunicación digital, el correo electrónico continúa dominando y creciendo en uso. En mi publicación anterior destaqué muchas de sus virtudes pero también aludí a algunas debilidades que la mayoría de los usuarios desconocen por completo.

En esta publicación, exploraremos estas debilidades con más detalle y, específicamente, cómo se transmite el correo electrónico entre servidores. También destacaremos cómo se pueden abordar estas debilidades con una mayor adopción de extensiones establecidas para los protocolos de correo electrónico tradicionales (p. ej., DANE).

Como siempre, este artículo se basa en mi investigación y práctica personal en el tema, pero compartir conocimientos es una colaboración, así que envíe comentarios o comentarios.

Introducción

Para facilitar la comprensión, destacaré tres fases de alto nivel de cómo se establecen las conexiones entre los servidores de correo.

Descubrimiento del servidor de correo de los destinatarios , el proceso de descubrir qué servidor de correo está destinado a aceptar correo para un dominio de destinatarios determinado.

Conexión al servidor de correo de los destinatarios, habiendo identificado el servidor de correo correcto, el proceso de conexión a él y asegurando la conexión con el cifrado adecuado (también conocido como TLS).

Verificación de que el servidor de correo de los destinatarios es el correcto, ¿podemos estar seguros de que hemos establecido una conexión segura con el servidor legítimo para el dominio de los destinatarios?

Descubrimiento del servidor de correo de los destinatarios

Esto se logra más comúnmente a través de una búsqueda de DNS de los registros MX (Mail Exchange) que apuntan a una o más direcciones IP de servidores de correo que están destinados a recibir correo para el dominio de los destinatarios. Sin embargo, existen otros mecanismos como MTA-STS, registros SRV o incluso registros A. Cubriremos algunos elementos de MTA-STS más adelante, pero no los enfoques de registro SRV/A (aunque comparten las mismas debilidades).

El descubrimiento de los servidores de correo se basa en DNS , y la gran mayoría de las consultas de DNS todavía se basan en paquetes UDP y, por lo tanto, no tienen conexión ni están encriptadas, lo que hace que sea relativamente fácil interceptar e inyectar respuestas falsificadas.

Si bien existen implementaciones de DNS que usan TCP, TLS e incluso DNS sobre HTTPS , son bastante poco comunes pero reducen el potencial de intercepción e inyección entre el cliente y el servidor.

Sin embargo, la implementación de TCP/TLS se enfoca en mejorar o asegurar la conexión, ellos mismos no brindan un mecanismo para garantizar que los datos, las respuestas a las búsquedas de DNS, sean genuinos y no hayan sido alterados.

Aquí es donde entra DNSSEC , proporciona un enfoque de firma digital anclado en la confianza que garantiza que cualquier respuesta de DNS para los dominios habilitados para DNSSEC se pueda validar criptográficamente como genuina y autorizada.

¿Y el DANE?

• El DANE requiere DNSSEC para todas las búsquedas de DNS, lo que mitiga con éxito este riesgo.

• MTA-STS publica los servidores de correo autorizados para un dominio, enumerándolos dentro de un archivo de política de MTA-STS alojado en un servidor web. Si bien la conexión al servidor web en sí puede ser HTTPS (con validación de certificado), no requiere que la búsqueda de DNS de ese servidor web sea segura.
• MTA-STS no exige el uso de DNSSEC; de hecho, entiendo que una de sus "características de diseño" es que no dependía de DNSSEC.

• El descubrimiento de un servidor de correo de dominios de destinatarios depende del DNS, que sin DNSSEC carece de la seguridad para garantizar las respuestas recibidas.
• El DANE exige el uso de DNSSEC, por lo que como extensión de SMTP, es el mecanismo más efectivo para brindar protección contra este riesgo.
• MTA-STS no exige el uso de DNSSEC y, a pesar de alojar la política en un servidor seguro HTTPS, todavía se basa en una búsqueda de DNS tradicional.
• Sin embargo, MTA-STS podría implementarse con DNSSEC, lo que mitigaría gran parte de este riesgo. Esta sería mi recomendación si está en proceso de implementar MTA-STS.

El mundo pasó a HTTPS en lo que pareció un abrir y cerrar de ojos. Hoy en día es muy inusual encontrar un sitio web que no admita HTTPS (incluso aquellos que no toman los datos de su tarjeta de crédito). Sin embargo, el correo electrónico no ha visto el mismo cambio de paso en la seguridad y todavía se basa en lo que llamamos "TLS oportunista". En TLS oportunista, los servidores primero establecerán una conexión insegura y luego intentarán negociar y actualizar la conexión a TLS, pero continuarán felizmente sin TLS si, por cualquier motivo, no pueden ponerse de acuerdo.

El problema real aquí es que "TLS oportunista" inicialmente abre una conexión insegura y la actualiza a TLS (iniciado por el método STARTTLS). Por lo tanto, es relativamente fácil interceptar dicha conexión e inhibir la actualización a TLS ocultando la compatibilidad con STARTTLS del servidor remoto. Los servidores de correo TLS oportunistas continuarán con el intercambio de correo electrónico sin cuidado ni consideración. Peor aún, ni el remitente ni los destinatarios serían remotamente conscientes de que esto ha sucedido.

Ambas partes en una conexión TLS utilizan certificados PKI que también se pueden usar para proporcionar niveles adicionales de confianza de que las partes son realmente quienes dicen ser y verificables de forma independiente a través de un ancla de confianza . Sin embargo, dado lo fácil que es obtener certificados de proveedores como LetsEncrypt, esto se vuelve menos confiable.

En la práctica, la gran mayoría de los servidores de correo electrónico admiten alguna forma de TLS, por lo que existe una probabilidad bastante alta de que su correo electrónico se haya cifrado mientras viajaba por Internet hasta su destino. Sin embargo, no aborda el riesgo de un ataque MITM que enmascare la compatibilidad con TLS y permita conexiones sin cifrar.

¿Qué pasa con MTA-STS?

• MTA-STS aborda este riesgo (y asumiendo que no está en modo de "prueba") requiriendo implícitamente que se debe establecer una conexión TLS para el intercambio de correo electrónico.

• El DANE hace cumplir el requisito implícito de una conexión TLS y, por lo tanto, mitiga este riesgo.

• TLS oportunista se basa en una conexión sin cifrar para establecer la posibilidad de una actualización a TLS y, por lo tanto, es vulnerable a un ataque MITM.
• Tanto DANE como MTA-STS requieren implícitamente una conexión TLS antes de que se intercambie el correo electrónico, por lo que son efectivos para garantizar que se establezca al menos una conexión TLS básica.
• TLS por sí solo no es suficiente para sugerir que una conexión está lo suficientemente segura/cifrada. Muchos de los protocolos y conjuntos de cifrado implementados dentro de TLS se consideran inseguros (fuerza bruta). Este es un tema completo en sí mismo que trataremos en un artículo posterior.

Podría decirse que este es un paso en el proceso de establecer una conexión segura entre los servidores de correo. Sin embargo, en mi opinión, es un elemento tan crítico que merece su propia sección.

Reconociendo la dependencia de las fases anteriores, se vuelve esencial que podamos validar aún más que el servidor al que nos estamos conectando es, de hecho, el servidor autorizado para el dominio de los destinatarios. La fase anterior describía el establecimiento de una conexión TLS que puede o no incluir Verificación de certificado. Sin embargo, en general, todo lo que hace la Verificación de certificados es validar que el nombre de host dado coincida con el nombre de host detallado en el certificado en el servidor remoto y, opcionalmente, si se puede vincular al ancla de confianza.

El DANE va un paso más allá al publicar un registro TLSA protegido por DNSSEC que contiene una huella digital (y un método de validación) para el certificado de los servidores de correo. Esto proporciona una validación definitiva y confiable que asegura categóricamente que el servidor al que se conecta presenta el certificado específico reconocido por el administrador de DNS.

¿Y el DANE?

• La validación del certificado de servidores contra un registro TLSA asegurado por DNSSEC, es inherente al DANE y proporciona el sello final de aprobación para asegurar la conexión.

• MTA-STS no va tan lejos, su propósito se centra en asegurar que una conexión TLS sea obligatoria y no se extiende a la validación de la autoridad de los servidores de correo.

En mi opinión, no existe una razón racional para que estas debilidades permanezcan sin mitigar en la mayoría de los proveedores de correo. La tecnología existe para abordarlos y es relativamente fácil de implementar en estos días. Mi suposición es que la falta de conocimiento de los consumidores elimina gran parte del incentivo para que los proveedores de correo implementen estas tecnologías.

MTA-STS proporciona algunas mejoras clave para los problemas de TLS oportunista, pero no va lo suficientemente lejos como para abordar todas las debilidades. Agregar DNSSEC a MTA-STS reduce algunos de los riesgos y sería mi recomendación (si DANE no es una opción para usted).

Sin embargo, el DANE brinda una solución integral a las debilidades discutidas en este artículo. Si está considerando tanto MTA-STS como DANE pero solo quiere elegir uno, entonces DANE sería mi recomendación.

Hay aproximadamente 365 millones de nombres de dominio registrados en todo el mundo, y solo 3,7 millones de dominios han implementado el DANE (aproximadamente el 1%).

Si observamos a los proveedores de correo más grandes, notamos que Gmail ha implementado MTA-STS pero aún no ha implementado DANE o incluso DNSSEC.

De manera similar, Microsoft implementó MTA-STS en Exchange Online este año y anunció su intención de ofrecer DANE en el futuro, pero es probable que pasen un par de años más antes de que lo admitan tanto de salida como de entrada.