¿Cómo verificar si un servidor no es vulnerable a Logjam?

28

En respuesta a Logjam , quiero demostrar que he reforzado mis servicios. Sé que el parámetro DH tiene que ser al menos 2048 bits y auto generado. Pero no puedo encontrar una manera de verificar esto para otra cosa que no sea un sitio HTTPS. ( eso es lo que puedo hacer aquí ) También me gustaría consultar mis otros servicios protegidos con SSL:

  • Correo (Postfix y Dovecot)
  • SSH
  • VPN
  • Cualquier otro

Llegué hasta openssl s_client -starttls smtp -crlf -connect localhost:25 , pero eso dio como resultado:

CONNECTED(00000003) depth=3 C = SE, O = ME, OU = Also ME, CN = Me again verify error:num=19:self signed certificate in certificate chain

verify return:0 Server certificate

-SNIPED SOME VALUES-

--- SSL handshake has read 6118 bytes and written 466 bytes

--- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression:

NONE Expansion: NONE SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 6EAA8A5B22E8C18E9D0E78A0B08447C8449E9B9543601BC53F57CB2059597754
    Session-ID-ctx: 
    Master-Key: <MASTERKEY>
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1432213909
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
--- 250 DSN

¿Cómo puedo probar los parámetros DH? ¿Y qué debo vigilar para saber si estoy en riesgo?

    
pregunta LvB 21.05.2015 - 16:10
fuente

3 respuestas

19

Haga la prueba de humo: (robado de blog de OpenSSL . (Archivado aquí .))

openssl s_client -connect www.example.com:443 -cipher "EDH" | grep "Server Temp Key"
  

La clave debe ser de al menos 2048 bits para ofrecer un margen de seguridad cómodo comparable al RSA-2048. Las conexiones con claves de menos de 1024 bits ya pueden estar en problemas hoy. (Nota: necesita OpenSSL 1.0.2. Las versiones anteriores del cliente no muestran esta información).

(Si las conexiones fallan de inmediato, entonces el servidor no es compatible con Diffie-Hellman efímero ("EDH" en OpenSSL-speak, "DHE" en ningún otro lugar) y está seguro de Logjam.)

[...]

  

Finalmente, verifique que los cifrados de exportación estén deshabilitados:

$ openssl s_client -connect www.example.com:443 -cipher "EXP"
  

La conexión debería fallar.

En otras palabras:

  • obtener OpenSSL 1.0.2.
  • agrega la opción -cipher "EDH" a tu cadena de conexión.
  • asume la vulnerabilidad si los cifrados de exportación están habilitados en el servidor
  • asume la vulnerabilidad si aparecen 512 bits (o algo menos de 2048 bits).
respondido por el StackzOfZtuff 21.05.2015 - 16:25
fuente
4

Así que decidí poner mi comentario a la respuesta "StackzOfZtuff" en una nueva publicación, ya que realmente puedes analizar el intercambio de claves con más detalle con este método. Esta respuesta se ha copiado de esta publicación en superuser.com (así que muchas gracias a Thomas Pornin) :

el uso de openssl con su opción -msg proporciona la información que nos interesa

openssl s_client -connect mail.example.com:143 -starttls imap -cipher EDH -msg

Esto muestra el mensaje completo de TLS ServerKeyExchange como

<<< TLS 1.2 Handshake [length 030f], ServerKeyExchange 0c 00 03 0b 01 00 ff ff ff ff ff ff ff ff c9 0f da a2 21 68 c2 34 c4 c6 62 8b 80 dc 1c d1 29 02 4e 08 8a 67 cc 74 02 0b be a6 3b 13 9b 22 51 4a

según Thomas Pornin, puede leerlo de esta manera (copié el siguiente texto literalmente):

  • 0c 00 03 0b: mensaje de tipo "ServerKeyExchange" (que es el "0c") de longitud 0x00030B bytes.
  • El primer elemento es el módulo DH como un entero grande, con un encabezado de longitud de dos bytes. Aquí, la longitud se codifica como 01 00, lo que significa un entero codificado sobre 0x0100 bytes. Eso es 256 bytes, por lo que el módulo tiene una longitud entre 2041 y 2048 bits.
  • Siguen los bytes de módulo, en orden big-endian sin firmar. Los bytes superiores de ese módulo son, en este caso, ff ff ff ff ... El módulo tiene una longitud de exactamente 2048 bits.

Al usar este método, también puede asegurarse de que su servidor no use los Grupos DH predefinidos en RFC 3526 (que mi Apache2.4.7 con Ubuntu 14.04 todavía usa, aunque enlace indica que esta versión debe usar parámetros DH agregados al SSLCertificateFile codificado PEM).

    
respondido por el r_3 22.05.2015 - 21:05
fuente
0

De las personas que encontraron la vulnerabilidad

Otra prueba en línea

Estos dos me dan respuestas conflictivas. Creo que los investigadores en el enlace uno informan que su sitio es vulnerable si existe alguna forma en la que se pueda configurar que permita su explotación. Cuando el segundo enlace muestra lo más pragmático, "¿es vulnerable en este momento?" información.

    
respondido por el cmaynard 01.06.2015 - 16:46
fuente

Lea otras preguntas en las etiquetas