El siguiente parche de Microsoft Patch Tuesday incluye la corrección BEAST SSL

4

enlace

Pensé que la vulnerabilidad que usa BEAST ya está solucionada en el lado "Microsoft", ¿no? ¿Alguien puede aclarar esto ?:

enlace

  

El soporte TLS para los navegadores en este momento es:

     
  • IE9 TLS 1.0, 1.1, 1.2, todos compatibles a través de Schannel
  •   
  • IE8 TLS 1.0 es compatible de forma predeterminada, 1.1 y 1.2 se pueden configurar
  •   
  • Opera - 10.x admite TLS 1.0, 1.1, 1.2
  •   

No cuento las versiones anteriores de ninguno de estos navegadores, ya que la gente realmente   debería tener actualización automática en. Si no lo hacen, probablemente tienen más grande.   problemas ( enlace )

     
  • Mozilla / Firefox - solo TLS 1.0
  •   
  • Chrome: solo TLS 1.0 (aunque se rumorea una actualización)
  •   
  • Safari - TLS 1.0
  •   
  • Teléfonos celulares: varios niveles de soporte (el kit de web tiene tls 1.2 desde noviembre de 2010, pero para   implementaciones de navegador de teléfono individuales su kilometraje puede variar)
  •   
    
pregunta LanceBaynes 08.01.2012 - 07:38
fuente

2 respuestas

4

Sin saber el funcionamiento interno del parche, solo puedo adivinarlo, pero ...

Tanto IE como IIS admiten versiones de TLS que no son vulnerables a BEAST, por ejemplo. TLS 1.1 y 1.2, pero estas versiones no están activadas de forma predeterminada. Además, depende de la suite de cifrado utilizada en la conexión para 1.0. El parche podría hacer varias cosas, como activar las versiones de forma predeterminada, o deshabilitar el conjunto de cifrado en particular que es vulnerable a BEAST.

    
respondido por el Steve 08.01.2012 - 08:17
fuente
6

Dado que el parche se ha lanzado hace algún tiempo, ahora podemos tener más información. El boletín de seguridad carece de información técnica, pero algunas pistas se pueden obtener de la lectura el artículo de KB sobre problemas conocidos . El parche hace, básicamente, dos cosas:

  1. El parche activa la compatibilidad con TLS 1.1 . Este soporte ya estaba incluido en Internet Explorer, pero no estaba habilitado de forma predeterminada, porque había algunos servidores con errores que no lo toleraban (en un protocolo de enlace SSL / TLS, el cliente anuncia su versión máxima admitida, pero algunas implementaciones del servidor se niegan a hablar) clientes que anuncian algo más que SSL 3.0 o TLS 1.0). Microsoft parece haber decidido que reparar BEAST era más importante que soportar servidores SSL defectuosos.

  2. El parche implementa división de registros . En SSL / TLS , los datos se codifican como registros, cada registro se cifra por sí solo. El defecto relacionado con BEAST es sobre los registros en SSL 3.0 y TLS 1.0 con cifrado CBC, donde el IV se extrae del final del registro anterior, por lo tanto predecible por un atacante espiando en la línea. División de registros se trata de dividir automáticamente los registros de n en dos registros, el primero es muy pequeño; esto tiene principalmente el mismo efecto neto que la elección de un IV aleatorio para cada registro (que es lo que hace TLS 1.1+), y esto corrige BEAST, con una sobrecarga de tamaño pequeño (no mucha). Una división 0 / n sería ideal (es decir, prefijar cada registro de datos con un registro vacío) pero tiende a romper demasiadas implementaciones existentes, en particular la de Internet Explorer 6.0; por lo tanto, a menudo se emplea una división 1 / n-1 , y casi tan buena. Esto es probablemente lo que aplica el parche de Microsoft.

La división de registros se utiliza cuando el servidor elige SSL 3.0 o TLS 1.0, y un conjunto de cifrado basado en CBC.

Tenga en cuenta que la aplicación práctica de BEAST también requiere una forma bastante flexible de hacer solicitudes entre sitios, algo que los diseñadores de BEAST (Duong y Rizzo) solo pudieron lograr al explotar una de las dos debilidades, que estaban en Javascript WebSockets (versión borrador) ) y en Java (implementación de Sun / Oracle), respectivamente; Ambas debilidades también fueron arregladas. El parche de Microsoft que estamos discutiendo aquí aborda la vulnerabilidad subyacente del cifrado CBC con IV predecible.

    
respondido por el Thomas Pornin 04.12.2012 - 04:02
fuente

Lea otras preguntas en las etiquetas