No veo más opciones para el protocolo SSL ...
SSL man en el medio todavía es fácil si algunos proveedores instalan certificados raíz de confianza adicionales en su sistema e incluyen la clave privada. Como ejemplo, vea Superfish y eDellRoot .
MITM también es posible si conoce la clave privada del sitio, ya que la misma clave se comparte con miles de otros dispositivos, consulte Nueve por ciento de los hosts HTTPS en la web" comparte las mismas claves privadas ".
Y, por supuesto, MITM es posible si CA emite certificados para dominios sin autorización, por lo general, lo hacen los cortafuegos internos de las sub-CA como se puede ver here y here .
Aparte de eso: las tecnologías para derrotar a sslstrip, etc. no solo tienen que estar disponibles, sino que deben utilizarse:
- Chrome no revisa correctamente la revocación del certificado porque solo verifican el certificado que consideran importante .
-
HSTS se implementa en todos los navegadores actuales (incluso IE11 lo obtuvo recientemente) pero no en todos los navegadores que están actualmente en uso.
- HSTS solo se usa para algunos sitios .
- HSTS no protege si el atacante logra obtener un certificado alternativo (ver arriba). Solo HPKP protege contra esto, pero esta función es no implementada por IE, Edge y Safari .
Como propietario de la red, quiero estar seguro de lo que pasa a través de mi puerta de enlace pero a través de los datos, es decir, no solo que IP: PORT se está conectando a través de 443 a este sitio HTTPS ...
Como propietario de la red, no necesita atacar a SSL, pero puede usar la intercepción SSL que ofrecen la mayoría de firewalls de nivel empresarial (e incluso el proxy de squid gratuito). Por supuesto, en este caso, la CA proxy necesaria debe instalarse en los clientes.