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?
fuente
Respuestas:
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):MS dice que Windows XP admite TLS_RSA_WITH_RC4_128_SHA, por lo que no debería tener ningún problema de compatibilidad.
fuente
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í
aptyyumtodaví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.
fuente
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:
Asegúrese de no tener ninguna de estas configuraciones publicadas dos veces en el archivo ssl.conf.
Ahora mis sitios pasan con una A.
fuente