La sécurité des échanges sur le web repose en grande partie sur la robustesse des protocoles de chiffrement utilisés. Pourtant, déployer un certificat SSL/TLS ne suffit pas : une mauvaise configuration du serveur web ou l’utilisation de suites cryptographiques obsolètes peuvent rendre vos échanges vulnérables. Comment auditer la configuration SSL/TLS ? C’est ce que nous allons voir.
Dans ce tutoriel, nous allons apprendre à effectuer un audit TLS avec l’outil testssl.sh. Contrairement aux scanners en ligne comme celui de Qualys SSL Labs (que vous connaissez certainement), testssl.sh est une solution en ligne de commande qui peut auditer n’importe quel serveur, qu’il soit sur Internet, dans votre réseau local (LAN) ou même sur votre machine de développement.
Il est pertinent d’utiliser ce type d’outil pour valider la configuration d’un service web (qu’il soit exécuté via Apache, Nginx, IIS, Caddy, etc…) avant sa mise en production, ou pour effectuer des audits de conformité réguliers sur des services web.
Au-delà de l’outil testssl.sh, développé depuis de nombreuses années et éprouvé, je vous invite à jeter un coup d’œil au script Bash SxTLSCheck (ScalarX TLS Checker) développé par Christophe Casalegno. Il fonctionne exclusivement à l’aide d’OpenSSL, ce qui est une approche intéressante car il n’a pas de dépendance.
Qu’est-ce que testssl.sh ?
Testssl.sh est un outil open source, gratuit et maintenu par une communauté active. Écrit en Bash, il s’appuie essentiellement sur OpenSSL pour analyser la configuration d’un service web. L’outil ne se contente pas de vérifier la validité d’un certificat TLS. Il effectue une batterie de tests complète :
Vérification des protocoles supportés (SSLv2, SSLv3, TLS 1.0 à 1.3).
Analyse des suites de chiffrement (Ciphers) et de leur ordre de préférence.
Test de robustesse contre les vulnérabilités connues (Heartbleed, POODLE, CCS Injection, etc.).
Vérification des en-têtes de sécurité HTTP liés à TLS (HSTS, HPKP).
Etc…
Il fonctionne sur n’importe quelle distribution Linux, macOS et FreeBSD, ce qui lui assure une certaine portabilité. Grâce à WSL, il est possible de l’utiliser sous Windows également. Par ailleurs, une image Docker est disponible, ce qui renforce le côté portabilité de cet outil.
Installation et utilisation de testssl.sh
L’installation de testssl.sh est simple car vous n’avez qu’à cloner le dépôt GitHub du projet pour lancer le script. Il s’appuie sur OpenSSL en local, mais ce dernier est généralement présent sur les machines Linux.
Installation sur Linux
La méthode la plus simple est de cloner le dépôt GitHub. Ouvrez votre terminal et installez d’abord Git si nécessaire :
sudo apt update
sudo apt install git
Ensuite, clonez le dépôt et entrez dans le répertoire. Ici, nous ciblons la branche de la version 3.2, qui est la dernière version stable. La version 3.3 est en cours de développement, donc à vous de voir.
git clone –depth 1 https://github.com/testssl/testssl.sh.git –branch 3.2
Cloning into ‘testssl.sh’…
remote: Enumerating objects: 104, done.
remote: Counting objects: 100% (104/104), done.
remote: Compressing objects: 100% (97/97), done.
remote: Total 104 (delta 12), reused 43 (delta 7), pack-reused 0 (from 0)
Receiving objects: 100% (104/104), 6.33 MiB | 28.18 MiB/s, done.
Resolving deltas: 100% (12/12), done.
Positionnez-vous dans le répertoire de l’outil. Si besoin, ajoutez les droits d’exécution sur le script Bash testssl.sh (en principe, c’est déjà OK).
cd testssl.sh
chmod +x testssl.sh
Vous pouvez maintenant vérifier que l’outil fonctionne en affichant l’aide :
./testssl.sh –help
Utilisation via Docker
Pour ceux qui préfèrent ne pas installer de dépendances sur leur système hôte, l’image Docker officielle est une alternative préférable. De plus, cette méthode est particulièrement adaptée pour les environnements CI/CD.
docker run –rm -it ghcr.io/testssl/testssl.sh
Lancer un audit TLS avec testssl.sh
L’utilisation de base de testssl.sh consiste simplement à fournir l’URL ou l’adresse IP (et le port si différent de 443) de l’hôte à analyser. Ce qui donne la syntaxe suivante :
./testssl.sh
Le script va alors lancer une batterie de tests, et au fur et à mesure de la progression, un retour sera effectué dans la console. Différentes couleurs sont utilisées pour faciliter la lecture et l’interprétation des résultats.
Vert : la configuration est sécurisée (conforme aux recommandations) ou la vulnérabilité n’est pas présente.
Blanc : information neutre.
Jaune : Avertissement (suite de chiffrement faible, protocole obsolète mais parfois nécessaire).
Rouge : problème de sécurité sérieux.
Le test peut prendre pas loin de 10 minutes, le temps qu’une analyse complète soit effectuée. Pour accélérer le scan, vous pouvez utiliser l’option –fast. Attention, cette option réduit la profondeur de certains tests (elle vérifie moins de suites de chiffrement par exemple), mais elle offre un aperçu rapide.
Comprendre les sections du rapport
Le rapport standard se divise en plusieurs blocs logiques, à commencer par la section Testing protocols via sockets except NPN+ALP. Chaque section représente un ensemble de tests, on y retrouve notamment :
Testing protocols : liste les protocoles activés. Vous devriez idéalement ne voir que TLS 1.2 et TLS 1.3 en vert. SSLv2, SSLv3, TLS 1.0 et 1.1 doivent apparaître en “not offered”. Même si parfois, pour des raisons de rétrocompatibilité, la réalité peut être différente.
Testing cipher categories : indique quelles sont les catégories d’algorithmes de chiffrement acceptés par le serveur, comme le chiffrement NULL (ce qui serait une faille potentielle). Cela est accompagné d’une section qui détaille quelles sont les préférences du serveur pour le chiffrement.
Testing robust forward secrecy : vérifie si le serveur supporte la confidentialité persistante (PFS), garantissant que le vol de la clé privée du serveur aujourd’hui ne permettra pas de déchiffrer les sessions passées.
Testing server defaults : analyse la chaine de certification et affiche les détails sur l’ensemble des certificats TLS associés.
Testing HTTP header response : analyse le code HTTP obtenu, ainsi que les différents en-têtes, y compris la partie Security headers.
Testing vulnerabilities : le script teste la présence de failles célèbres comme Heartbleed, ROBOT, ou Logjam.
D’autres tests sont effectués, comme des simulations de connexion depuis divers types de clients (Chrome, Edge, Safari, Android, OpenSSL, etc…) afin de voir comment le serveur gère ces différentes connexions (notamment le protocole utilisé).
Il est à noter que les résultats ne reflètent pas nécessairement la configuration locale de votre serveur. En effet, si vous utilisez un système comme Cloudflare, ce sont les paramètres de ce service qui seront analysés par testssl.sh, et non la configuration directe de votre serveur.
Enfin, le test se termine par un compte rendu global où une note est retournée en s’appuyant sur le système d’évaluation du célèbre service SSL Labs (décrit sur cette page). Voici un exemple :
Affiner le test avec les options de testssl.sh
Lancer un scan complet peut prendre du temps, et parfois, vous pourriez vouloir tester uniquement un point précis. Testssl.sh offre cette possibilité grâce aux différentes options disponibles en tant qu’arguments de la ligne de commande. Vous pouvez coupler plusieurs options ensemble.
Respectez la syntaxe suivante :
./testssl.sh [options]
Vérifier uniquement les protocoles
Si vous souhaitez simplement savoir si un serveur a désactivé les vieux protocoles SSL/TLS, utilisez l’option -p :
./testssl.sh -p
Cela affichera uniquement la section concernant SSLv2, SSLv3 et les versions de TLS.
Tester uniquement les vulnérabilités
Pour vérifier si un serveur est patché contre les failles connues sans lister tous les ciphers, utilisez l’option -U :
./testssl.sh -U
Scanner des services non-HTTP
Testssl.sh n’est pas limité au HTTPS. Il peut scanner tout service utilisant TLS, comme un serveur mail (SMTP, IMAP) ou un serveur FTP. Le script détecte souvent le protocole automatiquement, mais il est préférable de le spécifier avec l’option -t (pour starttls).
La documentation de l’outil indique une prise en charge des services suivants (correspondant à des protocoles) : ftp, smtp, lmtp, pop3, imap, xmpp, xmpp-server, telnet, ldap, nntp, sieve, postgres, mysql.
Pour tester un serveur SMTP avec STARTTLS :
./testssl.sh -t smtp smtp.domaine.fr:25
Générer des rapports pour l’audit
Rapport HTML
C’est le format le plus lisible pour les humains. Il génère un fichier HTML autonome, tout en conservant l’affichage des tests dans le terminal. Le rapport HTML ressemble à la sortie dans le terminal, sauf qu’elle est formatée en HTML.
./testssl.sh –htmlfile rapport_tls.html www.domaine.fr
Vous pouvez ensuite ouvrir ce fichier dans n’importe quel navigateur pour présenter les résultats à un client, à votre responsable, ou simplement pour en garder une trace.
Rapport JSON
Pour l’automatisation (intégration dans un pipeline, par exemple), le format JSON est plus pertinent que le rapport HTML. Dans ce cas, voici la syntaxe à adopter :
./testssl.sh –jsonfile-pretty rapport.json https://mon-intranet.local
Conclusion
Testssl.sh est un outil open source très pratique pour l’audit de configuration TLS/SSL en ligne de commande. Il a peu de dépendance, et surtout il fonctionne en local sans solliciter de services tiers. Au-delà des services web, sa compatibilité avec les services non-web (SMTP, FTP) est également un avantage, qui en fait un outil d’analyse avec un périmètre assez large sur tout ce qui touche au TLS/SSL.
Ingénieur système et réseau, cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.