web-dev-qa-db-fra.com

Comment vérifier si un serveur n'est pas vulnérable à Logjam?

En réponse à Logjam je veux prouver que j'ai durci mes services. Je sais que le paramètre DH doit être d'au moins 2048 bits et généré automatiquement. Mais je n'arrive pas à trouver un moyen de vérifier réellement ceci pour autre chose qu'un site HTTPS. ( c'est ce que je peux faire ici ) Je voudrais également vérifier mes autres services protégés par SSL:

  • Mail (Postfix et Dovecot)
  • SSH
  • VPN
  • Tout autre

Je suis allé jusqu'à openssl s_client -starttls smtp -crlf -connect localhost:25 Mais cela a donné:

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

Comment puis-je tester les paramètres DH? et que dois-je surveiller pour savoir si je suis à risque?

tlsopenssldiffie-hellman
29
LvB

Faites le test de fumée: (volé de blog OpenSSL . (Archivé ici .))

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

La clé doit être d'au moins 2048 bits pour offrir une marge de sécurité confortable comparable à RSA-2048. Les connexions avec des clés inférieures à 1024 bits peuvent déjà être en difficulté aujourd'hui. (Remarque: vous avez besoin d'OpenSSL 1.0.2. Les versions antérieures du client n'affichent pas ces informations.)

(Si les connexions échouent immédiatement, le serveur ne prend pas du tout en charge l'éphémère Diffie-Hellman ("EDH" en langage OpenSSL, "DHE" ailleurs) et vous êtes à l'abri de Logjam.)

[...]

Enfin, vérifiez que les chiffres d'exportation sont désactivés:

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

La connexion devrait échouer.

En d'autres termes:

  • obtenez OpenSSL 1.0.2.
  • ajouter le -cipher "EDH" option à votre chaîne de connexion.
  • supposer une vulnérabilité si les chiffres d'exportation sont activés sur le serveur
  • supposer une vulnérabilité si 512 bits (ou quelque chose de moins de 2048 bits) se présentent.
20
StackzOfZtuff

J'ai donc décidé de mettre mon commentaire à la réponse "StackzOfZtuff" dans un nouveau message, car vous pouvez réellement disséquer l'échange de clés plus en détail avec cette méthode. Cette réponse est copiée de this poster sur superuser.com (donc merci à Thomas Pornin):

utiliser openssl avec son option -msg donne les informations dont nous nous soucions

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

Cela montre le message TLS ServerKeyExchange complet comme

<<< 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

selon Thomas Pornin, vous pouvez le lire de cette façon (j'ai copié le texte suivant):

  • 0c 00 03 0b: message de type "ServerKeyExchange" (c'est le "0c") de longueur 0x00030B octets.
  • Le premier élément est le module DH comme un grand entier, avec un en-tête de longueur de deux octets. Ici, la longueur est codée comme 01 00, ce qui signifie un entier codé sur 0x0100 octets. C'est 256 octets, donc le module a une longueur entre 2041 et 2048 bits.
  • Les octets de module suivent, dans l'ordre big-endian non signé. Les octets supérieurs de ce module sont, dans ce cas, ff ff ff ff .... Le module a alors une longueur exacte de 2048 bits.

En utilisant cette méthode, vous pouvez également vous assurer que votre serveur n'utilise pas les groupes DH prédéfinis dans RFC 3526 (ce que mon Apache2.4.7 utilisant Ubuntu 14.04 fait toujours, bien que http://httpd.Apache.org/ docs/2.4/mod/mod_ssl.html indique que cette version doit utiliser les paramètres DH ajoutés au SSLCertificateFile encodé en PEM).

4
r_3

Des personnes qui ont trouvé la vulnérabilité

n autre test en ligne

Ces deux me donnent des réponses contradictoires. Je pense que les chercheurs du lien un rapportent que votre site est vulnérable s'il existe un moyen de le configurer qui permettra son exploitation. Où, comme le montre le deuxième lien, le plus pragmatique, "est-il vulnérable en ce moment?" information.

0
cmaynard