Soy un poco nuevo en esta área y he estado leyendo sobre los ataques de Man in the middle. Casi en todas partes, la solución provista parece ser utilizar un tercero de confianza como una Autoridad de Certificación.
¿Hay algún resultado de imposibilidad que implique que las dos partes que se comunican no pueden resolverlo por su cuenta? ¿Hay alguna forma de hacerlo sin utilizar una CA?
No es necesario utilizar una CA, incluso con HTTPS. Simplemente puede usar un certificado autofirmado en el servidor si le proporciona al cliente una copia o similar (es decir, huella digital) de este certificado de manera segura (a prueba de manipulaciones) antes de que el cliente se conecte al servidor para que el cliente pueda verificar que habla con el servidor esperado. Si el cliente no puede verificar el servidor, es posible realizar ataques en el medio.
El concepto de certificados firmados por CA (es decir, infraestructura de clave pública (PKI) ) solo se crea porque se comparte una Los certificados firmados de hoja con todas las partes no escalan. Con CA, el navegador / sistema operativo tiene una lista de anclajes de confianza (certificados raíz) y puede derivar la confianza a un certificado de servidor basado en una cadena de confianza desde la raíz confiable al certificado hoja. Debido a este mecanismo, solo se debe compartir la CA raíz de confianza, pero no todos los certificados de servidor posibles.
Además de un certificado compartido previamente o información pública similar (como una huella digital del servidor SSH), las conexiones resistentes a MITM también se pueden establecer mediante el uso de un secreto compartido en ambos lados. Ese es el caso típico en el hogar Wifi protegido con WPA.
La protección limitada contra MITM se logra con Trust On First Use (TOFU). En este caso, la identidad del par se guarda desde la primera conexión y se aplica a las siguientes conexiones con la esperanza de que el atacante no estuviera presente en la primera conexión, es decir, que la identidad recibida fuera la verdadera identidad del par esperado. Esto se hace, por ejemplo, si uno acepta un certificado autofirmado en HTTPS.
SSH es un ejemplo de TOFU (Confianza en el primer uso) que no requiere que una CA (o incluso un tercero) participe en el establecimiento de una relación de confianza.
La mayoría de las claves precompartidas (por ejemplo, como se usan para WPA en wifi o en una solución VPN) pueden brindar cierta protección contra ataques MitM si se usan correctamente y sin necesidad de establecer confianza a través de una CA (o PKI), y sin la necesidad de involucrar tokens criptográficos.
Considere también que MitM puede ser facilitado por una CA (por ejemplo, cuando una CA debe emitir certificados sin llevar a cabo los controles necesarios para validar la identidad, debido a un compromiso, presión legal o malicia), y el uso de una PKI no ofrece necesariamente protección contra MitM; simplemente establece que un token dado (una clave) se considera razonablemente para representar una reclamación (de identidad), y las malas opciones de criptografía podrían, por ejemplo, anular cualquiera y todas las reclamaciones / aserciones.
Actualizado :
Como se señala en @ Steffen Ullrich en los comentarios a continuación, TOFU es susceptible a MitM durante el primera conexion Esto podría mitigarse (por ejemplo, proporcionando algún mecanismo para validar las claves de host que se presentan). Después de esa primera conexión, estás a salvo de MitM o totalmente expuesto.
Tenía la intención de señalar a TOFU como un enfoque diferente para establecer la confianza (dejar que los usuarios lo descubran, básicamente), pero Steffen tiene toda la razón de que TOFU y PKI adopten un enfoque fundamentalmente diferente para validar la identidad inicialmente, con la creación de TOFU una decisión de diseño para no abordar el riesgo de MitM durante la primera conexión, por lo que los dos modelos de confianza tienen un impacto diferente en la capacidad de protegerse contra MitM.
Dado que la pregunta era acerca de por qué mucha literatura MitM menciona la PKI, esta es una respuesta parcial: de los enfoques más comunes para la protección contra MitM, una solución basada en PKI proporciona más protección que otros enfoques como TOFU.
El cliente necesita alguna forma de verificar que el servidor es quien dice que es.
Hay varias formas de verificar esto:
Lea otras preguntas en las etiquetas authentication certificates man-in-the-middle certificate-authority