Entendiendo SSL man-in-the-middle y sus limitaciones

Navega tus respuestas
1

Estoy tratando de desarrollar un buen sentido de cómo funciona un administrador de SSL (MITM). Como lo entiendo, los MITM hacen su trabajo de una de dos maneras:

  1. Descifre el SSL teniendo una copia de la clave privada del servidor. Estrictamente hablando, esto no es MITM ya que el "dispositivo MITM" simplemente está escuchando a escondidas. La sesión SSL no se cambia
  2. Generar nuevos certificados sobre la marcha. Aquí, el dispositivo MITM reenvía al cliente hola, intercepta el certificado del servidor, genera y firma uno nuevo y lo reenvía al cliente. El cliente confía en el certificado o se le pide que confíe en él (si es autofirmado)

Sin embargo, hay limitaciones (y mitigaciones):

  1. El Cliente y el Servidor podrían acordar generar e intercambiar claves usando DHE_RSA (o una variante). El MITM no participaría en la generación clave. Pero, ¿no puede un MITM lo suficientemente sofisticado todavía generar claves de sesión que creen sesiones de ssl distintas en cualquier lado?
  2. ¿No iría lo mismo con el Secreto Maestro Extendido? Como se indicó anteriormente, si el MITM en realidad estuviera computando claves de sesión distintas, el Secreto maestro extendido no ayudaría a derrotar al MITM
  3. El servidor puede requerir un certificado de cliente. Pero si el MITM podría adquirir su propio certificado de cliente y la clave privada correspondiente, podría firmar con éxito los mensajes de reconocimiento de verificación de certificado

¿Estoy entendiendo todo esto correctamente? Parece que si un MITM tuviera acceso a suficiente material clave, podría descifrar cualquier sesión SSL.

    
pregunta The_Glidd 03.05.2017 - 18:57
fuente

2 respuestas

1

Creo que entendiste bien algunos de los conceptos, pero también hay algunos malentendidos o inexactitudes.

  • Descifrar el tráfico en un hombre pasivo en el ataque central (es decir, solo olfatear) mediante el uso de la clave privada del servidor solo es posible cuando se usa el intercambio de claves RSA. No se puede hacer con el intercambio de claves Diffie-Hellman. Contrariamente al intercambio de claves RSA, el intercambio de claves DH también causa secreto hacia adelante , lo que significa que las conexiones previamente detectadas no se pueden descifrar una vez que el atacante obtuve la clave privada del certificado.
  • Un hombre activo en el ataque central consiste en una sesión SSL del cliente a MITM y de MITM al servidor. Estas son sesiones completamente separadas que tienen claves diferentes y también pueden usar un cifrado diferente, versión de protocolo, etc. Si el atacante MITM tiene la clave privada original del servidor, puede hacerse pasar por el servidor perfectamente utilizando el certificado original. De lo contrario, es necesario utilizar un certificado falso (a menudo creado de forma dinámica). El ataque solo tiene éxito en este último caso si el cliente ya confía en la CA que emite el certificado falso o si el cliente no realiza la validación adecuada del certificado.
  • Los certificados de cliente son similares a los certificados de servidor: o el atacante tiene la clave privada del certificado original y, por lo tanto, puede usarlo o el servidor necesita confiar de alguna manera en que el certificado falso de los atacantes, respectivamente, no valide correctamente el certificado.
respondido por el Steffen Ullrich 03.05.2017 - 19:57
fuente
1

La amenaza más obvia con MITM es cuando la interacción se simplifica, por ejemplo, entre un sitio web y un navegador. En la mayoría de los casos, el usuario simplemente escribe la URL y espera ver una notificación de que la conexión es segura. Si el sitio presentado cumple con sus expectativas, se ocupan de su negocio.

pasarelas de seguridad utiliza MITM de manera divertida para realizar el filtrado de contenido en las conexiones HTTPS. En estos casos, la puerta de enlace actúa como un proxy para todo el tráfico saliente; La conexión HTTPS es entre el cliente y la puerta de enlace. En entornos corporativos, el departamento de TI solía sacar la CA raíz para la puerta de acceso a todas las máquinas internas, lo que permite al cliente acceder al certificado de la puerta de enlace y mostrar la conexión como segura. Luego, la puerta de enlace descifra la solicitud, los filtra según corresponda y establece su propia conexión segura con el servidor. Esto también se aplica a las conexiones SMTP seguras y a cualquier otro protocolo que esté forzado por proxy.

Un sorteo en el escenario anterior es que el certificado utilizado por la puerta de enlace usualmente identifica la conexión con un proveedor de puerta de enlace (ya sea Sophos, Checkpoint, Fortinet, etc.).

En el caso de los actores maliciosos, el objetivo es la intercepción subrepticia. Para que esto sea exitoso, el actor habrá comprometido una CA raíz genérica de confianza. A través de ese compromiso, el actor puede emitir un nuevo certificado con todos los detalles esperados para el servidor.

Suponga que los huéspedes del hotel (Alice) se alojan en un lugar hostil. Quieren usar los servicios de Bob.com. El actor Malory está intentando el MITM.

Malory se conecta a Bob.com y copia todos los detalles comerciales del certificado SSL de Bob.com. Malory ha comprometido previamente WeTrust Root CA, que está integrada en Windows, macos, ios y Android.

Malory se inserta en la red del hotel (puede ser un toque físico, un desvío de puerto en el conmutador o incluso un simple ataque DHCP). Malory redirige todo el tráfico a través de su proxy transparente en busca de acceso a Bob.com.

Cuando Alice accede a Bob.com, el proxy de Malory se presenta a Alice como Bob.com utilizando el certificado falsificado. Mientras tanto, Malory se conecta a Bob.com y reenvía solicitudes / trámites / empujones / pone / etc entre ambos. A menos que Alice mire al emisor de la CA raíz y sepa quién es el emisor de certificados SSL de Bob.com (y también dado que el emisor de certificados SSL de Bob.com no es el mismo que el comprometido por Malory), no tendría forma de detectar el MITM.

MITM se trata de insertarse en el intercambio de claves, no de descifrar el cifrado y de usar un simple monitoreo de tráfico de wirehark / netflow.

    
respondido por el Jean-Michel Florent 03.05.2017 - 20:14
fuente

Lea otras preguntas en las etiquetas

¿Cómo evitar el acceso basado en la dirección MAC en la red local e internet? Cómo verificar la identidad de otra computadora