Recientemente, hemos comprobado si una autenticación SSL mutua basada en un certificado protege contra un ataque de Poodle sobre SSLv3.
Estamos atrapados en una situación en la que una aplicación cliente solo admite SSLv3 para obtener nuestros servicios web basados en SOAP. Obviamente, queremos desactivar SSLv3 en el lado del servidor, pero la aplicación cliente no podrá conectarse.
Entonces, ¿el uso de la autenticación SSL mutua proporciona alguna mitigación para prevenir un ataque de Poodle?
Estrictamente hablando, no, la autenticación mutua no protege contra POODLE. Sin embargo, algunos detalles pueden importar.
El núcleo del ataque POODLE es que hay una forma, con SSL 3.0, de alterar algunos registros para que el extremo receptor no note la sustitución con probabilidad 1/256. Con este protocolo, los atacantes pueden "probar" las suposiciones de descifrado en un solo byte de datos encriptados, y aprenderán ese byte con probabilidad 1/256. Sin embargo, si falla, el extremo receptor se da cuenta del problema y se interrumpe la conexión. El punto importante aquí es que nada de esto se ve afectado de ninguna manera por los detalles del apretón de manos; la autenticación del cliente basada en certificados no hace que desaparezca el problema del protocolo.
La descripción clásica de POODLE, basada en la web, aplica ese problema en un contexto web, es decir:
En ese contexto, POODLE recupera la cookie de destino con un promedio de 128 conexiones por byte adivinado (ese número puede reducirse un poco suponiendo que los bytes de la cookie son caracteres ASCII imprimibles).
En su caso, la aplicación cliente probablemente no sea un navegador web y, como tal, puede ser difícil para los atacantes disparar conexiones repetidas. Además, si realiza una autenticación mutua con certificados, es posible que no tenga cookies de sesión grandes y gruesas, eliminando así un objetivo jugoso. Sin embargo, los atacantes aún pueden probar suerte y adivinar algunos bytes, si aceptan romper la mayoría de las conexiones en las que intentan adivinar. El hecho de que los atacantes puedan lograrlo de manera discreta realmente depende de cómo se comporta la aplicación cuando se rompen las conexiones. En particular , si se realiza HTTP "keep-alive" (como es habitual para SOAP-over-HTTP-over-SSL), entonces el cliente espera algunas solicitudes fallarán (porque el servidor perdió la paciencia y cerró la conexión) y reiniciarlos en silencio, por lo que es probable que los atacantes puedan hacer sus suposiciones en silencio.
Se debe tener en cuenta que POODLE se trata de una infracción de confidencialidad , no de una integridad . Si usa SSL solo para que los datos se autentiquen, pero sin enviar nada en realidad secreto a través del túnel SSL, entonces POODLE deja de ser una preocupación.
Resumen: lo que proporciona mitigación para POODLE no es el certificado del cliente; Lo que puede proporcionar mitigación es que el cliente no es un navegador web. Sin embargo, la vulnerabilidad del protocolo todavía está allí y aún puede ser explotable, dependiendo de los detalles de su protocolo de aplicación.
Debería realmente pensar en actualizar estas aplicaciones cliente. Al mantener activo SSL 3.0, está buscando problemas.
Lea otras preguntas en las etiquetas tls known-vulnerabilities