Limitaciones de la inspección TLS cuando se usa Diffie-Hellman

Question

Limitaciones de la inspección TLS cuando se usa Diffie-Hellman

#1 de Steffen Ullrich (3 votos)

0

Tengo entendido que la inspección TLS se puede realizar de dos maneras diferentes:

1er enfoque: usando un servidor proxy que negocia TLS con ambos extremos.
- En este escenario, habría 2 canales TLS diferentes (Cliente < - > Proxy < - > Servidor)
- Si el cliente / servidor utiliza implementaciones TLS no estándar o si se deben cumplir requisitos específicos en la negociación de TLS, el Proxy deberá tener características específicas que lo permitan.
Segundo enfoque: utilizando un elemento intermedio que contiene los secretos necesarios para descifrar la negociación de la clave compartida TLS (por ejemplo, la clave privada asociada al certificado del servidor) con la capacidad de volver a cifrar (utilizando el certificado del servidor) y reenviar el tráfico al servidor.
- En este escenario, el Cliente y el Servidor no verían el servidor intermedio y esencialmente sería un canal TLS único, incluso si el elemento intermedio puede ver y bloquear el tráfico sospechoso.
- El elemento intermedio no tendría que implementar otras funciones, ya que solo actúa escuchando y reenviando / bloqueando.

Cuando se utiliza una aplicación de cifrado DH o ECDH a través de una comunicación TLS, ¿es posible hacer uso del Segundo Enfoque? Por lo que sé, el Intercambio de claves en DH hace imposible que un "interlocutor" descubra cuál es el secreto compartido, ya que las claves privadas RSA solo se usan como medio para autenticar el servidor.

Según el cryptosuite utilizado, ¿la inspección TLS se limitaría al primer enfoque?

tls diffie-hellman

pregunta Jausk 19.02.2018 - 10:42

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls diffie-hellman

Violación de seguridad del sitio web desde un iframe suplantación de ID de nombre SAML

score 3 · Accepted Answer

Ambos enfoques describen esencialmente lo mismo: hay algún sistema intermediario que termina TLS y usted tiene esencialmente dos conexiones TLS: una desde este middlebox al cliente y una desde el middlebox al servidor.

La única diferencia es que en su segundo escenario, el middlebox tiene acceso al certificado y la clave privada del servidor y, por lo tanto, puede suplantar completamente el servidor sin cambios en el cliente. Si bien no describe el primer caso con más detalle, mi conjetura es que, en este caso, los certificados se crean de forma dinámica por el proxy y los firma un CA en el que el cliente confía explícitamente. Este primer caso generalmente se puede encontrar en un servidor de seguridad que debería dar acceso al cliente a muchos sitios en Internet, mientras que el segundo caso se usa para proteger un servidor específico (por ejemplo, mediante el uso de un servidor de seguridad de aplicación web).

Dado que en ambos casos tiene dos conexiones TLS separadas e independientes, DH no tiene nada de especial, es decir, ambas conexiones pueden usar el intercambio de claves DH.

Pero, hay un tercer escenario donde un sistema de detección de intrusos (IDS) obtiene el tráfico intercambiado entre el cliente y el servidor y debe detectar pasivamente ataques contra este servidor, es decir, sin ser el punto final de TLS. En este caso, solo hay una conexión TLS de extremo a extremo entre el cliente y el servidor. Y para descifrar el tráfico para el análisis, las necesidades de IDS tradicionalmente tienen acceso al servidor de claves privadas, pero esto solo funciona con el intercambio de claves RSA. Para hacer posible este análisis pasivo con DH, el IDS debería tener acceso al secreto maestro de cada nueva conexión, es decir, de alguna manera el servidor debe proporcionar esta información al IDS. Y esto es mucho más complejo que simplemente proporcionar al IDS la clave privada estática del certificado.