OpenSSL: Afficher les paramètres DH

15

Lors de l'utilisation de chiffrements SSL reposant sur un échange de clés diffie hellman, la taille de la clé privée utilisée est d'une importance cruciale pour la sécurité de cet échange de clés.

Lorsque je me connecte à un serveur à l'aide de l'outil "openssl s_client", comment puis-je interroger les paramètres DH utilisés?


la source

Réponses:

17

Je ne connais pas de commutateur de ligne de commande facile à utiliser, mais dans la openssl s_clientligne de commande, vous pouvez ajouter l' -msgoption pour obtenir un vidage hexadécimal du message de prise de contact. Recherchez ensuite le ServerKeyExchangemessage; ça devrait ressembler à ça:

<<< 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
    (...)

et il se lit de cette façon:

  • 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 en tant que 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 exactement de 2048 bits.

Si vous utilisez une suite de chiffrement ECDHE (courbe elliptique), alors le ServerKeyExchangeformat est différent, bien sûr.

Voir la norme pour la définition du ServerKeyExchangemessage. Pour les suites de chiffrement DHE, il contient le module p , le générateur g et la clé publique DH du serveur y , dans cet ordre, chacun étant exprimé sous la forme d'un grand entier au format décrit ci-dessus (en-tête de 16 bits qui contient la longueur en octets, puis l'entier valeur dans le codage big-endian non signé).

Les versions récentes d'OpenSSL ont tendance à sélectionner une taille de module DH qui correspond (du point de vue de la sécurité) à la force de la paire de clés du serveur (utilisée pour signer le ServerKeyExchangemessage). Dans l'exemple ci-dessus, le serveur a une clé RSA de 2048 bits, donc OpenSSL a choisi d'utiliser un module DH de 2048 bits (dans ce cas, le module bien connu décrit dans la RFC 3526, section 3 ).

Certains autres serveurs s'en tiennent aux groupes DH de 1024 bits afin d'assurer la compatibilité avec certains clients existants qui ne prennent pas en charge les groupes DH plus importants (le plus grand délinquant étant l'implémentation SSL en Java, corrigé dans Java 8 build 56 en 2012). Une faille connue dans le protocole TLS, pour les suites de chiffrement DHE, est que le client n'a aucun moyen de spécifier la taille de module qu'il peut prendre en charge (cela est corrigé pour ECDHE, car le client peut spécifier la liste exacte des courbes qu'il accepte) .

Thomas Pornin
la source
1
OpenSSL ne sélectionne pas automatiquement DHE, mais un rappel d'application peut. OpenSSL 1.0.2 (janvier 2015) peut éventuellement sélectionner automatiquement ECDHE , et également dans 1.0.2 s_clientaffiche toujours "Temp server key" DH & size ou ECDH & curve le cas échéant, juste avant que "la poignée de main ait lu x et écrit y", vous n'avez donc plus besoin pour le décoder. C'est Apache mod_ssl récent qui sélectionne automatiquement DHE: httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcertificatefile (qui note le problème des clients Java).
dave_thompson_085
J'utilise OpenSSL 1.0.1e et je ne reçois tout pas ServerKeyExchangeavec 0c 00 03 0b. pouvez-vous fournir la commande exacte pour obtenir la sortie? Je n'ai aucune poignée de main commençant par0c
rubo77
Si la suite de chiffrement sélectionnée par le serveur n'est pas une suite de chiffrement "DHE" ou "ECHDE", il n'y aura pas de message ServerKeyExchange.
Thomas Pornin
J'obtiens <<< TLS 1.2 Handshake [longueur 01cd], ServerKeyExchange 0c 00 01 c9 03 00 17 41 04 08 5f 82 88 1e e5 b6 suivi de 443 octets qui correspondent à une longueur de 0x1c9 commençant au cinquième octet. Cependant, "0300" semble signifier 768 octets alors que je suis sûr que mon paramètre DH n'est "que" de 2048 bits.
Loi29
1
@ Law29 Cela ressemble plus à un ECDHE ServerKeyExchange. Si vous utilisez une courbe elliptique, le "03" signifie "c'est une courbe nommée, les deux octets suivants codent l'identifiant de la courbe". "00 17" est alors l'identifiant de la courbe, qui est le NIST P-256 (la courbe la plus utilisée pour ECDHE). Alors "41" est la longueur du point public, qui est exactement la bonne valeur pour un point P-256 au format non compressé; un tel point commencerait par un octet de valeur 0x04, et c'est précisément ce que vous avez. Pour résumer: il semble que votre poignée de main TLS 1.2 utilise vraiment ECDHE, pas DHE.
Thomas Pornin
9

Si vous avez le certificat au format PEM, vous pouvez essayer cette commande, elle devrait vous donner une sortie correcte de la commande Openssl.

openssl dhparam -inform PEM -in ./imapd.pem -check -text

(Exemple de sortie)
    Paramètres PKCS # 3 DH: (512 bits)
        premier:
            xx: xx: xx: xx
            xx: xx: xx: xx
            xx: xx: xx: xx
        générateur: 2 (0x2)
Les paramètres DH semblent corrects.
----- COMMENCER LES PARAMÈTRES DH -----
XXXX
XXXX
----- PARAMÈTRES DE FIN DH -----

J'espère que c'est ce que vous recherchez.

David Loh
la source