SMTP es un protocolo de comunicación para la transmisión de correos electrónicos que sirve para generar reportes TLS. Es un mecanismo diseñado para detectar problemas potenciales de configuración. Vamos a analizar paso a paso lo que es SMTP (Simple Mail Protocol según sus siglas en inglés) mientras describimos cómo funciona y cómo asiste en la generación de reportes TLS.
El objetivo principal de los protocolos de transferencia de correo simple (SMTP) es la transferencia de correos de forma confiable y eficiente.
Agente de transferencia de correo (MTA en inglés)
- Recepción de correos de clientes MUA
- Uso de SMTP para ofrecer una ruta de envío al flujo de correo entre servidores
- Pasa correos electrónicos a través del MDA para su envío final
[Nota Importante] ¡Para que dos servidores de correos tengan la capacidad de comunicarse, ambos deben correr los mismos protocolos SMTP y MTA para que el intercambio se lleve a cabo entre los dos servidores sin problemas!
SMTP También se usa para el reenvío de correos, mientras que el sistema POP se encarga de tu flujo regular de envíos.
[/Fin de Nota Importante]
Agente para el envío de correos (MDA)
El MDA (mail delivery agent según sus siglas en inglés) recibe los mensajes de parte de MUA o del sistema MTA para clasificar el envío al buzón de mensaje de tus destinatarios. Cualquier programa qué se encargue del envío de mensajes hasta el punto donde solamente puede ser leído por un cliente, es considerado una gente para el envío de correos (MDA), por esta razón algunos sistemas MTA (tales como Sendmail y Postfix) pueden ocupar el rol de un MDA al recibir nuevos mensajes de un usuario local.
Canales encriptados de SMTP
El protocolo SMTP original, únicamente respalda correos no autenticados y sin encriptación. Estos son altamente vulnerables a intermediarios qué pudiesen atacar al destinatario, cambiando su identidad, o usando estas vías de acceso para el envío de spam. Este problema puede prevenirse encriptando datos de origen binario antes de ser transmitida.
Existen una amplia cantidad de protocolos para encriptar canales de comunicación entre los agentes SMTP y los Agentes de Transferencia de Correo (MTAs), entre estos podemos incluir
- STARTTLS
STARTTLS es un protocolo de comandos que puede ser generado por un cliente de correo, el cual indica que este como usuario quiere actualizar la conexión que posee y considera insegura, a una conexión segura usando el encriptado SSL/TTL. Los comandos STARTTLS son emanados de los protocolos SMTP e IMAP, mientras que los protocolos POP3 usan STLS cómo el nombre de comando.
- Autenticación de Nombres y Entidades Basados en el DNS (DANE) TLSA
La autenticación de nombres y entidades basados en el DNS, también se conoce Cómo DANE (o DNS-Based Authentication of Named Entities por sus siglas en inglés) este sistema te permite asegurar de forma precisa el tipo de certificado TLS/SSL que debe aplicarse o qué servicio debe usarse para conectarse a tu dominio.
- Transporte de Seguridad Estricta (MTA – STS)
SMTP También posee un sistema de transporte de seguridad estricta (MTA – STS). Este mecanismo les permite a los proveedores de servicios de correo (ISP) declarar su habilidad para recibir el sistema de transporte seguro por fases (TLS o Transport Layer Security por sus siglas en inglés). También asegura las conexiones SMTP, y específica si los servidores SMTP deben rehusarse para enviar mensajes por parte de huéspedes MX qué no que no contienen TLS con un certificado de confianza por parte de su servidor.
Estos protocolos pueden fallar debido a problemas con su configuración o por ataques activos, lo cual conlleva a un flujo de mensajes qué no llegan a sus destinatarios a través de los canales encriptados apropiados. Los dueños de dominios pueden utilizar SMTP TLS para reportar información detectada acerca de ataques potenciales o diagnósticos no intencionales relacionados a configuraciones erróneas.
Los reportes SMTP TLS definen el mecanismo qué cubre las fallas en las rutas de envío, también determina la resolución del DNS y procesa la negociación de la política STARTTLS para la validación de errores por parte de los sistemas DANE y MTA-STS. Un registro estándar .TXT puede ser utilizado para indicar a dónde deben enviarse los reportes generados y en qué formato deben llegar. El reporte también puede ser utilizado para medir el pulso del sistema y apreciar cuáles procesos de negociación en el TLS están funcionando de manera exitosa.
Las políticas MTA-STS son un mecanismo por medio del cual los administradores de sistemas o dueños de dominio pueden especificar la disponibilidad de sus TLS, también pueden presentar su identidad, y especificar las acciones que deben tomarse con una dirección de correo determinada.
Políticas de reporte SMTP TLS
Cuando un dominio pública su registro en su DNS indicando que desea recibir reportes, las políticas SMTP TLSRPT son distribuidas a través del DNS desde la zona de políticas del dominio cómo registros en formato .TXT, tal como las políticas DMARC lo hacen bajo el comando “_smtp._tls“.
Por ejemplo, para la política del dominio “easydmarc.com”, El receptor de la política TLSRPT puede ser chequeada de un espacio que debe lucir de una forma similar a esta: “_smtp._tls.easydmarc.com“.
“v=TLSRPTv1; rua=mailto:[email protected]”
- “v”: Versión de TLSRPT, para el cual el valor debe ser igual a “TLSRPTv1”.
- “rua”: una URI qué específica el punto final hasta el cual deberá agregarse información acerca de la política de validación y los resultados que deben enviarse.
Nota: en el caso del comando ”mailto” los reportes deben ser enviados a las direcciones de correo especificadas. Cuándo se envían reportes de fallas a través del SMTP, el envío de MTAs debe enviar sus reportes de igual forma Incluso si existen fallas relacionadas al TLS y estos no deberían incluir la sesión SMTP en la que se generó el error en tu próxima sesión. Esto implica que los reportes están siendo enviados sin ninguna clase de encriptación. Los reportes que se envían a través del SMTP siempre deben contener claves válidas para la identificación del dominio (políticas DKIM), ya que estás actúan como firmas por parte del dominio que genera el reporte. Los reportes que no tengan está firma digital deben ser ignorados por el destinatario. Las firmas digitales DKIM nunca deben usar el atributo “l=” ya que esto limita la extensión de la firma digital. Este proceso permite asegurarse que ninguna clase de atacante pueda anexar archivos peligrosos o información para falsear el reporte sin afectar la firma. El registro DKIM .TXT siempre debe contener el tipo de declaración de servicio a través de la etiqueta “s=tlsrpt”. Sí está no está presente, el sistema que recibe el mensaje puede ignorar los reportes ya que no tiene forma de verificarlos.
Esquema de reportes SMTP TLS
Este reporte está compuesto de un archivo en texto simple qué está codificado en el formato JSON (I-JSON), el cual únicamente es visible en la internet.
Los reportes por agregaduría deben contener los siguientes campos:
Reportes de metadatos:
- Organización responsable por el reporte
- Información de contacto para uno o más responsables de los contenidos del reporte
- Un identificador único para el reporte
- Rango de fecha del reporte generado
Diversas políticas que consistan en:
- Uno de estos tipos de política
- La aplicación de la política MTA-STS (Cómo hilo de conexión)
- El registro de aplicación DANE TLSA (Cómo hilo de cola de conexión, con cada una de las entradas RR de los sets RR listados y separados haciendo uso de un punto y coma)
- El hilo de Unión literal quién indica la ausencia de una política, si no se consiguen las políticas DANE o MTA-STS en uso
- El dominio para el cual la política está siendo aplicada
- El hospedaje MX
- Las cuentas de agregaduría, indicando todos los tipos contenidos en estas, incluso las que envían MTA IPs y reciben el nombre de los hosts MTA, así como también el número de sesión, y cualquier información opcional y adicional que esté contenida en los URI para los destinatarios que necesite ser revisada para compilar mayor información sobre el tipo de fallo.
Contenido del reporte
Conteos exitosos
“Total-successful-session-count”: Este campo contiene todos los conteos agregados de conexiones exitosas al sistema de reportes.
Conteos fallos
“Total-failure-session-count”: Este campo contiene todos los conteos por agregaduría qué registran tus conexiones fallidas
Tipos de resultados
Fallos en negociaciones
- “Starttls-not-supported”: Este campo indica que los destinatarios MX no tenían ninguna clase de soporte para los STARTTLS
- “certificate-host-mismatch”: Esto indica que el certificado presentado no se adhiere a las limitaciones especificadas en la política MTA-STS o DANE.
- “certificate-expired”: indica que el certificado ha expirado.
- “certificate-not-trusted”: Esta etiqueta cubre múltiples fallos relacionados a certificados
- “validation-failure”: Este campo indica la presencia de un fallo general o la existencia de algunas de las razones para faltas de coincidencias que ya hemos mencionado.
Fallos de políticas
Fallos de Políticas específicas DANE
- “tlsa-invalid”: Esto indica que existe un error en la validación del registro TLSA asociado a la política DANE.
- “dnssec-invalid”: Esto indica que no existen registros válidos de los protocolos de resolución recursivos.
- “dane-required”: esto indica que el Sistema de envíos está configurado para solicitar registros DANE TLSA para todos los hosts MX en el destino del dominio, pero no hay registros DNSSEC validando los registros TLSA que están presentes en el host MX que está sujeto a los reportes.
Políticas de fallo especificas a MTA-STS
- “sts-policy-fetch-error”: Indica fallo en obtener una política MTA-STS, por ejemplo, por que la política por parte del host no puede ser localizada
- “sts-policy-invalid”: Indica la presencia de un error de validación para toda la política MTA-STS
- “sts-webpki-invalid”: Indica que la política MTA-STS no puede ser autenticada usando la validación PKIX
Esquema de reportes JSON
Observa este ejemplo:
{
«organization-name»: organization-name,
«date-range»: {
«start-datetime»: date-time,
«end-datetime»: date-time
},
«contact-info»: email-address,
«report-id»: report-id,
«policies»: [{
«policy»: {
«policy-type»: policy-type,
«policy-string»: policy-string,
«policy-domain»: domain,
«mx-host»: mx-host-pattern
},
«summary»: {
«total-successful-session-count»: total-successful-session-count,
«total-failure-session-count»: total-failure-session-count
},
«failure-details»: [
{
«result-type»: result-type,
«sending-mta-ip»: ip-address,
«receiving-mx-hostname»: receiving-mx-hostname,
«receiving-mx-helo»: receiving-mx-helo,
«receiving-ip»: receiving-ip,
«failed-session-count»: failed-session-count,
«additional-information»: additional-info-uri,
«failure-reason-code»: failure-reason-code
}
]
}
]
}
“organization-name”: El nombre de la organización responsable por el reporte lo obtienes en forma de hilo de conexión.
“date-time”: Las fechas indican el momento en que inician y culminan los reportes según su rango.
“email-address”: La información de contacto para el actor responsable del reporte.
“report-id”: Un identificador exclusivo para un reporte en particular.
“policy-type”: El tipo de política que fue aplicada desde el dominio de envío.
“policy-string”: La codificación que fue aplicada como política en forma de una serie de hilos JSON.
“domain”: La política del dominio contra la cual las políticas MTA-STS o DANE fueron definidas.
“mx-host-pattern”: En caso de que el “tipo de política” sea “sts”, el patrón de los hostnames MX viene de la aplicación de esta política.
“ip-address”: La dirección IP que envía el MTA que intenta todas las conexiones STARTTLS.
“receiving-mx-hostname”: El hostname del registro MTA MX receptor que envía los MTA que intentan negociar con las conexiones STARTTLS.
“receiving-mx-helo” (opcional): El hilo de conexión HELLO (HELO) o Extended HELLO (EHLO) del banner que anuncia el reporte de la sesión.
“receiving-ip”: La dirección IP del destinatario que fue utilizada para crear la sesión saliente.
“total-successful-session-count”: La cuenta por agregaduría de las conexiones TLS que se han negociado exitosamente con el sitio web receptor.
“total-failure-session-count”: La cuenta por agregaduría de los fallos en los intentos por negociar con una conexión TLS del sitio receptor.
“failed-session-count”: El número de intentos de inicio de sesiones que hacen juego con el “result-type“ que es relevante para esta sección.
“additional-info-uri” (opcional): Un URI que señala información adicional en torno al “result-type”. Por ejemplo: este URI puede que de hospedaje a un certificado completo presente en una cadena específica durante todos los intentos de sesiones STARTTLS.
“failure-reason-code”: Un campo de texto que incluye todos los errores relacionados a los errores específicos de un TLS o cualquier otro tipo de mensaje.
Los reportes SMTP TLS proveen visibilidad en los fallos de configuración y en los intentos para interceptar o cambiar un correo electrónico entre dos servicios de hosting que respalda las políticas STARTTLS.
Crea una cuenta con EasyDMARC para mejorar la seguridad de tu dominio.