SMTP con STARTTLS en sí no es una vulnerabilidad, aunque ofrece una superficie de ataque dada la complejidad de la implementación típica de TLS. Si no lo necesita, apáguelo (NIST SP800-123 §4.2.1 PDF).
Si confías solo en SMTP + STARTTLS para las comunicaciones de forma confidencial, es fácil hacerlo mal.
Protocolos de STARTTLS ( LDAP , FTP más o menos, POP3 & IMAP , incluso HTTP que Apache admite , aunque nunca se dio cuenta de ello) son intrínsecamente más difíciles de administrar desde la perspectiva de la política de seguridad y el firewall. Por ejemplo, si tiene una regla que permite que HTTPS acceda a un servidor web configurado correctamente, todo lo que debe hacer un firewall es verificar / aplicar los registros SSL / TLS.
Con los protocolos STARTTLS, para garantizar el cifrado con un nivel de confianza similar, debe tener una inspección de protocolo mayor (puede que no esté disponible en su firewall, puede requerir un proxy); o una confianza mucho mayor en las implementaciones de cliente y servidor (por ejemplo, para evitar el envío o la aceptación de credenciales de texto sin formato).
El punto anterior es más o menos de lo que se trata la advertencia: con un protocolo TLS estricto como HTTPS puede tener más confianza (aparte de los cifrados NULL) en el cifrado de la conexión que con STARTTLS y la posible negociación opcional del cifrado. Es un riesgo que debe evaluarse, no una vulnerabilidad .
La configuración típica de SMTP + STARTTLS (sin autenticación del cliente) (según mi experiencia) es:
- STARTTLS oportunistas
- retroceda para borrar el texto en caso de error, o cuando falte STARTTLS
- tiene valores predeterminados deficientes (selección de cifrado, validación de certificado)
Para utilizar correctamente STARTTLS para aumentar la seguridad de la comunicación, debe tener en cuenta el DNS, el elphant en la sala , copias de seguridad de MX y anulación de MX ("mailertable").
Un servidor client-auth ( SMTPAUTH ) con STARTTLS es más fácil de proteger si solo es para habilitar la autentificación segura del cliente de roaming (a través de certificado de cliente, nombre de usuario / contraseña, o ambos) para fines de transmisión.
Una implementación de canal segura ideal ofrece (al menos) tres cosas:
- confidencialidad / privacidad (encriptación)
- autenticidad (prueba de identidad de una o ambas partes)
- integridad (a prueba de manipulación indebida, o evidencia de manipulación indebida)
SMTP + STARTTLS se desvía de esto:
- debido a que la comunicación comienza de nuevo y se basa en un canal de texto sin formato corrupto y no autenticado, existe un margen para la interferencia de MITM. Si STARTTLS es oportunista, esto significa que podría ser subvertido de manera trivial (si alguna vez vio a un Cisco PIX o ASA haciendo su protocolo SMTP "fixups " habrás visto algo similar en acción). Problema similar si la validación del certificado es laxa.
- SMTP es un protocolo de almacenamiento y reenvío, la capacidad TLS es solo punto a punto, no hay una característica "CONECTAR" similar al proxy HTTP. es decir, esto no es un cifrado de extremo a extremo. La confidencialidad, la autenticación y la integridad están limitadas a las conexiones, no al mensaje, lo que podría no ser lo que un usuario espera o requiere. Consulte también ¿Cómo puede un usuario no técnico verificar que un mensaje se envió" de forma segura "? ... o sobre TLS?