Tout commence par la lecture d'une causerie sur Twitter qui mentionne un testeur TLS qui marque au fer rouge les configurations TLS qui n'utilisent pas les groupes prédéfinis dans leurs paramètres Diffie-Hellman (DH) utilisés, pour rappel, lors de l'échange des clés de chiffrement symétrique. Surtout, ce fil m'apprend qu'une manip' « résout le problème ».
Or, depuis le renforcement de mes configurations TLS de 2020, j'attendais que la fonction « SSL_CONF_cmd() » d'OpenSSL, qui est utilisée par la directive de configuration « SSLOpenSSLConfCmd » d'Apache httpd, prenne en charge les groupes prédéfinis lors d'une génération à la volée des paramètres DH. Or, même la version 1.1.1n empaquetée dans Debian 11 Bullseye ne permet pas cela (Apache httpd ne redémarre pas quand j'utilise la directive SSLOpenSSLConfCmd Groups ffdhe4096
… alors que cette valeur est référencée dans la doc' depuis 2019).
J'ai fini par comprendre que les paramètres DH avec groupes prédéfinis du RFC 7919 sont… des paramètres DH connus à l'avance. Rien de plus. Ils sont disponibles au téléchargement chez plusieurs acteurs. Mozilla : https://ssl-config.mozilla.org/ffdhe4096.txt ; Internet.nl : https://raw.githubusercontent.com/internetstandards/dhe_groups/main/ffdhe4096.pem.
On peut également demander à OpenSSL de nous les sortir : openssl genpkey -genparam -algorithm DH -pkeyopt dh_param:ffdhe4096 -out /etc/ssl/ffdhe4096.pem
.
J'étais donc totalement dans l'erreur. Le but du RFC 7919 est précisément de normaliser des paramètres DH fiables, c'est-à-dire dont les détails mathématiques (les groupes, etc.) sont connus et semblent être robustes, et de les utiliser partout. Par opposition aux paramètres DH générés à la volée (Dovecot faisait ça à une époque, Apache httpd fait ça si l'on ne configure pas explicitement des paramètres DH) qui peuvent être daubés.
Les paramètres DH normalisés s'utilisent comme tous les paramètres DH.
Du coup, avec nginx, il suffit d'utiliser la directive de configuration ssl_dhparam
avec, comme valeur, le chemin vers le fichier récupéré (ou généré) à l'étape précédente. Postfix : smtpd_tls_dh1024_param_file
. Dovecot : ssl_dh
. Ejabberd : c2s_dhfile
et s2s_dhfile
.
Et avec Apache httpd ? Il faut ajouter les paramètres DH au fichier qui contient les certificats x509 (feuille et intermédiaires) que l'on passe à la directive de configuration SSLCertificateFile
… Paye ton gloubi-boulga…
Avant de commencer mes manipulations, plusieurs testeurs TLS m'indiquaient que j'utilisais des paramètres DH de 3072 bits alors que, d'après ma configuration, j'ordonnais l'utilisation de paramètres de 4096 bits. En commentant la directive de configuration SSLOpenSSLConfCmd DHParameters
, j'obtenais le même résultat, ce qui prouve son inertie. C'est ici que l'on voit à l'œuvre les paramètres DH générés à la volée par un logiciel. ;)
Une recherche sur le web m'a appris que la directive SSLOpenSSLConfCmd DHParameters
ne produit pas (plus ?) l'effet escompté, et que ça serait la faute à OpenSSL (tous les logiciels serveur sus-cités parviennent à utiliser une directive de configuration séparée pour passer les paramètres DH, mais c'est la faute à OpenSSL… :- ). Source.
Comment tester mes changements ? Ma liste de testeurs de configurations TLS.
https://internet.nl/ permet de tester web et SMTP.
https://xmpp.net/ permet de tester XMPP. Même s'il n'évalue pas la robustesse des paramètres DH, il affiche « Group: draft-ietf-tls-negotiated-ff-dhe-10 ffdhe4096 » quand ils sont utilisés.
Et pour tester IMAP, alors ? Je n'ai pas trouvé d'outil, donc je l'ai fait à la main : openssl s_client -connect <server.example>:143 -starttls imap -tls1_2 -cipher 'DHE' -msg
. « msg » permet d'afficher les messages de la poignée de main TLS. Il suffit de constater que le contenu du message TLS « ServerKeyExchange » a changé… et qu'il contient, en partie, le même contenu que celui de tout serveur utilisant les groupes DH prédéfinis (« ff ff ff ff ff ff ff ff ad f8 54 58 a2 bb 4a 9a af dc 56 20 27 3d 3c f1 d8 b9 », etc.).