¿Cómo funciona la autenticación bidireccional usando SSL?

Supongo que el modelo de amenaza es que puede haber un atacante de tipo intermediario entre Alice y Bob, y que Alice y Bob no están en la misma subred confiable. Eso es contra lo que SSL / TLS está diseñado para protegerse, y esa es la razón por la cual Alice debería verificar el certificado de Bob en su ejemplo (al menos).

Desde el punto de vista de Bob, verificar que la solicitud de Alice provenga de una dirección IP conocida no sirve de mucho. Los atacantes pueden forjar y alterar paquetes para que parezcan que provienen de la dirección IP que desean. Posteriormente, las búsquedas de DNS también son inútiles: todo lo que necesita es asegurarse de que falsifica los paquetes para usar una dirección IP con la entrada de DNS correcta.

Cuando Bob solicita un certificado de cliente a Alice durante el protocolo de enlace SSL / TLS, esto también hará que Alice envíe su certificado y use su clave privada durante el protocolo de enlace SSL / TLS para afirmar su identidad. Cuando el saludo se haya completado con éxito, Bob sabrá que Alice tiene la clave privada para ese certificado y tendrá que verificar que confíe en este certificado.

Si la solicitud proviene o no de un proxy o no, no importa cuando esté usando SSL / TLS. Un proxy HTTP simplemente canaliza la conexión SSL / TLS del cliente original al servidor de destino.

Lo que le importa a Bob es cómo va a verificar el certificado de Alice. Por lo general, esto se hará usando una PKI de la misma manera que Alice verificó el certificado de Bob, aunque no es necesario que sea el mismo CA que Bob (debe ser algo en lo que Bob confía). Tenga en cuenta que esto tampoco necesita estar usando una PKI. Es posible verificar el certificado contra una lista dada (si Alice y Bob se han reunido antes, por ejemplo), pero esto puede ser un poco más complejo ya que Bob puede tener que modificar la lista de emisores aceptados que envía (por ejemplo, enviar una vacía, lo cual está permitido explícitamente por TLS 1.1, pero no se especifica de ninguna manera en versiones anteriores, vea Mensaje de solicitud de certificado ) y usa un código personalizado para verificar ese certificado. (He implementado este tipo de esquema en el pasado y funciona bien).

Hay una excepción a esto cuando se usa lo que yo llamaría "servidores proxy MITM", es decir, los servidores proxy que están configurados para falsificar el servidor SSL / TLS real insertando su propio certificado (consulte SSL Bump de Squid ). En este caso, el certificado que ve Alice no provendría de Diginotar, sino de otra CA (normalmente una CA corporativa cuando se hace en una LAN corporativa).

Aunque Alice podría permitirse confiar en un proxy MITM de este tipo, el uso de la autenticación de certificado de cliente SSL / TLS haría que Bob se diera cuenta de que existe un MITM y que la conexión fallaría. Esto se debe a que se supone que Alice debe firmar el protocolo de enlace SSL / TLS completo (como lo ven tanto Alice como Bob) en su CertificateVerify mensaje para autenticar con un certificado de cliente. Dado que el proxy MITM habría reemplazado el certificado de Bob, las firmas enviadas por Alice y Bob no coincidirían.

No del todo. Una vez que se completa el protocolo SSL, Bob sabe que está hablando con alguien que Verisign ha certificado como alice.in.wonderland.com . Lo que Bob haga con esta información en este momento depende de él, y dependerá de la aplicación en particular. Algunos ejemplos:

• Bob puede tener una lista blanca de clientes a los que se les permite conectarse. Entonces Bob buscaría alice.in.wonderland.com en esta lista. (Como alternativa, Bob podría tener una lista blanca de claves públicas, pero los certificados de los clientes podrían facilitar las cosas para que Bob las administre, porque ahora puede ingresar valores legibles para el usuario en su lista blanca).

• Bob podría tratar a alice.in.wonderland.com como el nombre de usuario de Alice e iniciar sesión en su cuenta. En otras palabras, Bob podría tener una base de datos con una lista de usuarios; para cada usuario, tendría el nombre del usuario (como se encuentra en el certificado del usuario) y toda la información asociada con ese usuario. Una vez que Bob recibe una conexión de alguien con el nombre N, Bob puede buscar N en la tabla y registrar automáticamente al cliente como N. Cuando alguien crea una nueva cuenta, Bob puede crear automáticamente una nueva cuenta con el nombre que se encuentra en su certificado ( asumiendo que uno no existe ya. El resultado es que los usuarios pueden iniciar sesión en el servicio de Bob, sin necesidad de ingresar un nombre de usuario o contraseña; su certificado de cliente se utiliza para autenticarlos.

De nuevo, esto depende de la aplicación; depende de lo que Bob quiera saber sobre la identidad de la computadora con la que está hablando. No hay una respuesta única.

Dependería de la implementación específica.

En general, Alice actuaría como cliente de Bob. Si Bob espera que solo se conecten otros servidores autorizados, Bob verificará la validez del certificado, incluida la caducidad, en la CRL de los emisores y realizará una búsqueda inversa del nombre. Si Bob está esperando un cliente de usuario, la búsqueda inversa probablemente se omitirá o solo se utilizará para el registro.

Si Bob espera que Alice se conecte desde un host de confianza conocido, Bob esperará que la dirección IP de Alice coincida con el registro DNS. No le importa a Bob que Alice esté detrás de un proxy, y Bob solo verá la dirección IP del proxy. Por lo tanto, alice.in.wonderland.com debería configurarse en la dirección IP externa del proxy.

Sin embargo, la parte clave es esta:

1. Bob tendrá la clave pública de Alice ya asignada a una identificación de algún tipo que se usará para otorgar acceso a los recursos de Bob.
2. Bob y Alice se retarán entre sí enviándose un mensaje que cada uno solo pueda descifrar con su clave privada. De este modo, se demuestra que cuentan con el certificado conocido y de confianza para cada parte.

También tenga en cuenta: Si Alice está detrás de un proxy, el proxy debe tener la clave privada de Alice (para que el proxy pueda hablar con Bob en nombre de Alice) o debe pasar a través de la conexión de Alice sin alterar su contenidos.

Referencia adicional enlace o enlace para detalles técnicos específicos.

Espero que ayude.