¿Los certificados de cliente proporcionan protección contra MITM?

Un ataque Man-in-the-middle es cuando un atacante se inserta entre el cliente y el servidor, y se hace pasar por el cliente al hablar con el servidor, y se hace pasar por el servidor al hablar con el cliente. La "suplantación" solo tiene sentido en la medida en que hay una identidad de par esperado; no puede hacerse pasar por un cliente anónimo.

Desde el punto de vista del servidor , si el cliente muestra un certificado y usa su clave privada como parte de un mensaje CertificateVerify (como se describe en SSL/TLS standard , sección 7.4.8), y el servidor valida el certificado del cliente con respecto a un conjunto de anclajes de confianza que no incluye una raíz hostil o incompetente CA, entonces el servidor tiene una garantía de que está hablando con el cliente correcto (el identificado por el certificado del cliente). La garantía se mantiene para todos los datos subsiguientes dentro de la conexión ( NO se extiende a los datos intercambiados antes del acuerdo donde el cliente mostró un certificado, en caso de que el acuerdo fuera una "renegociación").

Esto significa que un certificado de cliente protege de hecho contra el escenario específico de una CA falsa inyectada en el cliente almacén de confianza. En ese escenario, el "atacante" logró que el cliente confiara en una CA raíz específica que está controlada por el atacante, lo que le permite ejecutar un ataque MitM creando un certificado falso para el servidor de destino sobre la marcha (esto es exactamente lo que sucede con algunos servidores proxy de "filtrado de contenido SSL" que se implementan en algunas organizaciones). Dicha MitM rompe la autenticación del certificado del cliente, porque lo que el cliente firma como parte de un mensaje CertificateVerify es un hash calculado sobre una gran cantidad de datos, incluido el certificado del servidor; en el escenario MitM, el cliente no ve el certificado "correcto" y por lo tanto, calcula una firma incorrecta, que el servidor detecta.

Desde el punto de vista del cliente , si el servidor solicitó un certificado de cliente y luego el el cliente sabe que el verdadero servidor detectará cualquier MitM. El cliente no detectará el propio MitM; y si hay un ataque MitM en curso, entonces el cliente realmente está hablando con el atacante, y el atacante no le dirá al cliente "por cierto, actualmente estás siendo atacado".

En ese sentido, un certificado de cliente evita una MitM verdadera (también conocida como "suplantación de dos caras") pero no protege contra fraudes más simples (suplantación de una sola cara, es decir, servidores falsos).

Conclusión: En presencia de SSL con autenticación mutua cliente-servidor (ambos envían un certificado al otro), un MitM exitoso requiere que el atacante plante una CA falsa tanto en el cliente como en el servidor. Sin embargo, si el atacante puede plantar una CA deshonesta solo en el cliente, el cliente todavía se encuentra en una situación bastante mala (aunque se ha frustrado un MitM completo).

Un certificado del lado del cliente, al igual que cualquier tecnología segura de clave pública-privada, brindará protección contra MITM.

El principal problema con los certificados del lado del cliente en este extremo es el phishing o el atacante que de otra manera recupera el certificado / clave privada del usuario final, que suele ser mucho más fácil que desde un servidor porque los usuarios finales no saben mucho sobre seguridad. Cuando un atacante ha recuperado el pk / certificado, puede ejecutar un ataque MITM transmitiendo toda la información proveniente del cliente, ya que solo puede volver a cifrar los datos utilizando el pk / certificado.

Tenga en cuenta que para un ataque MITM exitoso, se necesitan los certificados / pk del cliente y del servidor, ya que de lo contrario una parte de la comunicación no se puede descifrar.

Si se adhiere a la definición estricta de un MiTM (que no implica manipulaciones de almacenes de certificados), la respuesta se proporciona en TLS RFC, apéndice F.1.1 :" Cada vez que se autentica el servidor, el canal es seguro contra ataques de intermediario ". Así que para un MiTM puro, los certificados de cliente ni siquiera son necesarios.