¿Qué sucede si STARTTLS se cae en SMTP?

Navega tus respuestas
4

SMTP usa la extensión STARTTLS para actualizar SMTP a SMTP Secure (STMPS). Según el RFC , el cliente y el servidor inician TLS de la siguiente manera: 

S: <waits for connection on TCP port 25>
   C: <opens connection>
   S: 220 mail.imc.org SMTP service ready
   C: EHLO mail.example.com
   S: 250-mail.imc.org offers a warm hug of welcome
   S: 250-8BITMIME
   S: 250-STARTTLS
   S: 250 DSN
   C: STARTTLS
   S: 220 Go ahead
   C: <starts TLS negotiation>
   C & S: <negotiate a TLS session>
   C & S: <check result of negotiation>
   C: EHLO mail.example.com
   S: 250-mail.imc.org touches your hand gently for a moment
   S: 250-8BITMIME
   S: 250 DSN

En el mismo documento, las especificaciones mencionan la posibilidad de MITM:

  

Se puede iniciar un ataque Man-in-the-middle eliminando la respuesta "250 STARTTLS" del servidor.

Lo que no obtengo de las especificaciones es: ¿Qué significa exactamente eliminar? ¿Está eliminando el contenido del mensaje pero enviándolo vacío? (es decir, corromperlo) o soltarlo para que el cliente no lo reciba?

Si significa dejar caer el mensaje para que el cliente no lo reciba, ¿enviará el servidor 250 DSN ? no me queda claro si 250 STARTTLS cayó, ¿cuál será el próximo mensaje? ¿Cómo sabe el cliente que debe enviar EHLO mail.example.com y que no hay 250-STARTTLS ?

    
pregunta user6875880 07.09.2017 - 20:23
fuente

2 respuestas

4

SMTP con STARTTLS funciona creando primero una conexión simple con el servidor y luego actualizándolo a TLS si el servidor lo admite . El servidor muestra soporte para STARTTLS dentro de la respuesta al comando EHLO. Un hombre en el medio podría simplemente modificar la respuesta del servidor y eliminar la información que admite STARTTLS. En este caso, el cliente cree que STARTTLS no es compatible y no actualizará TLS.

Por ejemplo, el diálogo SMTP original podría verse así: 

  << 220 welcome to example.org
  >> EHLO example.com
  << 250-example.org 
  << 250-HELP
  << 250-8BITMIME
  << 250 STARTTLS

A partir de esto, el cliente sabrá que STARTTLS es compatible. Un hombre en el medio o un cortafuegos como Cisco ASA (pero también otros) puede modificar la respuesta para que el cliente crea que TLS no es compatible para inspeccionar el tráfico de forma sencilla: 

  << 220 welcome to example.org
  >> EHLO example.com
  << 250-example.org 
  << 250-HELP
  << 250-8BITMIME
  << 250 XXXXXXXX

Debido a esta modificación (en este caso, al reemplazar STARTTLS con XXXXXXXX), el cliente no sabe que el servidor es compatible con TLS y, por lo tanto, no lo intentará. Incluso si el cliente todavía lo intenta, el hombre en el medio podría reescribir el comando STARTTLS del cliente en algún otro comando (quizás no válido) para que el servidor parezca rechazar el STARTTLS.

Tenga en cuenta que el comportamiento exacto en este caso depende de la configuración del cliente. Mientras que las aplicaciones de usuario final (es decir, MUA - agente de usuario de correo) a menudo se configuran para imponer TLS con el único servidor de correo configurado, este es diferente con MTA (servidor de correo - agente de transferencia de correo) a la comunicación de MTA. Por lo general, los MTA no saben por adelantado qué próximo salto en la entrega será compatible con TLS, por lo que simplemente comprueban si es posible TLS, pero continúan en claro si no parece que es posible TLS.

En resumen: el cifrado oportunista como este es una mala idea ya que un hombre en el medio simplemente puede hacer que ambos lados crean que el otro lado no admite el cifrado.

    
respondido por el Steffen Ullrich 07.09.2017 - 20:35
fuente
2

El hombre en el medio se encuentra entre usted y el servidor SMTP y oculta la transmisión de la capacidad del servidor de 250-STARTTLS (eso es lo que elimina la respuesta "250 STARTTLS" de la servidor significa).

Por lo tanto, el cliente no sabrá que TLS es posible; no intentará TLS; y si no se le ha pedido al cliente que lo solicite , la conversación seguirá de manera clara, y el MitM podrá leerlo en su tiempo libre.

Por lo general, los clientes de correo pueden configurarse como "STARTTLS si están disponibles", "STARTTLS", "sin formato", etc. En interés de la experiencia del usuario, el primero suele ser el predeterminado ("mantener el flujo de correo sin importar qué"). En aras de la seguridad, la segunda opción es claramente mejor.

    
respondido por el LSerni 07.09.2017 - 20:35
fuente

Lea otras preguntas en las etiquetas

¿Es razonable que el software contenga algo que el usuario no pueda manipular? ¿Cuál es la diferencia entre una carga útil y un código de shell?