Resumen

  • Algunos clientes respondían a un handshake fallido reintentando con versiones cada vez más antiguas. Quien podía interrumpir el primer intento adquiría influencia sobre la siguiente oferta de seguridad.
  • La recuperación de texto en POODLE exigía además SSL 3.0 con CBC, un adversario activo, peticiones repetidas que transportaran el secreto y modificación de registros; el trabajo esperado era de 256 peticiones por byte.
  • TLS_FALLBACK_SCSV declaraba que el ClientHello reducido era un reintento. El servidor podía compararlo con su mayor versión habilitada y rechazar localmente un repliegue innecesario.

La negociación normal ya resolvía diferencias de versión. Un cliente capaz de TLS 1.2 podía anunciarlo y aceptar que un servidor respondiera con TLS 1.0. El acuerdo quedaba protegido por el handshake. El problema nació en una ruta lateral creada para servidores y middleboxes que no toleraban mensajes modernos.

En esa ruta, el cliente interpretaba el silencio o el error como si fuera información auténtica sobre el servidor. Bajaba el máximo anunciado y volvía a conectar. Un atacante en tránsito no necesitaba quebrar TLS 1.2: bastaba con impedir que terminara. El propio cliente recorría la escalera hasta SSL 3.0.

La degradación no revelaba por sí sola el contenido. El segundo mecanismo estaba en CBC. SSL 3.0 permitía bytes de relleno no cubiertos de forma determinista por el MAC. El informe original construyó un ataque Web en el que el adversario inducía al navegador a enviar peticiones HTTPS con una cookie, colocaba un byte desconocido al final de un bloque y sustituía el último bloque cifrado. La aceptación del registro modificado aparecía, en promedio, una vez cada 256 intentos y revelaba un byte.

Por eso, 256 no es una velocidad universal. Es una expectativa bajo condiciones concretas. Hacían falta posición de intermediario, control sobre la forma de las peticiones, una sesión SSL 3.0 CBC y capacidad de repetir. Tampoco todos los clientes ejecutaban el repliegue ni todos los servidores aceptaban esa combinación.

La mitigación inmediata más limpia era retirar SSL 3.0. Cuando una dependencia heredada impedía hacerlo de golpe, había que distinguir un servidor realmente antiguo de una caída fabricada.

La señal {0x56,0x00}, llamada TLS_FALLBACK_SCSV, resolvía esa pregunta acotada. Aunque viajaba en la lista de suites, no representaba ningún sistema criptográfico y el servidor no podía seleccionarla. Indicaba que el cliente ofrecía una versión inferior durante un reintento. Si el servidor tenía habilitada una versión superior, debía cerrar con inappropriate_fallback(86).

La decisión quedaba distribuida. El cliente declaraba el contexto y el servidor aplicaba una comparación local. No necesitaban una autoridad que decidiera si había ataque. De hecho, RFC 7507 advierte que un fallo normal de red también puede producir la alerta. SCSV demostraba un repliegue impropio respecto de las capacidades observadas, no la intención de un atacante.

También era una pieza provisional. OpenSSL incorporó soporte en 1.0.1j, 1.0.0o y 0.9.8zc. RFC 7568 prohibió después SSL 3.0. Años más tarde, RFC 8996 retiró TLS 1.0 y 1.1 y declaró obsoleto RFC 7507 porque TLS 1.3 integraba otra defensa mediante valores centinela en ServerHello.Random.

El buen diseño no conserva toda compatibilidad. La convierte en una excepción explícita, medible y eliminable.