← RFC Reference

Seguridad TLS y de correo electrónico

Cómo TLS protege el correo electrónico en tránsito — STARTTLS, TLS implícito, MTA-STS, DANE, TLSRPT — y por qué el cifrado oportunista no es suficiente.

El Problema: SMTP Nació Desencriptado

SMTP fue diseñado en 1982 (RFC 821) como protocolo de texto plano. Cada comando, cada respuesta, cada encabezado, cada byte del contenido del mensaje viajaba por la red sin cifrar. Las contraseñas enviadas a través de AUTH eran efectivamente gritadas en la habitación.

TLS (Seguridad de la Capa de Transporte) se superpuso a SMTP para solucionar esto. Pero a diferencia de HTTPS — donde TLS es obligatorio y universal — el TLS de correo ha evolucionado a través de una serie de compromisos imperfectos que aún se están resolviendo hoy.

STARTTLS: Cifrado Oportunista

STARTTLS (RFC 3207) actualiza una conexión SMTP de texto plano existente a TLS. El proceso:

Puntos clave sobre STARTTLS:

• La conexión comienza en texto plano y se actualiza en medio de la transmisión. Los comandos EHLO y STARTTLS iniciales en sí mismos no están cifrados.
• Después de que STARTTLS se completa, el cliente debe enviar EHLO nuevamente. El servidor puede anunciar diferentes capacidades sobre la conexión cifrada.
• STARTTLS se utiliza en puerto 25 (servidor a servidor) y puerto 587 (envío de cliente).
• STARTTLS en puerto 25 es oportunista por defecto: si el servidor no anuncia STARTTLS, o si el protocolo de enlace TLS falla, la mayoría de los MTA de envío regresan a texto plano y envían el mensaje de todas formas.

El ataque de eliminación de STARTTLS

Debido a que STARTTLS comienza en texto plano, un atacante de intermediario puede modificar la respuesta EHLO del servidor para eliminar el anuncio de STARTTLS. El MTA de envío piensa que el servidor no admite TLS y continúa en texto plano. El atacante puede entonces leer y modificar el mensaje.

Este no es un ataque teórico. Ha sido observado en la práctica, particularmente en países que realizan vigilancia masiva. El STARTTLS oportunista no proporciona protección contra atacantes activos — solo protege contra el espionaje pasivo.

TLS Implícito: Cifrado desde el Primer Byte

RFC 8314 recomienda TLS implícito para envío de correo (cliente a servidor). En lugar de comenzar en texto plano y actualizar, la conexión es TLS desde el primer byte.

• Puerto 465: TLS implícito para envío de mensajes. El cliente abre una conexión TLS inmediatamente. Sin paso STARTTLS. Sin oportunidad de eliminación.
• Puerto 993: TLS implícito para IMAP.
• Puerto 995: TLS implícito para POP3.

RFC 8314 declara explícitamente que el envío SMTP en texto plano en puerto 587 sin TLS es obsoleto, y que TLS implícito en puerto 465 es la ruta de envío preferida. En la práctica, el puerto 587 con STARTTLS sigue siendo ampliamente utilizado, pero la dirección es clara: TLS implícito es el futuro.

Sin embargo, TLS implícito solo se aplica a la ruta de envío (tu cliente a tu servidor). La entrega de servidor a servidor en puerto 25 aún utiliza STARTTLS porque no hay un mecanismo implementado universalmente para que los servidores sepan de antemano que el MX del destinatario admite TLS implícito. Aquí es donde entran en juego MTA-STS y DANE.

MTA-STS: Aplicación de TLS Basada en Políticas

MTA-STS (RFC 8461) resuelve el problema de eliminación de STARTTLS permitiendo que un dominio publique una política que dice "siempre requiere TLS al entregar correo a mis servidores MX." La política se publica a través de HTTPS (no DNS), que proporciona su propia autenticación a través de la PKI web.

Cómo funciona MTA-STS

1. El dominio publica un registro DNS TXT señalando que existe una política MTA-STS:

2. El MTA de envío obtiene la política a través de HTTPS desde una URL bien conocida:

3. El archivo de política especifica el modo y los nombres de host MX válidos:

4. El MTA de envío almacena en caché la política (durante max_age segundos) y la aplica en todas las conexiones futuras. Hará:
   • Requiere STARTTLS en puerto 25 (nunca regresa a texto plano)
   • Valida el certificado TLS del servidor contra el nombre de host MX
   • Solo entrega a los nombres de host MX listados en la política

Modos MTA-STS:

• enforce: Requiere TLS y certificados válidos. Falla la entrega si no se puede establecer TLS.
• testing: Intenta TLS pero entrega de todas formas si falla. Envía reportes de fallo a través de TLSRPT.
• none: Sin política. Se utiliza para revocar explícitamente una política anterior.

MTA-STS tiene el mismo modelo de confianza que la web: se basa en Autoridades de Certificación. Si una CA se ve comprometida, un atacante podría falsificar un certificado para tu MX. DANE proporciona un modelo de confianza alternativo basado en DNSSEC.

DANE: Verificación de Certificados Basada en DNS

DANE (RFC 7672) utiliza registros TLSA firmados con DNSSEC para asociar un certificado TLS (o su clave pública) directamente con un nombre de host MX. Esto elimina la dependencia de Autoridades de Certificación.

Los campos del registro TLSA:

• 3 (Uso de Certificado) — Certificado emitido por dominio (no se requiere CA)
• 1 (Selector) — Coincide con la clave pública del sujeto
• 1 (Tipo de Coincidencia) — Hash SHA-256 de la clave pública
• a]b2c3d4e5f6... — El valor del hash

Cómo funciona DANE para correo

1. El MTA de envío resuelve el registro MX y obtiene mx1.example.com.
2. Consulta un registro TLSA en _25._tcp.mx1.example.com.
3. Si existe un registro TLSA validado con DNSSEC, el MTA sabe:
   • TLS es obligatorio (sin regresión a texto plano).
   • El certificado del servidor debe coincidir con el registro TLSA.
4. El MTA se conecta, realiza STARTTLS, y valida el certificado del servidor contra el registro TLSA en lugar de (o además de) el sistema de CA.

La fortaleza de DANE: no depende de Autoridades de Certificación. Su debilidad: requiere DNSSEC, que muchos dominios no han implementado. Sin DNSSEC, los registros DANE no pueden ser confiables (un atacante que puede manipular DNS puede manipular registros TLSA también).

DANE vs. MTA-STS

Ambos mecanismos pueden coexistir. Un dominio puede publicar políticas tanto de MTA-STS como de DANE. Los remitentes que admiten DANE lo utilizan; los que no pueden recurrir a MTA-STS.

TLSRPT: Reporte de TLS

Reporte de TLS SMTP (RFC 8460) permite que un dominio reciba reportes sobre fallos de conexión TLS de servidores de envío. Es el equivalente de TLS de reportes agregados de DMARC.

Los MTA de envío que admiten TLSRPT enviarán reportes JSON diarios detallando:

• Total de intentos de conexión a tu MX
• Negociaciones TLS exitosas
• Negociaciones TLS fallidas (y por qué: errores de certificado, fallos de STARTTLS, violaciones de política de MTA-STS)
• Conexiones que se revirtieron a texto plano

TLSRPT es esencial durante la implementación de MTA-STS. Comienza con mode: testing en tu política MTA-STS y monitorea reportes de TLSRPT. Cuando veas cero (o fallos aceptables), muévete a mode: enforce.

Gestión de Certificados

TLS requiere certificados, y la gestión de certificados es uno de los puntos de fallo operacional más comunes en la seguridad del correo.

Certificados para servidores de correo

• El certificado debe coincidir con el nombre de host MX. Si tu registro MX apunta a mx1.example.com, el certificado debe ser válido para mx1.example.com. Un certificado para example.com o www.example.com no funcionará.
• Utiliza certificados de una CA pública. Let's Encrypt funciona perfectamente para servidores de correo. Los certificados autofirmados causarán fallos de validación de TLS para remitentes que verifican (lo que incluye a cualquiera que use MTA-STS o DANE).
• Automatiza la renovación. La expiración de certificados es el fallo de TLS más común. Utiliza ACME (Let's Encrypt) o la automatización de tu CA para garantizar que los certificados se renueven bien antes de la expiración.
• Incluye todos los nombres de host MX. Si tienes varios servidores MX, cada uno necesita un certificado válido para su nombre de host. Un certificado SAN (Nombre Alternativo del Sujeto) puede cubrir varios nombres de host.

Errores de certificado y su impacto

Esta tabla revela el problema central con TLS oportunista: sin MTA-STS o DANE, la mayoría de los errores de certificado se ignoran silenciosamente. La conexión está cifrada, pero no autenticada — podrías estar cifrando tu mensaje a un servidor de un atacante.

El Estado del Cifrado de Correo

El cifrado de correo existe en dos niveles, y a menudo se confunden:

Cifrado de transporte (TLS)

TLS cifra la conexión entre servidores. Protege contra el espionaje mientras el mensaje está en tránsito entre cualquier dos puntos. Una vez que el mensaje llega al servidor de destino, se descifra y se almacena en texto plano (típicamente). TLS protege el transporte, no el mensaje.

El cifrado de transporte es salto a salto: el mensaje está cifrado entre tu servidor y el próximo servidor, luego se descifra, luego se vuelve a cifrar para el próximo salto. Cada servidor intermedio tiene acceso al mensaje de texto plano.

Cifrado de extremo a extremo (S/MIME, PGP)

El cifrado de extremo a extremo (S/MIME por RFC 8551, o PGP/OpenPGP) cifra el contenido del mensaje en sí, para que solo el destinatario previsto con la clave privada correcta pueda descifrarlo. El mensaje permanece cifrado en reposo en el servidor y durante cada salto de tránsito.

La adopción del cifrado de extremo a extremo en correo sigue siendo extremadamente baja. Las razones son prácticas:

• La gestión de claves es difícil. Tanto remitente como destinatario deben gestionar claves criptográficas. No hay directorio de claves universal.
• La usabilidad es pobre. La mayoría de clientes de correo hacen que el cifrado sea engorroso. El usuario promedio no puede (y no debería tener que) gestionar claves PGP.
• Las características del servidor se rompen. Si el servidor no puede leer el mensaje, no puede indexarlo, buscarlo, filtrar spam o aplicar reglas.
• La interoperabilidad es limitada. S/MIME y PGP no son compatibles entre sí.

Para la mayoría del correo, TLS a nivel de transporte es la capa de cifrado práctica. El cifrado de extremo a extremo sigue siendo nicho, utilizado en entornos de alta seguridad donde la carga operacional está justificada.

Requiere TLS (RFC 8689)

RFC 8689 define un mecanismo por mensaje para requerir TLS. El remitente agrega una extensión SMTP REQUIRETLS a mensajes individuales:

Cuando se establece REQUIRETLS:

• El servidor receptor debe usar TLS para entregar o retransmitir el mensaje. Si TLS no está disponible en el siguiente salto, el mensaje se devuelve en lugar de enviarse en texto plano.
• La verificación del certificado TLS debe tener éxito.
• Todos los saltos posteriores también deben admitir y honrar REQUIRETLS.

REQUIRETLS es a nivel de mensaje — puedes usarlo para mensajes sensibles sin requerir TLS para todo el correo. Sin embargo, la adopción aún es limitada. La mayoría de servidores aún no lo admiten.

Guía Práctica de Implementación

Aquí hay una secuencia recomendada para implementar TLS para el correo de tu dominio:

Paso 1: Asegura TLS en tus servidores MX

Obtén certificados válidos de una CA pública para cada nombre de host MX. Automatiza la renovación. Prueba que STARTTLS funciona correctamente desde remitentes externos.

Paso 2: Implementa TLSRPT

Publica un registro DNS TXT _smtp._tls para recibir reportes de fallo de TLS. Comienza a monitorear antes de que hagas cumplir nada.

Paso 3: Implementa MTA-STS en modo de prueba

Publica el registro DNS TXT y el archivo de política HTTPS con mode: testing. Monitorea reportes de TLSRPT para fallos. Investiga y corrige cualquier problema.

Paso 4: Mueve MTA-STS al modo de aplicación

Una vez que los reportes de TLSRPT muestren resultados limpios, cambia el modo a enforce. Incrementa el id en el registro DNS TXT para señalar el cambio de política.

Paso 5: Considera DANE (si usas DNSSEC)

Si tu dominio está firmado con DNSSEC, publica registros TLSA para tus servidores MX. Esto proporciona una capa adicional de fijación de certificados independiente del sistema de CA.

Qué Puede Salir Mal

El certificado expirado causa fallos de entrega

El certificado de tu servidor MX expira. Sin MTA-STS, la mayoría de remitentes ignoran el error y entregan de todas formas (inseguro pero funcional). Con MTA-STS en modo de aplicación, los remitentes que validan certificados aplazarán la entrega. Los mensajes se colan en el lado del remitente. Si no lo arreglas dentro de la ventana de reintento del remitente (típicamente 4–5 días), los mensajes rebotan. La solución: automatiza la renovación de certificados con Let's Encrypt / ACME.

Desajuste de política MTA-STS después del cambio de MX

Agregas un nuevo servidor MX (mx3.example.com) pero olvidas agregarlo a tu archivo de política MTA-STS. Los remitentes que han almacenado en caché la política antigua rechazan conexiones al nuevo MX porque no está en la lista de políticas permitidas. La solución: siempre actualiza el archivo de política MTA-STS antes de agregar nuevos registros MX, e incrementa el id de política en DNS.

Eliminación de STARTTLS no detectada

Sin MTA-STS o DANE, un atacante elimina STARTTLS de la respuesta EHLO del servidor. Los mensajes se entregan en texto plano. Ni remitente ni receptor se da cuenta. La solución: implementa MTA-STS para hacer que la eliminación de TLS sea detectable y prevenible.

El registro TLSA de DANE se vuelve obsoleto

Rotas tu certificado TLS pero olvidas actualizar el registro TLSA en DNS. Los remitentes que validan DANE ven una desajuste y se niegan a entregar. La solución: siempre actualiza registros TLSA antes de implementar un nuevo certificado. Utiliza automatización que coordine la implementación de certificados con actualizaciones de DNS.

Conclusiones Clave

• El STARTTLS oportunista es mejor que nada, pero no proporciona protección contra ataques activos. Un atacante que puede modificar el tráfico de red puede eliminar TLS de la conexión.
• MTA-STS previene la eliminación de TLS publicando una política que los remitentes almacenan en caché y aplican. Se basa en la PKI web (Autoridades de Certificación).
• DANE previene la eliminación de TLS publicando datos de certificado en registros DNS firmados con DNSSEC. No depende de CA pero requiere DNSSEC.
• Implementa ambos si es posible. MTA-STS tiene apoyo de remitente más amplio; DANE es más fuerte pero requiere DNSSEC. Juntos cubren la mayor parte del terreno.
• TLSRPT es esencial para visibilidad. Sin él, no tienes idea de con qué frecuencia falla TLS para correo entrante a tu dominio.
• La gestión de certificados es una preocupación operacional. Automatiza la renovación. Haz coincidir certificados con nombres de host MX. Coordina la rotación de certificados con actualizaciones de TLSA de DANE.
• TLS protege transporte, no contenido. Para cifrado de mensaje de extremo a extremo, necesitas S/MIME o PGP — pero las barreras de usabilidad y adopción siguen siendo altas.
• TLS implícito (puerto 465) es el futuro para envío. Para entrega de servidor a servidor, STARTTLS con aplicación de MTA-STS/DANE es la práctica actual recomendada.

Lectura Adicional

Related RFCs