Je ne connais pas de commutateur de ligne de commande facile à utiliser, mais dans la openssl s_client
ligne de commande, vous pouvez ajouter l' -msg
option pour obtenir un vidage hexadécimal du message de prise de contact. Recherchez ensuite le ServerKeyExchange
message; ç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 ServerKeyExchange
format est différent, bien sûr.
Voir la norme pour la définition du ServerKeyExchange
message. 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 ServerKeyExchange
message). 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) .
s_client
affiche 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).