Reparando la vulnerabilidad de BEAST en Apache 2.0 que se ejecuta en RHEL 4

11

Tengo un servidor web que ejecuta Apache 2.0 en RHEL4. Este servidor recientemente falló un escaneo PCI.

Motivo: Protocolo SSLv3.0 / TLSv1.0 Solución de vulnerabilidad de modo CBC débil: Este ataque se identificó en 2004 y posteriores revisiones del protocolo TLS que contienen una solución para esto. Si es posible, actualice a TLSv1.1 o TLSv1.2. Si no es posible actualizar a TLSv1.1 o TLSv1.2, deshabilitar los cifrados en modo CBC eliminará la vulnerabilidad. El uso de la siguiente configuración SSL en Apache mitiga esta vulnerabilidad: SSLHonorCipherOrder en SSLCipherSuite RC4-SHA: HIGH:! ADH

Solución simple, pensé. Agregué las líneas a la configuración de Apache y no funcionó. Aparentemente,
"SSLHonorCipherOrder On" solo funcionará en Apache 2.2 y versiones posteriores. Intenté actualizar Apache, pronto encontré un infierno de dependencia y parece que tendré que actualizar todo el sistema operativo para actualizar a Apache 2.2. Retiraremos este servidor en unos meses, por lo que no vale la pena.

La solución dice "Si no es posible actualizar a TLSv1.1 o TLSv1.2, deshabilitar los cifrados en modo CBC eliminará la vulnerabilidad".

¿Cómo haría esto en Apache 2.0? ¿Es esto posible? Si no, ¿hay alguna otra solución?

apache-2.2 ssl tls

— Debianuser
fuente

3

Dado que el soporte de actualización extendida para RHEL4 (.7) terminó hace un año, sugiero que tal vez retire el servidor lo antes posible. De lo contrario, probablemente necesitará compilar Apache 2.2 desde la fuente.

— DerfK

El nuevo servidor está listo, pero no podemos migrar hasta diciembre. Sí, compilar e instalar Apache 2.2 desde las fuentes es la última opción por ahora. ¿Se preguntaba si hay una solución más fácil?

— Debianuser

11

Además de compilar un Apache más nuevo a mano, lo único en lo que puedo pensar sería en hacer que RC4-SHA sea el único cifrado compatible (probado con openssl ciphers RC4-SHAel openssl actual para asegurarse de que solo imprima un cifrado, es posible que desee hacer lo mismo para asegurarse de que no coincida con alguna cifra antigua extraña en su antiguo openssl):

SSLCipherSuite RC4-SHA

MS dice que Windows XP admite TLS_RSA_WITH_RC4_128_SHA, por lo que no debería tener ningún problema de compatibilidad.

— DerfK
fuente

1

Exactamente lo que estaba buscando. Probé con éxito usando beast-check.googlecode.com/files/beast.pl . Programaré un escaneo PCI y le haré saber una vez que esté hecho.

— Debianuser

Puedo confirmar que esto funcionó. El servidor pasó un escaneo PCI. Muchas gracias.

— Debianuser

6

Solo hay dos formas de "arreglar" BEAST a nivel de servidor.

La mejor opción es actualizar la biblioteca SSL de su servidor a una que admita TLS v1.1 o posterior (y asegúrese de que sus clientes también la admitan, para que pueda obligarlos a usarla).

La otra opción es deshabilitar cualquier algoritmo de cifrado CBC (Cypher-Block-Chaining) y cambiar a un cifrador ECB (Libro de códigos electrónicos) o algo así como RC4 (los algoritmos ECB son teóricamente "menos seguros" porque una entrada de texto sin formato cifrada en un determinado La tecla siempre se asigna de nuevo al mismo texto cifrado, lo que hace que sea más fácil romper con los ataques de texto sin formato conocidos, pero en términos prácticos, es probable que esto no sea un gran problema. Google (como ejemplo) todavía usa RC4).

Dado que el servidor que está ejecutando está muerto, enterrado, y la descomposición probablemente no valga la pena el esfuerzo que requeriría construir un Apache parcheado (necesitará reconstruir Apache y OpenSSL de forma aislada, para no alterar nada que requiere la versión de OpenSSL instalada en su sistema de forma predeterminada: si está haciendo tanto trabajo, también puede actualizar todo el sistema a algo que sea realmente compatible), de modo que prácticamente lo deje con "Cambiar a Cyphers ECB" como Su solución viable.

BEAST no es realmente un ataque de hamburguesas en estos días: todos los navegadores populares (IE, Chrome, Safari, Opera) han implementado una solución efectiva , y debido a la forma en que funciona el ataque , es bastante difícil de implementar fuera de un navegador (así apty yumtodavía son bastante seguros).

Adam Langley, de Google, dio una excelente charla a principios de este año que describe algunos de los puntos débiles en los que debería concentrarse en re: SSL y seguridad.

— voretaq7
fuente

RC4 no es un cifrado en modo ECB. Usar el modo ECB sería un gran error, y hay buenas razones por las que TLS no tiene conjuntos de cifrado ECB compatibles. Usar un cifrado de flujo como RC4 es una idea mucho menos mala, aunque los resultados recientes significan que se ve menos bien de lo que era isg.rhul.ac.uk/tls

— armb

4

La única solución que he encontrado que le permitirá pasar la prueba ssllabs.com es agregar las siguientes cuatro líneas a su httpd.conf de apache y sus archivos ssl.conf:

SSLHonorCipherOrder On

SSLProtocol -todos + TLSv1 + SSLv3

SSLCipherSuite RC4-SHA: HIGH:! MD5:! ANULL:! EDH:! ADH

SSLInsecureRenegociación desactivada

Asegúrese de no tener ninguna de estas configuraciones publicadas dos veces en el archivo ssl.conf.

Ahora mis sitios pasan con una A.

— usuario2183769
fuente