¿Cómo prevenir los ataques de intermediarios junto con SSL?

2

Me gustaría discutir este escenario:

Hay un servicio HTTPS que responde con claves firmadas a un cliente autenticado. Estas claves firmadas se pueden usar para que otro servicio devuelva datos muy sensibles. Supongamos que debido a algún agujero de seguridad interno (prácticas sin experiencia, clave ssh expuesta en el servidor git, alguien envió el ssl ca con un correo electrónico, ...) una persona recibe el certificado, y ahora puede cifrar cada conexión y simplemente escuchar en el el servidor responde con una de las claves de seguridad firmadas que puede usar para acceder a los datos sensibles del otro servicio.

¿Existe alguna técnica que pueda invalidar la clave de seguridad firmada cuando puede haber ocurrido un ataque de intermediario (quizás un segundo túnel SSL)?

    
pregunta bodokaiser 24.08.2013 - 20:06
fuente

3 respuestas

6

Bueno, hay muchas otras opciones además de SSL para prevenir a un hombre en el ataque central, pero la mayoría de ellas tienen una base criptográfica similar. Fundamentalmente, para asegurar que una comunicación no pueda ser atacada por un hombre en el medio, debe poder probar que a) ambas partes pueden validar la otra yb) que ninguna otra parte puede monitorear la comunicación.

Ambos de estos se realizan más comúnmente a través de un secreto compartido. Las operaciones criptográficas asimétricas también se pueden usar cuando ambas partes tienen una clave pública confiable para la otra, sin embargo, esto es mucho más difícil (computacional) que intercambiar un secreto compartido y luego usarlo.

El secreto compartido puede ser compartido previamente, como en el caso de una red wifi encriptada, o puede negociarse mediante un proceso de autenticación. Por ejemplo, con SSL, el servidor se valida al cliente mediante la firma de la clave pública, el cliente establece un secreto compartido con el servidor mediante el certificado de confianza del servidor y el servidor luego valida al cliente mediante un inicio de sesión tradicional (o posiblemente un certificado de cliente en casos raros.)

Este proceso general no es exclusivo de SSL, pero los pasos básicos para verificar la identidad de una o ambas partes y establecer una clave de comunicación segura son los bits críticos. Sin embargo, si se comprometiera la raíz del fideicomiso para ese certificado, sería posible que alguien se ocupara del medio, ya que podrían pretender ser el servidor y abrir su propia conexión con el servidor y su propia conexión con el cliente.

En el caso de una pérdida de clave privada, el certificado debe revocarse a través de una lista de revocaciones. Esto generalmente lo publica una CA y se incluye como parte del certificado firmado. Como condición para validar la validez del certificado, se debe verificar la validez de la lista de revocaciones.

    
respondido por el AJ Henderson 24.08.2013 - 20:18
fuente
5

Parece que lo que estás preguntando es: ¿cómo puedo prevenir un MITM si mi clave privada puede verse comprometida? Y a eso, la respuesta es obtener una nueva clave privada (y por lo tanto nuevo certificado).

Si su política de seguridad es tan desastrosa que un pasante puede cargar su clave privada SSL en github, entonces ese es su problema. Las claves privadas son privadas y deben estar protegidas como tales. Nadie debe tener acceso a su clave privada, lo que significa que a las personas se les debe impedir física o tecnológicamente el acceso. Simplemente instituir una política que diga "no cargar la clave privada en usenet" no es suficiente. En realidad, debe evitar el acceso no deseado a datos privados.

A menos que pueda hacerlo, no tiene ninguna esperanza de mantener una apariencia de seguridad de datos.

Además, parece que confunde la clave privada con el certificado. Puede hacer lo que quiera con el certificado (que incluye certificados firmados); envíelo por correo electrónico a amigos, publíquelo en su muro de Facebook, publíquelo en Github, cualquier cosa es segura. Pero la clave privada nunca debe dejar la computadora donde se generó.

    
respondido por el tylerl 25.08.2013 - 01:52
fuente
0

Cuando MITM se lleva a cabo en la fase de intercambio de claves, puede aplicar cifrado basado en ID , donde el público La clave es el ID del destinatario para evitarlo.

    
respondido por el Wang Ye 30.08.2013 - 12:14
fuente

Lea otras preguntas en las etiquetas