Mitigación de BEAST en un equilibrador de carga Cisco ACE 4710

3

Estamos buscando mitigar BEAST (y similares) en nuestro dispositivo Cisco ACE (versión en ejecución A4 (2.0)), que es el "punto final" para un puñado de servicios de carga equilibrada. Algunos de estos servicios aún se ejecutan con certificados firmados por SHA1 (aunque estamos trabajando para que nuestros clientes realicen pruebas con certificados firmados por SHA2).

La ACE nos permite crear un parameter-map para priorizar los cifrados que admite (siendo la prioridad 10 la más preferida y 1 la menos preferida), pero no estoy completamente al tanto de las complejidades de cada conjunto de cifrado. .

¿Lo siguiente sería una mitigación razonable (priorizando esencialmente los cifrados basados en CBC más bajos, para preferir los cifrados que no son CBC)? ¿Hay alguna en esta lista que realmente no debería aceptar? Obviamente, nuestro objetivo es seguir siendo tan compatibles como sea razonablemente posible.

Tenga en cuenta que no estamos tratando de cumplir específicamente con el cumplimiento de PCI, solo estamos tratando de 'hacer lo correcto' (aunque si alguno de los puntos a continuación infringiría eso, sería útil saberlo en caso de que aparezca en el futuro)

parameter-map type ssl PMAP_SSL_CIPHERS
  cipher RSA_WITH_RC4_128_SHA            priority 6
  cipher RSA_WITH_RC4_128_MD5            priority 6
  cipher RSA_EXPORT1024_WITH_RC4_56_SHA  priority 6
  cipher RSA_EXPORT1024_WITH_RC4_56_MD5  priority 6
  cipher RSA_EXPORT_WITH_RC4_40_MD5      priority 6
  cipher RSA_WITH_AES_256_CBC_SHA        priority 2
  cipher RSA_WITH_AES_128_CBC_SHA        priority 2
  cipher RSA_WITH_3DES_EDE_CBC_SHA       priority 2
  cipher RSA_WITH_DES_CBC_SHA            priority 2
  cipher RSA_EXPORT1024_WITH_DES_CBC_SHA priority 2
  cipher RSA_EXPORT_WITH_DES40_CBC_SHA   priority 2
    
pregunta jimbobmcgee 11.04.2013 - 12:50
fuente

2 respuestas

3

La forma más sencilla de mitigar BEAST es no hacer nada . BEAST es un ataque de cliente . Los servidores pueden "proteger" a los clientes haciendo cumplir el uso de conjuntos de cifrado basados en RC4, incluso si el cliente declara que prefiere algunos conjuntos de cifrado CBC. Sin embargo, todas las versiones recientes de los navegadores web incluyen soluciones que los hacen inmunes a BEAST, es decir, 1 / n -1 división ; y el servidor nunca ha sido vulnerable para empezar.

Además, BEAST se basa en la capacidad de inyectar en el cliente un Javascript hostil que puede enviar solicitudes binarias arbitrarias a un host externo; esto requiere un agujero en la Política del mismo origen . Los dos agujeros que se usaron en la demostración original de BEAST se han reparado (uno usó un error en Java y el otro una versión de borrador de WebSockets).

Por lo tanto, si BEAST sigue siendo una preocupación para usted, entonces su navegador está totalmente desactualizado y tiene muchas otras vulnerabilidades más urgentes. Actualízalo lo antes posible. Como subproducto, solucionará cualquier preocupación relacionada con la BESTIA.

    
respondido por el Thomas Pornin 11.04.2013 - 14:10
fuente
2

Dado que:

  • los navegadores actuales (incluido IE6) tienen parches para solucionar BEAST,
  • es un ataque difícil de realizar de todos modos, y
  • ha habido progreso en atacar RC4 últimamente,

preferir RC4 como una medida para derrotar a BEAST parece de utilidad cuestionable. Ciertamente no es una victoria clara, y no debe ser representada como una medida de seguridad básica necesaria (como hacen algunos escáneres con falsedad, para darse algo de qué quejarse).

Sin embargo, definitivamente valdría la pena deshacerse de los cifrados EXPORT y los cifrados de un solo DES compatibles con FIPS. Ciertamente, preferir RSA_EXPORT_WITH_RC4_40_MD5 en lugar de RSA_WITH_AES_256_CBC_SHA no es del todo sensato.

    
respondido por el bobince 12.04.2013 - 10:40
fuente

Lea otras preguntas en las etiquetas