¿Por qué el ataque BEAST antes era considerado inverosímil?

El ataque requiere cooperación entre un componente externo (que puede interceptar el tráfico) y un componente interno que se ejecuta en la máquina atacada y puede inyectar datos arbitrarios (elegidos por el atacante) dentro del SSL túnel, junto con el dato que se va a descifrar. La opinión general de la mayoría de las personas en las comunidades de criptografía y seguridad es que cuando el atacante puede hacer eso, tiene el control suficiente sobre la máquina atacada y se puede considerar que ya tiene ya ganado . No obstante, se publicó una solución en TLS 1.1 (publicada en 2006) y versiones posteriores.

Sucede que con la Internet de 2011, puede haber una cantidad considerable de código hostil ejecutándose en el sistema del usuario, a través de Java y / o Javascript, y dicho código tiene un poder considerable sobre lo que sucede en dicho sistema. Este es el tipo de über-attacker que fue previsto y declarado como "no plausible en la práctica" en 2006. Tenga en cuenta que BEAST aún no está publicado, excepto en algunas diapositivas, por lo que aunque se ha ejecutado con éxito en condiciones de laboratorio, no está claro si Valdría la pena el esfuerzo de construirlo en la naturaleza. Después de todo, parece que nadie se molestó nunca en descifrar conexiones SSL de 40 bits de manera regular e industrial, a pesar de la facilidad computacional de hacerlo (que "nadie" trata de atacantes que buscan números de tarjetas de crédito y contraseñas de acceso bancario, no agencias gubernamentales de seguridad: si el servicio secreto de su país no descifra de forma rutinaria SSL de 40 bits, entonces tiene derecho a cuestionar qué diablos hacen con su dinero de los impuestos).

Una forma de verlo es que los investigadores de criptografía y seguridad, y / o los proveedores de navegadores web, no pudieron prever la evolución de la arquitectura web. Otra forma de verlo es que los proveedores de navegadores están trabajando arduamente en la construcción de una estructura web que, desde el punto de vista de la seguridad, esté condenada desde el principio.

Anteriormente, el ataque se consideraba posible en principio, pero no una amenaza seria en la práctica. Se creía que el ataque requeriría un texto tan claro y tan elegido que el ataque no era una amenaza práctica. Además, en la configuración web, no se conocía ninguna forma de que el navegador de la víctima cifrara el texto sin formato elegido con el nivel de control necesario (se sabía cómo hacerlo en una configuración de VPN, pero no para una víctima que está usando navegador web para navegar por la web). Por lo tanto, se creía que el ataque tenía una relevancia limitada en el mundo real.

Obviamente, esta creencia tenía algunos agujeros. Como escribe Bruce Schneier, "los ataques siempre mejoran". En otras palabras, solo porque hoy parece que un ataque requiere 2 ²⁰ Plaintexts seleccionados, no significa que siempre será así: la gente podría en el futuro descubrir formas de reducir la cantidad de texto simple elegido. .

Puedo simpatizar con un argumento que, en retrospectiva, la comunidad debería haber tomado el ataque más en serio. Dicho esto, la retrospectiva es de 20 a 20, por lo que no juzgaría a la comunidad con tanta dureza. En pocas palabras: estas cosas pasan. Nuestra comprensión crece con el tiempo.

La vulnerabilidad solo se consideraba teórica, por lo que todos los grandes proveedores de navegadores simplemente optaron por ignorarla. De todos modos, por lo que sé, el documento aún no se ha publicado, pero algunas personas en la comunidad de cripto parecen haber entendido el ataque.