He recopilado los problemas que afectan a SSL 3.0 y he encontrado que
- son problemas de configuración (deshabilitar RC4, RC2, DES, anon, exportar, suites nulas, compresión, longitudes de clave adecuadas, etc.) o
- requiere un navegador donde el atacante pueda generar tráfico usando JavaScript.
Entonces, la pregunta es: ¿se puede atacar una conexión SSL 3.0 correctamente configurada si el cliente no es un navegador? (Piense en las MUA y en otros agentes como ese). ¿Hay ataques que puedan dirigirse a un cliente-servidor SSL 3.0 correctamente configurado que no sería posible si lo único que cambiaría fuera el protocolo a una versión más reciente?
Tengo las siguientes teorías sobre posibles ataques:
- INCUMPLIMIENTO, CRIMEN: ambos se basan en el efecto de la compresión del texto simple conocido suministrado por el atacante, por lo que no se puede explotar si el atacante no puede iniciar solicitudes en el contexto del cliente SSL víctima
- POODLE: puede forzar el retroceso a SSL 3.0, pero en este caso, SSL 3.0 se usa en sí mismo, por lo que el ataque es irrelevante (ver otros ataques)
- BEAST, Lucky13: ambos se basan en oráculos criptográficos (basados en el tiempo o en la respuesta) que son explotables solo si el atacante puede iniciar solicitudes en el contexto del cliente SSL víctima, lo cual no es el caso en mi escenario anterior
- Ataques RC4: mitigados al deshabilitar RC4, dejando a conjuntos de cifrados 3DES-CBC como las únicas opciones (AES aún no estaba incluido en SSL 3.0, desde su lanzamiento en 1996)
- FREAK, LOGJAM: se mitiga mediante el cumplimiento de longitudes de clave sanas (> 1024 bit) en el cliente y el servidor
En resumen, mi cliente y mi servidor están configurados de manera que las claves tienen una longitud razonable, y el único conjunto de cifrado habilitado es SSL_RSA_WITH_3DES_EDE_CBC_SHA .
Consulte también discusión anterior sobre / r / crypto