¿El procedimiento de acción recomendado para prevenir Logjam en los servidores Tomcat realmente elimina todos los riesgos de las claves DH débiles?

9

¿Alguien puede verificar que esta solución se proteja contra vulnerabilidad de Logjam para Apache Tomcat?

Soy escéptico acerca de su efectividad, ya que no menciona cómo implementar el archivo de parámetros DH de 2048 bits definido por el usuario en Tomcat, pero su lista de cifrado utiliza cifrados "DHE". Ayer se mencionó la configuración de "SSLDHParametersFile", pero se eliminó, posiblemente debido a este error , donde dice que Tomcat solo puede manejar longitudes de clave DH de 1024 bits. Pero no soy un experto en esto, posiblemente mezclando las cosas aquí.

En este momento, el sitio WeakDH dice que debe agregar esta lista de cifrado al Connector en el server.xml de archivo (para JSSE) para solucionarlo:

  

cifrados="ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-AES256-GCM-SHA384 AES128-GCM-SHA256, DHE-DSS-AES128-GCM-SHA256: kEDH + AESGCM: ECDHE-RSA-AES128-SHA256: ECDHE-Estado-A-Estado-Estado-A-Estado-V-A-Estado-V-A-Estado-V-A-Estado-Estado SHA: ECDHE-RSA-AES256-SHA384: ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA, ECDHE-ECDSA-AES256-SHA, DHE-RSA-AES128-SHA256, EE. DHE-DSS-AES128-SHA256, DHE-RSA-AES256-SHA256, DHE-DSS-AES256-SHA, DHE-RSA-AES256-SHA, AES128-GCM-SHA256, AES256-GCM-SHA384, AES128 -A2525 SHA256, AES128-SHA, AES256-SHA, AES, CAMELLIA, DES-CBC3-SHA "

    
pregunta Casper 21.05.2015 - 12:35
fuente

3 respuestas

8

Así que creo que he interpretado tu pregunta correctamente. Si no, dispara en los comentarios.

Confusamente, hay varios factores en la diferencia del hombre del infierno: lo está haciendo sobre curvas elípticas o no, qué grupo de tamaño tiene (supongamos "fuerte" y "no fuerte") y si genera pares de llaves efímeras privadas / públicas o no.

El problema con logjam es el siguiente: si tiene una variante de grupo simple y antigua de DHE, entonces si puede convencer al servidor para que disminuya a la potencia de nivel de exportación (variedad débil), entonces con algunas precomputaciones hechas antes de poder romper la Secreto generado para una sesión en minutos.

Esto está condicionado a poder bajar la variable de tamaño a una más pequeña: si puedes hacer esto con la simple variante DHE, entonces estás en el negocio.

Esto requiere que la suite de cifrado tenga DHE_..._EXPORT_... , como TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA . Ahora que tiene un montón de otros problemas como el DES de 40 bits y otras cosas, pero esencialmente, podría haber algunos servidores que admitan las variantes de EXPORT de DHE con mejores cifrados simétricos. O, de hecho, podrían estar negociando un DES de 40 bits si están convencidos.

El punto es realizar un ataque de degradación. La lista de conjuntos de cifrado que ha proporcionado no permite cifrados de exportación.

Usted podría desactivar todas las variantes que no sean EC de DH. Sin embargo, esto podría limitar el soporte del lado del cliente. Si puedes o no ser tan limitante realmente depende de ti. Pero "DHE" en sí mismo está bien, a menos que haya exportación en algún lugar. Asegúrese de que los cifrados de exportación estén deshabilitados y siga los consejos de Thomas en la respuesta que vinculó.

Ahora en SSLDHParametersFile - en DHE, el cebador y el generador del grupo pueden ser arreglados antes de tiempo - el bit que es efímero es la clave privada elegida en ese grupo. De esta manera, al configurar los parámetros, puede controlar qué grupo de tamaño usa su servidor.

Por ejemplo, la salida de esto podría ser:

openssl dhparam 2048 -text
<snip>
    PKCS#3 DH Parameters: (2048 bit)
    prime:
        00:bd:90:31:72:a5:bf:eb:96:b0:0e:1c:1e:3f:ff:
        cd:0a:e2:fc:14:72:50:19:f8:6d:e9:25:3c:3d:21:
        3b:3c:e3:93:9b:2e:a1:b5:98:dc:25:88:9c:9e:55:
        1a:78:36:a8:10:67:f2:f1:37:e7:6b:c7:b8:39:85:
        a7:ec:aa:e9:2f:4e:10:17:fd:72:e1:22:2e:ab:97:
        4b:bf:7b:a2:68:6d:94:a8:ae:df:e0:fb:66:ad:79:
        02:9c:09:ba:47:60:40:12:a8:27:46:ba:8f:a9:8b:
        bd:f5:d2:4e:67:0c:7a:49:f3:9d:80:98:50:4d:8c:
        72:38:47:91:4b:54:1f:3b:74:b5:81:30:c7:89:71:
        b0:87:8a:82:66:b0:06:f6:2e:a6:2b:e8:18:51:23:
        2d:09:d9:0a:87:03:7b:85:8a:27:c6:bd:fa:e9:16:
        70:b3:bf:ad:77:d5:55:72:22:e7:7c:6b:4e:31:2c:
        86:91:7a:51:11:ac:23:9d:5f:3d:f1:f2:83:02:98:
        72:a2:a4:c5:a8:26:40:25:02:59:00:80:22:37:ac:
        38:95:07:76:f5:31:3d:19:f6:81:36:6c:14:fa:d8:
        46:10:e1:b4:fa:5f:e2:9d:2f:a1:78:47:5d:9c:f9:
        ac:0c:06:83:dc:f4:2d:81:17:d4:34:1b:6f:c2:c7:
        2c:0b
    generator: 2 (0x2)

Es revelador, por su error de ejemplo, parece que todavía no es posible utilizar estos archivos de parámetros con Tomcat. No soy un experto en Tomcat, así que realmente no puedo decir pero si ha dado instrucciones a las suites de cifrado para que no permitan la exportación, OpenSSL debería predeterminar un grupo DH de 1024 bits, que es lo suficientemente bueno por ahora.

Puede, entonces, cuando el parche esté disponible, actualizar sus parámetros DH como mejor le parezca.

    
respondido por el user70990 21.05.2015 - 16:30
fuente
2

Como una adición al proveedor, enumero mi práctica:

Por el momento no permitiría la comunicación directa con Tomcat,  pero configure una conexión de proxy inverso utilizando nginx.

Y haz que nginx haga todos los bits SSL. Las principales ventajas son que nginx se puede configurar con mejores claves DH y compatibilidad con cifrado. como beneficio adicional si alguien está intentando "piratear" mi gato mediante la inyección de desbordamiento. probablemente solo llegará al proxy nginx y no al tomcat en sí. (así que otra capa para derrotar a un atacante)

    
respondido por el LvB 22.05.2015 - 02:32
fuente
-3

Desactive cualquier cifrado en modo CBC y protocolos SSL, solo habilite TLS 1.1 & 1.2 protocolos en su server.xml.

Mozilla también tiene una buena guía para cifrados permitidos. enlace

    
respondido por el jas- 21.05.2015 - 13:34
fuente

Lea otras preguntas en las etiquetas