Pregunta:
¿BEAST está realmente arreglado en todos los navegadores modernos?
Andrei Botalov
2012-08-11 03:43:25 UTC
view on stackexchange narkive permalink

Se dice que BEAST se corrige en todos los navegadores modernos:

También se corrigió en OpenSSL desde 2002.

¿Estas correcciones significan que es seguro usar cifrados en modo CBC en TLS 1.0 si el usuario final usa uno de estos navegadores modernos?

Tenga en cuenta que Safari no figura en la lista de "todos" los navegadores modernos. http://blog.ivanristic.com/2013/03/rc4-in-tls-is-broken-now-what.html
Dos respuestas:
D.W.
2012-08-12 08:11:01 UTC
view on stackexchange narkive permalink

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

BEAST aprovecha una debilidad de seguridad en TLS 1.0. La forma básica de cerrar toda la debilidad es actualizar tanto el navegador como el servidor a TLS 1.1 o TLS 1.2. Por el momento, Chrome admite TLS 1.1; IE9, IE10, Opera admiten TLS 1.1 y TLS 1.2 si configura una opción especial, pero el soporte no está habilitado de forma predeterminada; El cliente iOS 5 admite hasta TLS 1.2; Firefox y Safari no lo hacen. Desafortunadamente, ambos extremos deben admitir TLS 1.1 antes de que pueda establecer una conexión TLS 1.1 y, en la actualidad, pocos servidores admiten TLS 1.1 o TLS 1.2. Algunos servidores admiten 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 principio para el ataque BEAST no se implementa ampliamente en la actualidad, independientemente del navegador que use.

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

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

Puedo entender por qué pudo haber tenido la impresión de que sí. El primer ataque aprovechó esta debilidad utilizando WebSockets. Un ataque posterior también mostró cómo explotarlo usando Java. La mayoría de los navegadores modernos ahora han sido parcheados para cambiar el funcionamiento de WebSockets, de modo que WebSockets ya no se puede utilizar para explotar esta debilidad. Sin embargo, la debilidad subyacente sigue presente, y no creo que nadie se sorprendería mucho 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 BEAST: enviar 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 soporte para TLS 1.1, hay una advertencia importante. Activar TLS 1.1 o 1.2 causa problemas de compatibilidad con servidores defectuosos. 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, lo intentan nuevamente con TLS 1.0. Si TLS 1.0 falla, volverán a utilizar SSL 3.0. Esto introduce una vulnerabilidad: un intermediario puede obligar a ambas partes a recurrir a TLS 1.0.

¿Qué tiene de malo el esquema 1 / n-1 (que [está actualmente implementado] (http://www.imperialviolet.org/2012/01/15/beastfollowup.html) en todos los navegadores que implementaron la corrección)?
@AndreyBotalov, No sé de nada malo con ese esquema.
¿Por qué ha escrito "Esto no es perfecto, pero debería ayudar mucho"? Creo que los navegadores no implementarán esas medidas si no son perfectas
Acerca del párrafo que comienza con "Puedo entender por qué pudo haber tenido la impresión de que sí". No tengo esta impresión por esto. Las correcciones realizadas por los navegadores para resolver el problema de BEAST no se tratan de WebSockets, Java, etc. Quisiera eliminar este párrafo pero no sé si será apropiado
¡Gracias por tus ediciones, @AndreyBotalov! Son geniales. Buen trabajo.
Andrew Smith
2012-08-12 01:12:22 UTC
view on stackexchange narkive permalink

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 debe estar configurado para negociar desde AES y no desde RC_4, y también puede deshabilitar SSLv2 por completo.

¿Por qué no utilizar RC4? Se implementa de forma segura en los navegadores y se utiliza, por ejemplo, por Google
RC_4 es un cifrado de flujo, por lo que es fácil de atacar con hardware.
@AndrewSmith "_RC_4 es un cifrado de flujo, por lo que es fácil de atacar con hardware._" ¿Cómo es fácil? ¿Puede respaldar su estado de cuenta con datos publicados?
@curiousguy Creo que Andrew habla sobre [esas cosas] (http://crypto.stackexchange.com/questions/853/google-is-using-rc4-but-isnt-rc4-considered-unsafe)


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...