Una forma de mitigar BEAST es no hacer nada . Sucede que aunque la vulnerabilidad utilizada en BEAST todavía está ahí, explotarla es bastante difícil. Requiere la capacidad de realizar solicitudes de dominios cruzados, con un alto nivel de control sobre los datos que se envían en la solicitud; en particular, necesita datos "binarios". Duong y Rizzo no encontraron una manera de mapear el ataque en etiquetas sencillas <img> (Javascript hostil que produce tales etiquetas, con una ruta elegida por el atacante: la ruta entra en la solicitud, pero es solo de texto). En su demostración, podrían usar dos agujeros de dominios cruzados, uno en una versión de borrador de WebSockets, y el otro en la implementación de Java desde Oracle. Desde entonces, ambos agujeros se han arreglado, por lo que ahora mismo, BEAST ya no se aplica (a menos que no haya actualizado su navegador durante más de un año, en cuyo caso es probable que tenga más problemas).
Dado que confiar en la no existencia de vulnerabilidades entre dominios es, en el mejor de los casos, endeble, los proveedores de navegadores también han incluido algunas contramedidas adicionales, con división de registros . Cuando el navegador desea enviar un bloque de n bytes de datos, en lugar de ponerlo en un registro SSL, lo divide en dos , el primero es muy pequeño. Los límites de registro no tienen importancia semántica en SSL / TLS, por lo que puede hacer dicha división sin cambiar el significado. Sin embargo, cada registro termina con un MAC calculado sobre los datos del registro y un número de secuencia , y utilizando una clave derivada del intercambio de claves inicial. Esto de alguna manera actúa como un generador de números pseudoaleatorios. Por lo tanto, el pequeño registro "emula" la generación IV aleatoria que hace que TLS 1.1+ sea inmune a BEAST.
Idealmente, la división sería 0 / n : un registro sin datos (pero aún con un MAC), seguido de un registro con los datos reales. Se permiten registros de longitud cero (según el estándar ) pero las implementaciones de servidor y cliente con errores no los toleran (en particular, IE 6.0); en su lugar, los navegadores utilizan una división 1 / n-1 , que es igual de buena para vencer a BEAST, pero también funciona con casi todos los clientes y servidores SSL / TLS existentes. Al menos Chrome y Firefox lo han empujado el año pasado .
La buena solución es TLS 1.1+ pero incluso en SSL 3.0 y TLS 1.0, el problema de BEAST puede considerarse como solucionado, al menos en el contexto web. Por lo tanto, usa AES y sé feliz.