¿TLS_FALLBACK_SCSV será la solución para los servidores que deseen mantener SSLv3 habilitado? Si no, ¿qué acciones se están tomando, si las hay, que abordan la vulnerabilidad además de deshabilitar SSLv3?
El protocolo SSLv3 es defectuoso. Esto no puede ser arreglado. En general, un atacante explotaría esto al obligar a la víctima a conectarse a un servidor mediante SSLv3 al forzar las conexiones que usan protocolos más altos a fallar. TLS_FALLBACK_SCSV intenta detener el navegador / servidor para que no vuelva a SSLv3 si ya se ha intentado un protocolo superior.
Como puede ver, TLS_FALLBACK_SCSV no soluciona realmente el problema del protocolo, sino que trata de reducir la superficie de ataque haciendo más difícil que el atacante obligue a la víctima a degradar el protocolo.
TLS_FALLBACK_SCSV no tendrá ningún efecto si el navegador o el servidor no admiten nada más alto que SSLv3 (lo cual es raro, te concedo, pero no imposible).
Ha habido algunas discusiones sobre cómo mitigar los problemas con algunas divisiones de registros. Es decir, lo que hace que Poodle sea eficiente es que el relleno puede usar hasta un bloque completo (8 bytes con 3DES o RC2, 16 bytes con AES). Cuando esto sucede, el destinatario solo comprueba el último byte del bloqueo, por lo que la alteración del atacante logra la probabilidad de 1/256. Por lo tanto, si puede hacer que esa situación de relleno nunca ocurra, puede reducir la probabilidad de éxito del atacante.
La idea es entonces, cuando un registro se va a cifrar y daría lugar a un bloque final con demasiado relleno aleatorio y muy pocos bytes no ignorados, para dividir los datos en dos registros, cuyas longitudes individuales inducirán los últimos bloques con suficientes bytes de relleno ignorados.
Este "arreglo" se discute allí (ver en particular el comentario 13). El éxito del atacante cae de 1/256 a 1/281474976710656. Sin embargo, esto solo se aplica a Poodle como se describió; y se sabe que la división de registros, aunque es "legal" desde el punto de vista estándar, puede romper implementaciones antiguas, con errores y heredadas.
TLS_FALLBACK_SCSV no corrige SSL 3.0; Corrige los ataques de degradación del protocolo. Asegura que si el cliente y el servidor conocen TLS 1.0+, no estarán obligados a usar SSL 3.0. Sin embargo, si el cliente o el servidor solo conocen SSL 3.0, entonces la comunicación usará SSL 3.0, y pueden aplicarse los ataques de Poodle. Esto es inevitable: si el servidor solo conoce SSL 3.0, la opción es entre usar un protocolo vulnerable a Poodle o no comunicarse en absoluto.
Varias personas han expresado que preferirían esto último. En lugar de tolerar SSL 3.0 con TLS_FALLBACK_SCSV o alguna división de registros, simplemente déjelo morir. Tendrá que suceder en algún momento; la preocupación general provocada por una vulnerabilidad puede ser una buena ocasión para ello.
Lea otras preguntas en las etiquetas attacks encryption tls protocols cipher-selection