¿BEAST realmente se corrige en todos los navegadores modernos?

No creo que nadie sepa de ninguna forma de explotar BEAST, en ninguno de esos navegadores modernos, por lo que, por lo que sabemos, esos navegadores son probablemente bastante seguros contra ataques similares a los de la BESTIA. Por otro lado, la debilidad subyacente todavía está presente, lo que deja cierto margen de preocupación sobre la posibilidad de que alguien pueda encontrar una nueva forma de explotar esa debilidad.

BEAST explota una debilidad de seguridad en TLS 1.0. La forma de principio para cerrar toda la debilidad es actualizar tanto el navegador como el servidor a TLS 1.1 o TLS 1.2. Por el momento, Chrome soporta TLS 1.1; IE9, IE10, Opera son compatibles con TLS 1.1 y TLS 1.2 si configura una opción especial, pero la compatibilidad no está habilitada de forma predeterminada; El cliente iOS 5 soporta hasta TLS 1.2; Firefox y Safari no lo hacen. Desafortunadamente, ambos puntos finales tienen que admitir TLS 1.1 antes de poder establecer una conexión TLS 1.1, y hoy en día, pocos servidores admiten TLS 1.1 o TLS 1.2. Algunos servidores son compatibles con TLS 1.2 (por ejemplo, Apache con mod_gnutls; IIS 7 si habilita algunas claves de registro especiales; servidores de aplicaciones Java en Java 7), pero solo unos pocos. Esto significa que será extremadamente raro que alguien pueda usar TLS 1.1 o TLS 1.2 hoy. Por lo tanto, la solución de principios para el ataque BEAST no se implementa ampliamente hoy en día, independientemente del navegador que utilice.

Para obtener más detalles, consulte, por ejemplo, Vulnerabilidad de inyección de JavaScript de TLS 1.0 (BEAST): ¿qué hacer en el lado del cliente? ; Impacto en la seguridad del ataque "BEAST" de Rizzo / Duong CBC ; y ¿Qué puedo hacer con respecto a la vulnerabilidad de inyección de javascript TLS 1.0 en mi servidor? ; ¿Cómo uso OpenSSL para probar el ataque BEAST? ; ¿Por qué el ataque BEAST antes se consideraba improbable? .

Dicho esto, varios servidores han implementado algunas soluciones que ayudan a mitigar las formas conocidas de explotar esta debilidad en TLS 1.0. Estas soluciones son un "recurso provisional" que no hace desaparecer la debilidad, pero sí evitan todas las formas conocidas de explotar la debilidad. La mitigación principal es garantizar que ambas partes utilicen RC4, en lugar de cualquier modo de operación basado en cifrado de bloque. Los servidores pueden arreglar esto cambiando el orden de sus conjuntos de claves. Puede probar si su servidor está configurado de una manera que impida que BEAST use este comprobador de SSL .

Puedo entender por qué podrías haber tenido la impresión de haberlo hecho. El primer ataque explotó esta debilidad usando WebSockets. Un ataque posterior mostró cómo explotarlo usando Java, también. La mayoría de los navegadores modernos ahora han sido parcheados para cambiar la forma en que funciona WebSockets, por lo que ya no se puede usar WebSockets para explotar esta debilidad. Sin embargo, la debilidad subyacente todavía está presente, y no creo que nadie se sorprendería terriblemente si mañana alguien descubriera una nueva forma de explotar la debilidad sin usar WebSockets o Java.

Firefox, Chrome, Opera, IE también implementó la siguiente mitigación para la vulnerabilidad de BEAST: envíe solo un byte de datos de la aplicación en el primer registro (también conocido como división de registros 1 / n-1 para CBC). Esto no es perfecto, pero debería ayudar mucho. A largo plazo, la solución correcta es mover a todos a TLS 1.2, pero eso llevará tiempo.

Otra nota al pie: aunque muchos navegadores están comenzando a implementar el soporte para TLS 1.1, hay una advertencia importante. Simplemente activando TLS 1.1 o 1.2 se producen problemas de compatibilidad con servidores con errores. Esos servidores fallan si un cliente indica que admite las versiones más recientes de TLS. Por lo tanto, los navegadores prueban TLS 1.1, pero si eso falla, intentan nuevamente utilizando TLS 1.0. Si TLS 1.0 falla, volverán a SSL 3.0. Esto introduce una vulnerabilidad: un hombre en el medio puede obligar a ambos lados a retroceder a TLS 1.0 .

Se solucionó recientemente, por lo que la mayoría de los navegadores que ahora están en actualización automática están bien, y el servidor debería configurarse para negociar desde AES y no RC_4, y también puede desactivar SSLv2 por completo.