Dado que las organizaciones dependen cada vez más del correo electrónico como principal medio de comunicación, no se puede exagerar la importancia de fortificar estos canales frente a posibles amenazas. La seguridad de la capa de transporte (TLS) es la piedra angular para garantizar la confidencialidad e integridad de los datos transmitidos a través de las redes.
Varios protocolos ayudan a cifrar los canales de mensajes SMTP para impedir que los ciberatacantes intercepten las comunicaciones por correo electrónico. Entre ellos se encuentran STARTTLS, DANE y MTA-STS. Sin embargo, cuando fallan los intentos de cifrado al utilizar estos protocolos, es posible que no se entregue el correo electrónico. TLS-RPT (descrito en RFC 8460) proporciona un mecanismo de retroalimentación para informar sobre estos fallos de entrega.
Recomendamos encarecidamente el uso de TLS-RPT junto con la solución MTA-STS . Veamos cómo funcionan conjuntamente estos protocolos para reforzar la seguridad del correo electrónico.
¿Qué es TLS-RPT?
TLS-RPT son las siglas de Transport Layer Security Reporting. Es un estándar para informar de los problemas de entrega de correo electrónico que se producen cuando un mensaje no está cifrado con TLS. Su importancia en la autenticación del correo electrónico va de la mano con la razón de activar el cifrado TLS para los correos electrónicos.
El cifrado TLS garantiza que todos los correos electrónicos enviados se entreguen de forma segura. En caso de que la conexión no sea segura, muchas veces los correos electrónicos pueden no entregarse. TLS-RPT permite a los propietarios de dominios controlar la entrega de correos electrónicos y los fallos de conexión. Los informes pueden contener información sobre:
- Problemas de gestión de la política MTA-STS
- Motivo y tipo de fallo en la entrega
- Dirección IP de los agentes de transferencia de correo electrónico remitentes y receptores
- Recuento total de sesiones de conexión TLS exitosas y fallidas
Esto proporciona visibilidad sobre sus canales de correo electrónico y la capacidad de contrarrestar más rápidamente los problemas de entregabilidad.
¿Cómo funcionan los informes TLS?
En la comunicación por correo electrónico SMTP, el cifrado TLS es "oportunista". Esto significa que si no se puede negociar un canal cifrado, el correo electrónico se sigue enviando en formato no cifrado (texto sin formato). De hecho, hace casi 4 décadas, los protocolos de correo electrónico SMTP no soportaban el cifrado TLS. Hubo que adaptarlo más tarde en forma del comando STARTTLS.
El comando STARTTLS sólo se emite en comunicaciones SMTP, si ambas partes soportan encriptación TLS. De lo contrario, el correo electrónico seguirá enviándose en texto plano.
Para deshacerse del cifrado oportunista en SMTP, se introdujo MTA-STS (RFC 8461). El protocolo MTA-STS garantiza que los correos electrónicos se cifran antes de ser entregados. 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. De lo contrario, la entrega falla.
Puede haber varias razones para los fallos de encriptación TLS. Aparte de la falta de soporte para el cifrado en ambos lados, razones más siniestras como un ataque de degradación SMTP pueden llevar al fallo de la conexión TLS. Con MTA-STS activado, los atacantes no pueden entregar mensajes en texto plano cuando falla una conexión.
Pero los propietarios de dominios querrían saber sobre la entrega fallida. TLS reporting (TLS-RPT) es un protocolo que le notificará. En caso de fallo en la entrega, recibirá un informe TLS en formato de archivo JSON en la dirección de correo electrónico definida en su registro TLS-RPT.
¿Por qué necesita informes SMTP TLS?
Los propietarios de dominios deben mantenerse informados sobre el correo electrónico d
os problemas de entrega 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. TLS-RPT
- Para recibir informes que destaquen su tipo de póliza y
- Para identificar el motivo de los fallos de cifrado TLS
- Para ganar visibilidad en los canales de correo electrónico
- Para solucionar los problemas de entrega
Pasos para configurar TLS-RPT
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
Paso 1: Seleccionar una herramienta generadora de registros TLS-RPT
Puede inscribirse en PowerDMARC de forma gratuita y utilizar nuestro generador de registros TLS-RPT para crear su registro.
Paso 2: Introduzca su dirección de correo electrónico de notificación
Introduzca una dirección de correo electrónico en la que desee recibir sus informes SMTP TLS.
Paso 3: Publicar el registro TLS en su DNS
Puede ponerse en contacto con su registrador de dominios para crear un nuevo registro TXT para TLS-RPT. Si gestiona su propio DNS, edite su configuración DNS para incluir el registro.
Ejemplo de registro TLS-RPT
Sintaxis: v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com;
Desglosemos los 2 componentes del registro de información 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.
- rua=mailto:tlsrpt@yourdomain.com: rua significa "Reporting URI(s) for Aggregate Data. Esta etiqueta especifica dónde debe enviar el servidor de correo del destinatario los informes TLS agregados.
Puede configurar más de un destino para recibir sus informes. Para varios destinos, separe cada entrada con una coma (,). Puede utilizar "maito:" para especificar una dirección de correo electrónico para este paso, o bien indicar al MTA que envíe los informes mediante POST a URL de punto final utilizando "https:" en el campo rua=. Si utiliza "https:" asegúrese de que el campo define la URL a un servidor web habilitado para HTTPS con un certificado válido. Tanto "mailto:" como "https:" también pueden utilizarse en un único registro, separados por una coma.
Ejemplo: v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://tlsreport.example.com;
Nota: En la práctica, deberá sustituir "sudominio.com" por el nombre real del dominio en el que desea recibir estos informes.
Formato de los informes TLS
Los informes TLS se envían en formato JSON. A continuación se muestra un ejemplo de cómo podría ser un informe TLS JSON:
{
"nombre-organización": "Organización Inc.",
“date-range”: {
"start-datetime": “2020-10-22T00:00:00Z”,
"end-datetime": “2020-10-22T23:59:59Z”
},
"información de contacto": "smtp-tls-reporting@organization.com",
"report-id": “2020-10-22T00:00:00Z_domain.com”,
"políticas": [
{
“policy”: {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: testing",
"mx: mx.dominio.com",
"mx: mx2.dominio.com",
"mx: mx3.dominio.com",
"max_age: 604800"
],
"política-dominio": "dominio.es"
},
“summary”: {
"total-successful-session-count": 15,
"total-failure-session-count": 0
}
He aquí el desglose de los principales campos de este informe JSON TLS:
| Campos | Descripción |
| organización | La organización de 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 | Fecha de finalización del período de información. |
| políticas | Una matriz de objetos de política que describen las políticas aplicadas durante el periodo del informe. |
| política | Contiene información sobre la política aplicada. |
| tipo_política | Especifica el tipo de política |
| cadena_política | Especifica la cadena de política asociada a la política |
| modo | Especifica el modo de la política MTA-STS (Enforce/Testing) |
| resumen | Contiene información resumida sobre las sesiones que se han intentado. |
| recuento_sesiones_exitosas | Recuento total de sesiones TLS establecidas correctamente. |
| 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. |
| motivo | Cadena que indica el motivo del fallo (por ejemplo, "certificado_vencido"). |
| cuente | 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
| Tipos de fallos | Razones | Posibles sugerencias para solucionar problemas |
| certificado_vencido | El certificado presentado por el servidor remoto ha superado su fecha de caducidad. Esto hace que no sea de confianza para el cifrado. | Renueve su certificado. |
| certificado_no_válido_aún | El certificado presentado por el servidor remoto aún no es válido. Esto puede deberse a una hora incorrecta del servidor o a un uso prematuro del certificado. | Póngase en contacto con su proveedor de certificados. |
| certificado_revocado | El certificado presentado por el servidor remoto ha sido revocado por la autoridad de certificación debido a problemas de seguridad. | Póngase en contacto con su proveedor de certificados. |
| no_valid_signature | 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. | Póngase en contacto con su proveedor de certificados. |
| 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. | Póngase en contacto con su proveedor de certificados. |
No coincidencia de nombre de host e identidad
| Tipo de fallo | Razón | Posibles sugerencias para solucionar problemas |
| nombre_de_anfitrión_incorrecto | 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. Indica un posible ataque de intermediario o un problema de configuración. | Compruebe los registros MX de su archivo de políticas MTA-STS para asegurarse de que coinciden con el registro MX del dominio. |
Cuestiones de protocolo y apretón de manos
| Tipos de fallos | Razones | Posibles sugerencias para solucionar problemas |
| fallo_apretón_de_manos | Se produjo 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 impidió que se estableciera el canal seguro. | Compruebe si se ha establecido la conexión SMTP STARTTLS. Puede haber varias razones que contribuyan a los fallos de cifrado como la falta de soporte para STARTTLS, o un ataque de downgrade TLS. |
Cuestiones políticas de la MTA-STS
| Tipos de fallos | Razones | Posibles sugerencias para solucionar problemas |
| 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. | Revise su archivo de políticas MTA-STS.
Compruebe su registro MTA-STS para asegurarse de que se ha publicado correctamente. |
| 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. | Revise su archivo de políticas MTA-STS.
Especifique un modo de política MTA-STS apropiado. Puede ser Ninguno, Aplicar o Probando. Esto indica a los servidores de envío cómo gestionar los correos electrónicos que sufren fallos de validación de la política MTA-STS. Más información sobre los modos de política aquí. |
| 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. | Valide los registros MTA-STS en su DNS para asegurarse de que la sintaxis del registro es correcta. |
| 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. | Compruebe la validez de su certificado, asegúrese de que el certificado está actualizado con el último estándar 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. | Compruebe los registros MX de su archivo de políticas MTA-STS para asegurarse de que coinciden con el registro MX del dominio. |
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
Sus complejos informes TLS-RPT JSON se convierten en información simplificada que puede hojear en segundos o leer en detalle.
Problemas de autodetección
La plataforma PowerDMARC señala y destaca el problema al que se enfrenta para que pueda resolverlo sin perder tiempo.
¡No hay una sola cosa que me guste de la plataforma PowerDMARC, tienen un diseño fácil de usar y entender con lo que yo llamaría funciones completas que permiten el control DMARC alojado, SPF flattening, ser capaz de ampliar fácilmente el SPF incluye para inspeccionar los detalles del registro e incluso soporte completo para MTA-STS y TLS-RPT!
Dylan B (Empresario)
Preguntas frecuentes sobre la seguridad de la capa de transporte
1. ¿Qué significa TLS?
TLS son las siglas de Transport Layer Security.
2. ¿Quién emite los certificados TLS?
Las Autoridades de Certificación (CA) pueden emitir certificados TLS. El proceso de emisión del certificado incluye la verificación de la identidad del titular del certificado. Una vez identificados, se emite el certificado.
3. ¿Por qué necesito un certificado TLS?
Los certificados TLS desempeñan un papel fundamental en la seguridad de las comunicaciones a través de Internet. Ayudan a cifrar la información confidencial que se intercambia entre servidores web en comunicación. Algunos de sus usos más comunes son la seguridad de las comunicaciones por correo electrónico y HTTPS.
4. ¿Cuál es el estándar TLS actual?
TLS 1.3 es la última versión de Transport Layer Security. TLS-RPT puede implementarse utilizando cualquier versión de TLS. Esto puede incluir versiones anteriores del protocolo o versiones futuras. La versión suele venir determinada por criterios como las capacidades de los servidores que se comunican.
Recursos adicionales
- SPF Softfail Vs Hardfail: ¿Cuál es la diferencia? - 26 de abril de 2024
- La FTC informa de que el correo electrónico es un medio popular para las estafas de suplantación de identidad - 16 de abril de 2024
- SubdoMailing y el auge del phishing de subdominios - 18 de marzo de 2024