Se recomienda, para mitigar POODLE, si SSLv3 no se puede desactivar por completo, para utilizar TLS_FALLBACK_SCSV, un valor de conjunto de cifrado de señalización que indica que se ha producido un repliegue. El borrador de la norma para él dice:
Si TLS_FALLBACK_SCSV aparece en ClientHello.cipher_suites y el La versión de protocolo más alta admitida por el servidor es más alta que La versión indicada en ClientHello.client_version, el servidor. DEBE responder con una alerta de caída inadecuada.
La idea, como la entiendo, es que si el cliente ha intentado y fracasado en la negociación de una conexión con, por ejemplo, TLS 1.2 (posiblemente porque un MITM ha forzado esta situación en un ataque de degradación de protocolo), el servidor será capaz de detectar la situación porque este valor de señalización estará presente en la lista de conjuntos de cifrado.
No estoy muy familiarizado con la negociación de TLS, y no entiendo por qué no sería posible que el atacante también manipule la lista de conjuntos de cifrado para eliminar este valor de señalización.
Por ejemplo, el cliente intenta conectarse al servidor con TLS 1.1, pero Mallory el MITM intercepta y falsifica una falla. Y lo hace de nuevo cuando el cliente intenta conectarse con TLS 1.0. Cuando el cliente intenta conectarse con SSL 3.0, Mallory elimina TLS_FALLBACK_SCSV de las suites de cifrado, pasa la solicitud al servidor y luego devuelve la respuesta del servidor, lo que permite que la conexión se negocie sin que el servidor vea el indicador FALLBACK.
¿Qué características de TLS previenen tal ataque? ¿La lista de suites de cifrado está cifrada de alguna manera, incluso antes de que se haya negociado la sesión?