¿Qué son los informes SMTP TLS?
TLS Reporting es un mecanismo de retroalimentación inversa que ayuda a los propietarios de dominios a encontrar problemas de entrega de correo electrónico con una precisión milimétrica. Funciona conjuntamente con el MTA-STS y proporciona datos de seguimiento sobre los mensajes de correo electrónico devueltos que no se entregaron debido a un protocolo TLS fallido.
¿Qué significan los informes TLS?
TLS Reporting (TLS-RPT) es un estándar para informar de los problemas de entrega de correo electrónico que se producen cuando un correo electrónico no está cifrado con TLS. Es compatible con el protocolo MTA-STS que se utiliza para garantizar que cualquier correo electrónico enviado a su dominio recibe cifrado TLS.
- El cifrado TLS garantiza que todos los correos electrónicos que se le envíen se entreguen de forma segura. Sin embargo, un atacante podría intentar una degradación SMTP, un tipo de ataque en el que el correo electrónico se le envía sin cifrar, lo que le permite leer o manipular el contenido. MTA-STS combate esto haciendo necesario que todos los correos electrónicos sean encriptados antes de ser enviados a usted. Si un atacante intenta realizar una degradación SMTP, el correo electrónico no se enviará en absoluto.
- TLS-RPT hace posible que usted, el propietario del dominio, reciba informes sobre cada correo electrónico que no se encripta y no se envía. Así podrá identificar el origen del problema y solucionar los problemas de entrega.
¿Cómo funcionan los informes TLS?
La notificación TLS (TLS-RPT) se utiliza para soportar el protocolo MTA-STS, que asegura que los correos electrónicos están encriptados antes de ser entregados. Normalmente, su servidor de correo electrónico o Agente de Transferencia de Correo (MTA) negocia con el servidor receptor para ver si soporta el comando STARTTLS. Si lo hace, el correo electrónico se encripta con TLS y se entrega al MTA receptor.
Un atacante podría intentar un ataque de degradación SMTP en este punto, que consiste en bloquear la negociación entre los MTAs emisor y receptor. El servidor emisor piensa que el receptor no soporta el comando STARTTLS y envía el correo electrónico sin cifrado TLS, permitiendo al atacante ver o manipular el contenido del correo.
Cuando implementa MTA-STS en su dominio, obliga a su servidor de envío a cifrar los mensajes antes de enviarlos. Si un atacante intenta un ataque de degradación SMTP, el correo electrónico simplemente no se enviará. Esto garantiza el cifrado TLS en todos sus correos electrónicos sin falta.
El informe TLS (TLS-RPT) es un protocolo que le notificará a usted, el propietario del dominio, cuando los correos electrónicos enviados a través de su dominio tengan problemas de entrega. Si falla el envío de un correo electrónico debido a una caída de SMTP o a algún otro problema, recibirá un informe en formato de archivo JSON con los detalles del correo electrónico que falló. Este informe no contiene el contenido del correo electrónico.
¿Por qué necesita informes SMTP TLS?
Es esencial que los propietarios de dominios se mantengan informados sobre los problemas de entrega de correo electrónico debidos a fallos en el cifrado TLS de los correos electrónicos enviados desde un dominio habilitado para MTA-STS. Los informes TLS lo hacen posible proporcionando esta información.
Recibir informes de evaluación
Si falla el envío de un mensaje, los informes TLS le ayudan a recibir una notificación al respecto
Para obtener una visibilidad total de los canales de correo electrónico
Obtenga información detallada sobre su flujo de correo electrónico mediante informes TLS
Para eliminar los problemas de entrega
Los informes TLS le ayudan a identificar el origen del problema y a solucionarlo sin demora.
Pasos para activar los informes TLS
Puede activar los informes TLS para su dominio creando un registro TXT para TLS-RPT y publicándolo en su DNS. Este registro debe publicarse en el subdominio _smtp._tls.sudominio.com
Ejemplo de registro TLS-RPT
v=TLSRPTv1; rua=mailto:[email protected];
Desglosemos los componentes del registro de informes TLS proporcionado:
v=TLSRPTv1:
Esta etiqueta especifica la versión del protocolo TLS-RPT que se está utilizando. En este caso "TLSRPTv1 indica la primera versión del protocolo TLS-RPT.
rua=mailto:[email protected]:
Esta etiqueta indica el URI de notificación para los informes agregados (RUAs). Especifica dónde debe enviar el servidor de correo del destinatario los informes agregados sobre fallos TLS. rua son las siglas de "Reporting URI for Aggregated Reports".
El valor "mailto:[email protected]" es un URI que especifica una dirección de correo electrónico ([email protected]) a la que deben enviarse por correo electrónico los informes agregados.
En la práctica, sustituiría "sudominio.com" por el nombre real del dominio en el que desea recibir estos informes.
La importancia de cada componente:
v=TLSRPTv1:
Indica la versión del protocolo TLS-RPT que se está utilizando. Ayuda a garantizar la compatibilidad entre el emisor y el receptor de los informes.
rua=mailto:[email protected]:
Especifica el destino de los informes agregados sobre problemas de entrega TLS. Al proporcionar una dirección de correo electrónico de informes, los propietarios de dominio pueden recibir información sobre conexiones TLS fallidas o problemáticas. Los informes son valiosos para diagnosticar posibles problemas de seguridad o configuración relacionados con la comunicación por correo electrónico.
Formato de informe TLS y ejemplo de informe
Un informe TLS JSON sigue un formato específico definido por la especificación TLS-RPT (Transport Layer Security Reporting Policy). Este formato se utiliza para transmitir información sobre problemas de entrega de correo electrónico relacionados con el cifrado TLS. A continuación se muestra un ejemplo del aspecto que podría tener un informe TLS JSON:
He aquí el desglose de los principales campos de este informe JSON TLS:
organización: Organización del dominio propietaria del registro TLS-RPT.
correo electrónico: Dirección de correo electrónico a la que se envían los informes agregados.
fecha_inicio: Fecha de inicio del período de información.
fecha_final: La fecha final del período de información.
políticas: Una matriz de objetos de política que describen las políticas aplicadas durante el periodo de notificación.
política: Contiene información sobre la política aplicada.
tipo_política: Especifica el tipo de política (por ejemplo, "policy" para una política TLS).
cadena_política: Especifica la cadena de política asociada a la política (por ejemplo, "reject" para una política TLS estricta).
resumen: Contiene información resumida sobre las sesiones que se han intentado.
total_session_count: El recuento total de sesiones TLS establecidas con éxito.
total_failure_session_count: El recuento total de fallos de sesión TLS.
detalles_del_fallo: Una matriz de objetos que proporcionan detalles sobre fallos específicos.
razón: Cadena que indica el motivo del fallo (por ejemplo, "certificado_vencido").
contar: El recuento de sesiones que fallaron por una razón específica.
Razones y tipos de fallos de cifrado TLS
Cuestiones relativas a los certificados:
- certificado_vencido: El certificado presentado por el servidor remoto ha superado su fecha de caducidad, por lo que no es de confianza para el cifrado.
- certificado_no_válido_aún: El certificado presentado por el servidor remoto aún no es válido, posiblemente debido a una hora incorrecta del servidor o a un uso prematuro del certificado.
- certificado_revocado: El certificado presentado por el servidor remoto ha sido revocado por la autoridad de certificación por motivos de seguridad.
- certificado_no_confiable: La cadena de certificados presentada por el servidor remoto no es de confianza para el servidor o cliente de correo del remitente, lo que indica un riesgo potencial para la seguridad.
- no_valid_signature: El certificado presentado por el servidor remoto no está firmado correctamente por una autoridad de certificación de confianza, lo que plantea dudas sobre su autenticidad.
- certificado_no_soportado: El certificado presentado por el servidor remoto utiliza algoritmos de cifrado o longitudes de clave no compatibles con el servidor de correo del remitente, lo que impide una conexión segura.
No coincidencia de nombre de host e identidad
- nombre_de_host: El nombre de host especificado en el certificado del servidor no coincide con el nombre de host del servidor al que intenta conectarse el servidor de correo del remitente, lo que indica un posible ataque de intermediario o un problema de configuración.
Suite de cifrado y configuración de cifrado
- insecure_cipher_suite: El conjunto de cifrado negociado entre los servidores de correo del remitente y del destinatario se considera débil o inseguro, lo que puede comprometer la confidencialidad e integridad de la comunicación.
- protocolo_version_mismatch: Existe un desajuste en las versiones de protocolo TLS soportadas entre los servidores de correo del remitente y del destinatario, lo que les impide establecer una conexión cifrada compatible.
- no_shared_cipher_suite: No hay un conjunto de cifrado común disponible para que los servidores de correo del remitente y del destinatario lo utilicen para el cifrado, lo que provoca una conexión fallida.
Cuestiones de protocolo y apretón de manos
- handshake_failure: Se ha producido un problema durante el proceso inicial de enlace TLS entre el servidor de correo del remitente y el servidor de correo del destinatario, lo que ha impedido que se establezca el canal seguro.
- mensaje_inesperado: El servidor de correo del remitente recibió un mensaje inesperado o no compatible durante el proceso de enlace TLS, lo que indica un posible desajuste de protocolo o implementación.
Cuestiones políticas de la MTA-STS
- mta_sts_policy_not_found: Este fallo se produce cuando el servidor de correo del remitente no puede encontrar una política MTA-STS para el dominio del destinatario.
- mta_sts_policy_invalid: Este fallo se produce cuando la política MTA-STS encontrada en DNS para el dominio del destinatario no es válida, contiene errores o no se adhiere a la especificación MTA-STS.
- mta_sts_policy_fetch_error: Este fallo se produce cuando el servidor de correo del remitente encuentra un error al intentar recuperar la política MTA-STS de los registros DNS del dominio del destinatario.
- mta_sts_connection_failure: Este fallo se produce cuando el servidor de correo del remitente intenta establecer una conexión segura utilizando MTA-STS pero falla debido a razones como certificados no fiables, suites de cifrado no compatibles u otros problemas de TLS.
- mta_sts_invalid_hostname: Este fallo se produce cuando el nombre de host del servidor de correo del destinatario, especificado en la política MTA-STS, no coincide con el nombre de host real del servidor.
- mta_sts_policy_upgrade: Este fallo se produce cuando el servidor de correo del remitente intenta actualizar la conexión a una segura mediante MTA-STS, pero el servidor del destinatario no admite la actualización.
Informes SMTP TLS simplificados con PowerDMARC
La experiencia de informes SMTP TLS de PowerDMARC consiste en mejorar su seguridad al tiempo que le facilita la vida con un servicio alojado.
Informes TLS traducidos
Los complejos informes JSON para informes TLS se convierten en información simplificada que puede hojear en segundos o leer en detalle
Problemas de autodetección
La plataforma PowerDMARC localiza automáticamente el problema al que se enfrenta para que pueda resolverlo sin perder tiempo
- Seguridad Web 101 - Mejores Prácticas y Soluciones - 29 de noviembre de 2023
- ¿Qué es el cifrado de correo electrónico y cuáles son sus diversos tipos? - noviembre 29, 2023
- DMARC Black Friday: Fortalezca sus correos electrónicos estas fiestas - 23 de noviembre de 2023
