En la Sección 6 de Descripción general del segundo factor universal (U2F) , donde se analizan los ataques MITM, cerca del final de la sección, se lee:
It is still possible to MITM a user's authentication to a site if the MITM is
a. able to get a server cert for the actual origin name issued by a valid CA, and
b. ChannelIDs are NOT supported by the browser.
But this is quite a high bar.
No estoy convencido de que esta sea una barra tan alta. Hemos visto más de algunos casos en los que los atacantes han podido obtener información falsa pero confiable Certificados CA firmados . Y, TLS ChannelID no ha sido adoptado ampliamente por la mayoría de los navegadores y servidores (de hecho, la propuesta borrador de RFC expiró en 2013). Además, incluso si ambos puntos finales admiten el TLS ChannelID, un atacante MITM activo podría evitar que el TLS ChannelID se use por medio de un ataque degradado durante el mensaje de ClientHello.
Aplaudo el salto que FIDO ha dado para reducir nuestra dependencia de las contraseñas y para que la autenticación sea más segura y menos engorrosa para los usuarios. Pero, parece que ha hecho poco para proteger contra un ataque MITM en el que un atacante puede obtener un certificado falso pero confiable, y debemos continuar poniendo toda nuestra fe y confianza en los CA, que tienen una Historia de decepcionarnos. Por supuesto, incluso el protocolo de autenticación más seguro es inútil si la conexión puede verse comprometida por un atacante MITM activo.
Otros protocolos de autenticación basados en claves (como SSH) protegen contra los ataques MITM mediante la fijación de claves públicas incorporadas al protocolo. Con SSH, por ejemplo, los clientes almacenan las claves públicas de los servidores a los que se han conectado. Inmediatamente después de realizar la conexión, durante el intercambio de claves y antes de intentar la autenticación del cliente, el cliente verifica que efectivamente está conectado al servidor deseado, al verificar que la clave pública que está utilizando el servidor es la misma que la del archivo. para ese servidor, y asegurarse de que el servidor esté en posesión de la clave privada asociada con la clave pública a través de alguna operación criptográfica que requiera la clave privada.
Por supuesto, HPKP (sin FIDO) se puede usar para fijar los certificados SSL / TLS de los sitios en el navegador, pero esto tiene su propio conjunto de problemas .
Tengo curiosidad por la razón por la cual los arquitectos de FIDO UAF y U2F no llevaron el protocolo un paso más allá, e incorporaron un método de fijación de clave pública dentro del protocolo (tal vez utilizando diferentes pares de claves que los utilizados para la conexión SSL / TLS). ), para que los clientes puedan asegurarse de que se conectan al servidor legítimo antes de intentar la autenticación, a la SSH. ¿A alguien le gustaría hipotetizar?