¿Es STARTTLS una vulnerabilidad de seguridad?

7

Después de leer sobre STARTTLS y SSL y realizar un escaneo / prueba en nuestro servidor, tengo la siguiente pregunta con respecto a la seguridad: ¿Esta advertencia de STARTTLS está por debajo de una vulnerabilidad de seguridad? Y si es así, ¿por qué?

Por lo que entiendo de STARTTLS, significa:

  

Cifre si ambos lados admiten el cifrado; de lo contrario, utilice una conexión no cifrada

y SSL:

  

Siempre use el cifrado, si un lado de la conexión no admite SSL, no se conecte en absoluto.

Mi escaneo dio como resultado la siguiente advertencia:

  

El servicio SMTP remoto admite el uso del comando 'STARTTLS' para cambiar de un texto sin formato a un canal de comunicaciones cifrado.

    
pregunta Rob 11.03.2014 - 13:52
fuente

4 respuestas

8

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:

  1. confidencialidad / privacidad (encriptación)
  2. autenticidad (prueba de identidad de una o ambas partes)
  3. 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?
respondido por el mr.spuratic 12.03.2014 - 14:48
fuente
2

La idea es que debe habilitar SSL de forma predeterminada y no permitir la comunicación de texto sin formato. STARTTLS significa que debe indicar explícitamente al servidor que use SSL si lo desea.

    
respondido por el Lucas Kauffman 11.03.2014 - 14:05
fuente
2

Técnicamente, sí, ofrecer un canal no cifrado significa que la información puede transmitirse a / desde su servidor de forma insegura. El problema es que no todos los servidores de correo proporcionan cifrado y si desea recibir / enviar un correo electrónico a un servidor que no lo admite, debe permitirlo.

Esto potencialmente permite que un intermediario pretenda que cada punto final no admite el cifrado y se inyecta en el medio, pero la alternativa es, desafortunadamente, fallar una gran parte de la entrega de correo.

    
respondido por el AJ Henderson 11.03.2014 - 14:13
fuente
0

Antes de STARTTLS, el protocolo de enlace inicial se produce sobre texto sin formato, por lo tanto, el atacante que se encuentra en la misma red puede forjar la respuesta del servidor y hacer que el usuario sienta que el protocolo de enlace TLS no está disponible con el servidor. Eso puede resultar en una falla.

    
respondido por el FrOgY 06.11.2017 - 23:03
fuente

Lea otras preguntas en las etiquetas