Entrega cifrada: TLS, MTA-STS y DANE
Módulo 5: Reputación y los grandes proveedores · Tiempo de lectura: 10 minutos
Objetivo de aprendizaje: Después de esta lección podrá explicar cómo se cifran las comunicaciones entre servidores de correo, por qué eso no es exigible por defecto, y qué cambian en eso MTA-STS, TLS-RPT y DANE. Podrá buscar y leer los registros correspondientes.
Conceptos clave: STARTTLS entre servidores, cifrado oportunista, ataque de downgrade, MTA-STS (RFC 8461), registro _mta-sts, archivo de política, modo testing/enforce/none, TLS-RPT (RFC 8460), registro _smtp._tls, DANE para SMTP (RFC 7672), registro TLSA, DNSSEC
Dos tipos de conexiones
En la lección 1.4 se habló de la conexión entre su programa de correo y el servidor de correo de su proveedor: puerto 587 con STARTTLS, o 465 con TLS directo, con inicio de sesión. Ahí usted mismo tiene el control. Su programa sabe qué servidor espera, comprueba el certificado y se niega a conectar si algo no cuadra.
Esta lección trata del siguiente paso: la conexión entre el servidor emisor y el servidor receptor, por el puerto 25. Esa funciona de otra manera.
Oportunista: cifrar cuando es posible
Cuando un servidor entrega correo, se conecta con el MX del destinatario. Después de EHLO, comprueba si el servidor receptor ofrece STARTTLS. Si es así, pasa a una conexión cifrada. Si no, entrega el correo sin cifrar, sin más.
Esto se llama cifrado oportunista: se cifra si es posible, y si no, no. Y, por lo general, el servidor emisor no comprueba el certificado de forma estricta. Un certificado caducado o autofirmado no es motivo para detenerse.
¿Por qué así? Porque el correo siempre debe seguir funcionando, incluso con servidores antiguos. Un emisor no puede saber si un receptor debería tener TLS. Esto hace posibles dos ataques:
- Downgrade. Alguien que puede modificar el tráfico en tránsito elimina la palabra
STARTTLSde la respuesta del receptor. El emisor cree que no hay cifrado y entrega sin cifrar. El atacante lee el mensaje. - MX falso. Alguien que puede falsificar respuestas DNS indica su propio servidor como MX. Como no se comprueba el certificado, el emisor no nota nada.
Hoy en día, casi todos los grandes servidores de correo cifran, y Gmail exige a los remitentes que usen TLS (lección 5.3). Pero "normalmente cifrado" es distinto de "siempre y con el servidor correcto". Para eso existen dos soluciones: MTA-STS y DANE. Ambas las configura el receptor: con ellas indica que el correo dirigido a su dominio siempre debe ir cifrado, hacia un servidor con un certificado válido.
MTA-STS: política mediante una página web
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) funciona con dos componentes.
Un registro TXT que indica que existe una política:
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20261108T120000;"Y un archivo de política en una ubicación fija, mediante https con un certificado válido:
https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800| Línea | Significado |
|---|---|
mode: enforce | Entregar únicamente mediante TLS con un certificado válido en uno de los servidores MX indicados. Si no es posible, no se entrega (queda en la cola) |
mode: testing | Entregar como siempre, pero notificar los problemas mediante TLS-RPT |
mode: none | No hay política (ya) |
mx: | Los nombres de los servidores MX que deben llevar el certificado; se admite un *. al principio |
max_age: | Durante cuánto tiempo (en segundos) un emisor puede recordar la política |
id= en el registro TXT | Un número de versión. Si modifica la política, cambie también el id, para que los emisores vuelvan a descargar el archivo |
Lo inteligente: un emisor recuerda la política durante el tiempo indicado por max_age. Un atacante que más tarde elimine la palabra STARTTLS o indique un MX falso queda entonces al descubierto: la política dice que el cifrado es obligatorio y qué servidores son válidos. En la primerísima conexión (antes de que se conozca la política), MTA-STS no protege; ese es el punto débil conocido.
Un ejemplo real es gmail.com: el registro TXT _mta-sts.gmail.com existe, y el archivo de política en https://mta-sts.gmail.com/.well-known/mta-sts.txt está en mode: enforce.
TLS-RPT: informes sobre cifrado fallido
Con MTA-STS en enforce, el correo puede quedar atascado si algo falla con su certificado. Usted querrá saberlo. Para eso está TLS-RPT (RFC 8460):
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"Los emisores que admiten TLS-RPT (entre otros, Google y Microsoft) envían entonces diariamente un informe en formato JSON: cuántas conexiones tuvieron éxito y cuáles fallaron, con el motivo (por ejemplo, un certificado caducado o un nombre que no figura en la política). Igual que con los informes DMARC (lección 4.5), puede hacer que un servicio de informes los procese por usted.
Orden de implementación: primero TLS-RPT, después MTA-STS en testing, unas semanas leyendo informes, y solo después enforce. Se parece a la línea de recomendación de DMARC: primero observar, después ser estricto.
DANE: el certificado en el DNS, protegido con DNSSEC
DANE (DNS-based Authentication of Named Entities) lo aborda de otra manera. Usted coloca en el DNS un registro TLSA para cada servidor MX, con una huella digital del certificado o de la clave:
_25._tcp.mx1.example.com. 3600 IN TLSA 3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5_25._tcp significa: para SMTP por el puerto 25. Los tres números indican cómo debe leerse el valor. Para servidores de correo, 3 1 1 es lo más habitual: "esta es la huella digital SHA-256 de la clave pública de exactamente este servidor". También aparece 2 1 1: en ese caso contiene la huella digital de un certificado intermedio.
Un emisor que admite DANE ve el registro TLSA, exige cifrado y comprueba si el certificado del servidor coincide. Si no coincide, no entrega el mensaje.
¿Por qué es DANE seguro frente a respuestas DNS falsificadas? Porque solo funciona con DNSSEC (curso de DNS, lección 8.1). Sin una cadena DNSSEC válida, los registros TLSA se ignoran. Ese es precisamente el obstáculo: tanto su dominio (para el MX) como la zona del servidor de correo deben estar firmados.
DANE no tiene la debilidad de "primera vez" que tiene MTA-STS, y se usa mucho en los Países Bajos y en Alemania. internet.nl lo comprueba en sus pruebas. Microsoft admite DANE para correo entrante en Exchange Online. Los propios servidores MX de internet.nl también tienen registros TLSA.
Trampa habitual: si sustituye el certificado de un servidor de correo con DANE por una clave nueva, el registro TLSA debe cambiar a la vez, y con antelación: primero añadir el nuevo registro, esperar a que expire el TTL, y solo entonces poner en uso la nueva clave. De lo contrario, los emisores que usan DANE rechazarán su correo. Con 3 1 1 esto solo importa si cambia la clave, no en cada renovación con la misma clave.
¿MTA-STS o DANE?
| MTA-STS | DANE | |
|---|---|---|
| Necesita DNSSEC | No | Sí |
| Dónde se encuentra | Registro TXT más archivo de política en un sitio web | Registro TLSA por servidor MX |
| Protege la primera conexión | No | Sí |
| Mantenimiento | Mantener el sitio web y el certificado de mta-sts. | Actualizar TLSA al cambiar de clave |
Puede usarlos conjuntamente. La RFC 8461 indica que un emisor que admite DANE le da prioridad sobre MTA-STS si existen registros TLSA válidos.
¿Quién se encarga de esto?
Esto se configura para el correo entrante de su dominio. Si su correo funciona en una empresa de hosting o un servicio de correo, depende de ese proveedor:
- DANE solo es posible si el proveedor publica registros TLSA para sus servidores de correo y su dominio tiene DNSSEC. En WebOké, por ejemplo, puede activar DANE en el mismo lugar que DNSSEC (consulte el artículo de internet.nl más abajo); en otros proveedores funciona de forma parecida o ya viene configurado por defecto.
- MTA-STS a veces puede configurarlo usted mismo, pero entonces
mta-sts.example.comdebe ser un sitio web con un certificado válido y usted debe conocer los nombres MX de su proveedor. - TLS-RPT siempre puede configurarlo usted mismo: es solo un registro TXT con una dirección de informes.
Para su correo saliente no tiene que hacer nada: el servidor de su proveedor decide si respeta el MTA-STS y el DANE de los destinatarios.
Resumen
- Entre servidores de correo, TLS es por defecto oportunista: cifrado si es posible, sin comprobación estricta del certificado. Eso hace posibles el downgrade y el MX falso.
- MTA-STS: TXT
_mta-stsmás archivo de política enhttps://mta-sts.<dominio>/.well-known/mta-sts.txt; modotestingoenforce. - TLS-RPT: TXT
_smtp._tlscon una dirección de informes, para informes diarios sobre cifrado fallido. - DANE: registro TLSA en
_25._tcp.<servidor-mx>, solo funciona con DNSSEC y protege también la primera conexión. - Impleméntelo como DMARC: primero informes (TLS-RPT,
testing), después estricto.
Cuestionario
Ejercicio
Ejercicio Z5.4: Buscar MTA-STS, TLS-RPT y DANE. Busque en gmail.com el registro MTA-STS y el registro TLS-RPT, abra el archivo de política y anote el modo (enforce, testing o none). Después, busque en un servidor MX de internet.nl el registro TLSA en _25._tcp.<servidor-mx> y anote los tres primeros números de uno de los registros. Opcional: las mismas preguntas para su propio dominio (ahí la respuesta puede ser "ninguno"). El programa consulta todo en tiempo real y lo compara.
Para seguir leyendo
Los pasos de estos artículos corresponden a los paneles de WebOké; en otros proveedores funciona de forma parecida.
- Lista de comprobación de Internet.nl
- ¿Qué es DNSSEC?
- Curso gratuito de DNS 8.1: DNSSEC en lenguaje sencillo
- internet.nl, compruebe su correo electrónico (prueba independiente de STARTTLS, DANE y más): https://internet.nl/
- RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE para SMTP)