Una historia de dos fuentes: ¿Es TLS * defense * contra Man-in-the-Middle, o no?

Para citar la parte importante del artículo al que hace referencia:

  

La desventaja es que este tipo de seguridad se aplica por separado en cada salto en la ruta de comunicación, lo que hace que la comunicación sea susceptible a un ataque de hombre en el medio.

TLS se utiliza en diferentes casos de uso. Algunos de estos casos implican un único transporte de extremo a extremo del mensaje, por ejemplo, cuando un cliente envía un mensaje a un servidor web, que luego el servidor procesa directamente. TLS protege con éxito contra el hombre en los ataques medios en este caso.

Pero TLS también se usa cuando hay varios saltos involucrados. En este caso, el transporte solo está protegido con TLS entre estos saltos, pero un hombre en el medio en cualquiera de estos saltos puede interceptar los datos sin cifrar. Este caso de uso es típico del correo (es decir, SMTP), pero también lo encuentra con HTTPS cuando usa un proxy inverso, una red de distribución de contenido o similar. En estos casos, TLS proporciona solo seguridad salto por salto, pero no seguridad de extremo a extremo. Esto último se puede lograr cifrando el mensaje antes del transporte y desencriptándolo después de que se realice el transporte completo (es decir, todos los saltos). Para el correo, esto generalmente se hace con PGP o S / MIME.

Imagina dos escenarios diferentes:

Llamadas típicas / directas

Tienes un cliente y un servidor. El cliente envía un mensaje al servidor; el servidor hace algo con la solicitud, crea una respuesta y anula la memoria que contenía la solicitud original. La solicitud no se reenvía a ningún otro sistema.

En este caso, el transporte está bien y no es particularmente susceptible a MitM, asumiendo que tiene configurado su capa de transporte seguridad correctamente . Hay muchas confusiones que puedes desordenar, pero deberías poder auditarlas y corregirlas mediante una prueba de lápiz.

Llamadas que involucran a tres o más partes

Tiene un cliente, un servidor de aplicaciones y un servidor específico del dominio (por ejemplo, un servidor que ejecuta middleware de host bancario). El cliente envía un mensaje al servidor de aplicaciones; el servidor de aplicaciones analiza los mensajes, autentica a la persona que llama y reenvía una parte al host de la banca.

En esta situación, un protocolo de seguridad de capa de mensaje permitirá que el host bancario confíe en que el mensaje de solicitud se recibió del cliente original intacto y sin molestias. Si estaba utilizando la seguridad de transporte, es posible que el servidor de la aplicación haya hecho algo malicioso, ya que habría descifrado y vuelto a cifrar el mensaje. Con la seguridad de la capa de mensajes, puede cifrar o firmar partes del mensaje y pasarlo intacto.

Uso de la seguridad del transporte con un intermediario de confianza

Dicho esto, si el servidor de aplicaciones es de confianza, el host bancario puede autenticar el servidor de aplicaciones (a través de la seguridad de transporte) si utiliza certificados de cliente. Con este tipo de configuración, puede utilizar la seguridad de la capa de transporte con el riesgo de mitigar adecuadamente el ataque MitM.

  

La afirmación es que la seguridad del "modo de transporte" es insegura:

     

    

"El modo de transporte es la opción menos segura y debe evitarse."

  

Yo diría que estás leyendo mal el documento. No dice que el modo de transporte sea inseguro; dice que es la opción menos segura y, implícitamente, entre el conjunto de opciones de las que se habla.

No debe considerar la seguridad como un problema binario de sí / no; más bien, debería verlo en términos más concretos, como una lista de las formas en que podría atacarse el sistema. En su caso, incluso si la seguridad de transporte está configurada lo más fuertemente posible (certificados SSL entre cada cliente y el servidor), hay escenarios en los que la comunicación pasa por más de un salto SSL (por ejemplo, hay un proxy de equilibrio de carga entre el cliente). y el punto final). Si alguno de los servidores en esa cadena es hackeado, entonces el atacante puede romper ambos:

1. Confidencialidad: el atacante puede leer el contenido de la carga útil.
2. Autenticidad: el atacante puede falsificar mensajes que parecen provenir del cliente.

Otra forma de ponerlo: si usa el sistema en esa configuración, los clientes pueden confiar en los servidores intermedios para que no falsifiquen mensajes. No es más seguro que esos servidores intermedios.

Las otras dos opciones que ofrecen son lo que llaman "seguridad de mensaje" y "credencial de mensaje". Estas opciones permiten que los clientes tengan menos confianza en el servidor:

• En el modo de seguridad de mensajes, el cliente cifra cada mensaje con una clave que los servidores intermedios no tienen, solo el punto final. Por lo tanto, si un atacante ingresa en un servidor intermedio, solo puede soltar mensajes (y tal vez no indetectable).
• No explican el modo de credencial del mensaje lo suficientemente bien como para que pueda entender su seguridad muy bien. El cliente no cifra los mensajes, por lo que un atacante que irrumpe en el proxy definitivamente puede leerlos. La ventaja sobre la seguridad de transporte parece ser que con la seguridad de transporte cada salto se autentica (el cliente se autentica con el proxy, el proxy se autentica con el punto final), pero con la credencial del mensaje el cliente se autentica en el punto final. Sin embargo, no puedo decir si un atacante que irrumpe en el proxy es capaz de falsificar mensajes. (¡Mala documentación!)

Tenga en cuenta que en los tres modos hay un escenario en algunos en el que un atacante hace que suceda algo malo . Una vez más, la seguridad no es un problema de sí / no.

Cita desde su propio enlace:

  

Cuando se utiliza un transporte como HTTPS, este modo tiene la ventaja de   ser eficiente en su desempeño y bien entendido debido a su   Prevalencia en internet. La desventaja es que este tipo de   la seguridad se aplica por separado en cada salto en la ruta de comunicación ,   haciendo que la comunicación sea susceptible a un ataque de hombre en el medio.

Tonterías.

Si bien "TLS" en sí mismo podría ser usado de esa manera, por ejemplo. en algunos protocolos P2P donde todos los hosts son de confianza por alguna razón, la gran mayoría de los casos de uso son sistemas de extremo a extremo (incluido HTTPS). El autor no parece saber mucho sobre este tema.

Para los sitios web, por lo que sabemos, HTTPS es suficiente para prevenir MITM.