Solución:
Supongo que el modelo de amenaza es que puede haber un atacante intermediario entre Alice y Bob, y que Alice y Bob no están en la misma subred de confianza. Eso es lo que SSL / TLS está diseñado para proteger, y es por eso que Alice debería verificar el certificado de Bob en su ejemplo (al menos).
Desde el punto de vista de Bob, comprobar que la solicitud de Alice proviene de una dirección IP conocida no es de mucha utilidad. Los atacantes podrían falsificar y alterar paquetes para que parezca 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 falsificar los paquetes para usar una dirección IP con la entrada de DNS correcta.
Cuando Bob solicita un certificado de cliente de 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 apretón de manos se haya completado con éxito, Bob sabrá que Alice tiene la clave privada para ese certificado y tendrá que verificar que confía en este certificado.
Si la solicitud proviene de detrás de un proxy o no, no importa cuando usa SSL / TLS. Un proxy HTTP simplemente tuneliza la conexión SSL / TLS desde el cliente original al servidor de destino.
Lo que le importa a Bob es cómo va a verificar el certificado de Alice. Normalmente, esto se hará utilizando una PKI de la misma manera que Alice verificó el certificado de Bob, aunque no es necesario que sea la misma CA que la de Bob (debe ser algo en lo que Bob confíe). Tenga en cuenta que esto tampoco necesita usar una PKI. Es posible verificar el certificado con una lista determinada (si Alice y Bob se han conocido 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, que está permitido explícitamente por TLS 1.1, pero no especificado de ninguna manera en versiones anteriores, consulte el mensaje de solicitud de certificado) y use 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, servidores proxy que están configurados para falsificar el servidor SSL / TLS real insertando su propio certificado (ver SSL Bump de Squid). En este caso, el certificado que Alice ve no vendría de Diginotar, sino de otra CA (normalmente una CA corporativa cuando esto 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 hay un MITM y que la conexión fallaría. Esto se debe a que se supone que Alice debe firmar todo el apretón de manos SSL / TLS (como lo ven Alice y Bob) en su CertificateVerify mensaje para autenticarse 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.
Dependería de la implementación específica.
En general, Alice actuaría como cliente de Bob. Si Bob espera que solo otros servidores autorizados se conecten, Bob verificaría la validez del certificado, incluida la expiración, con la CRL del emisor y realizaría una búsqueda inversa con el nombre. Si Bob espera un cliente de usuario, la búsqueda inversa probablemente se omitirá o solo se usará para el registro.
Si Bob espera que Alice se esté conectando desde un host de confianza conocido, Bob esperaría que la dirección IP de Alice coincida con el registro DNS. A Bob no le importa que Alice esté detrás de un proxy, y Bob solo verá la dirección IP del proxy. Entonces alice.in.wonderland.com debería configurarse con la dirección IP externa del proxy.
Sin embargo, la parte clave es esta:
- Bob tendrá la clave pública de Alice ya asignada a un ID de algún tipo que se utilizará para otorgar acceso a los recursos de Bob.
- Bob y Alice se desafiarán mutuamente enviándose un mensaje que cada uno solo puede descifrar con su clave privada. Demostrando así que tienen el certificado que es conocido y de confianza por cada lado.
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 contenido.
Referencia adicional http://en.wikipedia.org/wiki/Transport_Layer_Security o http://tools.ietf.org/html/rfc5246 para detalles técnicos específicos.
Espero que ayude.
No exactamente. Una vez que se completa el protocolo de enlace 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 podría tener una lista blanca de clientes a los que se les permite conectarse. Entonces Bob miraría hacia arriba
alice.in.wonderland.comen esta lista. (Bob, alternativamente, podría tener una lista blanca de claves públicas, pero los certificados de cliente podrían facilitar la administración de Bob, porque ahora puede ingresar valores legibles para humanos en su lista blanca). -
Bob podría tratar
alice.in.wonderland.comcomo nombre de usuario de Alice e inicie 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 e iniciar sesión automáticamente 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 ( suponiendo que no exista uno). 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.
Nuevamente, 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 única respuesta.