Si estás hablando del ataque "sslstrip" de Moxie, es más un ataque orientado al usuario que un ataque técnico real a SSL. No rompe la criptografía subyacente o el modelo de confianza. (Tiene otra herramienta, sslsniff, que en realidad ataca algunas de las implementaciones técnicas de confianza y verificación de certificados).
En primer lugar, debería ver su presentación de Defcon en sslstrip, si aún no lo ha hecho: enlace . Si nada más, es una gran idea de cómo razonar las fallas de seguridad.
El origen de sslstrip se basó en una observación simple: la mayoría de los usuarios no llegan a los sitios SSL escribiendo directamente la URL o escribiendo una URL https: // marcada. La mayoría de los usuarios se conectan a un sitio que no es SSL y se redirigen (por ejemplo, la redirección HTTP 302), o se conectan a un sitio que no es SSL que tiene un enlace al sitio SSL y hacen clic en el enlace.
En cualquier caso, el sitio que no es SSL puede ser fácilmente manejable, y por lo tanto, la dirección URL a la que el usuario es redirigido puede ser modificada silenciosamente por un atacante. P.ej. su enlace a enlace se puede cambiar a enlace . Los usuarios finales aún ven un candado y un certificado válido, simplemente pasa a un certificado para www.badguy.com en lugar de bankofamerica.com. Moxie también mostró algunas otras cosas interesantes con Unicode en las URL y encontrando glifos que parecen barras diagonales para engañar aún más al usuario final, pero esas cosas ya se han corregido en la mayoría de los navegadores y son secundarias a la causa raíz del problema. / p>
Para responder a sus preguntas:
-
No hay certificados comprometidos en este ataque, por lo que la "fuerza" no importa en absoluto. Todos los certificados utilizados son completamente válidos en un sentido criptográfico.
-
No tiene que ser propietario del enrutador local. Puede utilizar un ataque de suplantación ARP para que su objetivo sea el hombre en el medio si está en la misma red que ellos.