¿Cómo mitigar la vulnerabilidad de divulgación de información en la implementación del vector de inicialización del protocolo SSL / TLS?

8

Descargo de responsabilidad: no soy un administrador de sistemas, intenta dar tus respuestas en un lenguaje amigable para el desarrollador;)

Estoy probando una nueva imagen de VPS con Nessus y obtengo el complemento 58751 . Intenté averiguar qué hacer y probé con diferentes configuraciones de SSLCipherSuite en Apache ssl.conf , pero sigo obteniendo.

La imagen aún no incluye openssl 1.0.1, por lo que no es compatible con TLS 1.2.

¿Cuáles son los ajustes de trabajo recomendados? ¿O qué estoy haciendo mal?

Por favor, sugiera valores posibles para ese parámetro de configuración específico de mod_ssl, como:

SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

Lo que no es bueno, entiendo.

    
pregunta markus-tharkun 25.05.2012 - 16:07
fuente

2 respuestas

11

¿Qué significa esta tontería todo? ¿Qué puedo hacer ante la vulnerabilidad de inyección de javascript TLS 1.0 en mi servidor?

¿A qué debo cambiar? ¿Debo ignorar la vulnerabilidad de BEAST SSL y seguir prefiriendo AES?

Una mirada en profundidad a las diferentes selecciones de cifrado y su impacto: ¿Qué sistemas de cifrado debo usar en mi servidor web después de configurar? ¿mi certificado SSL?

La cadena de cifrado

Tomemos esa información e inspeccionemos la cadena de cifrado Apache predeterminada en su estado actual Escribo esto:

SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

Eso básicamente permite cualquier cifrado que autentifique. Los intercambios anónimos de Diffie-Hellman ( ADH ) se excluyen de la consideración ( ! ), pero todo lo demás se acumula allí. De hecho, dado el ALL justo al principio, solo !ADH está teniendo efecto. Todo ya está incluido. Los cifrados de exportación, los cifrados de baja calidad (40/56 bit, etc.) son todos un juego justo para negociar.

Si queremos ser muy simples, RC4 (simétrico), RSA (intercambio y firma asimétricos) y SHA1 (hash simétrico) son universalmente compatibles. RC4 tiene algunas debilidades académicas, pero es inmune al ataque BEAST y también es lo que mi navegador negocia para hablar con Google.

SSLCipherSuite 'ECDHE-RSA-RC4-SHA:RC4+SHA1+RSA'

Verificar:

 $ openssl ciphers -v 'ECDHE-RSA-RC4-SHA:RC4+SHA1+RSA'
 ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
 RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

Eso se encarga de configurarlo y olvidarlo. Pongo ECDHE-RSA-RC4-SHA en el frente porque soy un fan de usar secreto hacia adelante perfecto , pero no es soportado universalmente.

Sin embargo, para futuras referencias, aquí hay algunas otras cosas que debe considerar si está construyendo una cadena que especifica cifrados genéricamente:

  • Sin cifrados de "exportación" débiles: !EXP
  • No hay intercambios no autenticados de Diffie-Hellman: !ADH
  • No estamos usando una clave previamente compartida, por lo que !PSK

Agregue los cifrados que le interesen después de eso. Utilice otras exclusiones si necesita limitar algo. Seleccione combinaciones específicas utilizando el signo + en lugar de los dos puntos. Por ejemplo:

$ openssl ciphers -v '!ADH:AES+DH'
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1

es muy diferente de:

$ openssl ciphers -v '!ADH:AES:DH'
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
AECDH-AES256-SHA        SSLv3 Kx=ECDH     Au=None Enc=AES(256)  Mac=SHA1
ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
AECDH-AES128-SHA        SSLv3 Kx=ECDH     Au=None Enc=AES(128)  Mac=SHA1
ECDH-RSA-AES128-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA1
EDH-RSA-DES-CBC-SHA     SSLv3 Kx=DH       Au=RSA  Enc=DES(56)   Mac=SHA1
EDH-DSS-DES-CBC-SHA     SSLv3 Kx=DH       Au=DSS  Enc=DES(56)   Mac=SHA1
EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=RSA  Enc=DES(40)   Mac=SHA1 export
EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=DSS  Enc=DES(40)   Mac=SHA1 export

¿Es este un tema digno?

Estamos sopesando las vulnerabilidades académicas. RC4 es académicamente más débil que AES. AES es académicamente más débil si logra que el cliente ejecute un código no deseado.

Es bueno estar informado de los riesgos, pero después de hacer algunas búsquedas, la gente se encuentra con este problema como resultado de las exploraciones de PCI-DSS. El auditor está viendo esto en su herramienta automatizada y reaccionando. Si el usuario final está ejecutando un código no deseado, entonces ocurrió un mayor problema de raíz: su sitio está comprometido a través de algo como XSS y usted necesita arreglar eso o su máquina está comprometida (directamente o ejecutando el código de otro sitio) y el atacante Probablemente puede ejecutar incluso más software malicioso. Los navegadores modernos deberían adaptarse al eliminar un paquete de un byte al inicio de la conexión para activar el relleno y negar el ataque también.

De muchas maneras, realmente está en el cliente aquí. Si va a preocuparse por la privacidad del cliente, garantizar que su sitio no esté comprometido es el problema de orden superior en mi mente. Dado eso, SSL no hace mucho para ayudar a un cliente que está ejecutando algo malintencionado localmente, por lo que ahora volvemos a ver el cifrado AES más fuerte.

... pero, para pasar la auditoría sin un argumento y observar las espaldas de sus clientes (básicamente, lo que Google está tratando de hacer con cierto margen), RC4 lo lleva allí hoy. Esperemos que una versión más alta de TLS lleve a todos allí mañana, pero ese progreso es prácticamente glacial.

    
respondido por el Jeff Ferland 25.05.2012 - 17:02
fuente
1

estamos usando esto SSLProtocolo todo -SSLv2 -TLSv1

SSLCipherSuite ECDHE-RSA-AES256-SHA384:! AES:! AES256-SHA256:! AES256-SHA256: RC4: HIGH:! MD5:! SSLv2:! ADH:! aNULL:! NULL:! NULL:! ! ADH:! EDH:! AESGCM:! DES-CBC3-SHA

Sin embargo, estamos fallando 403labs PCI scan (parece que están usando el mismo plugin / nessus), y la prueba Qualys SSL labs dice que somos compatibles con PCI ... enlace

    
respondido por el Ivan Lotina 25.05.2012 - 17:56
fuente

Lea otras preguntas en las etiquetas