Nouveau outil auto-hébergé tlswatch : audit des certificats TLS et du support des protocoles hérités

Un nouvel utilitaire auto-hébergé nommé tlswatch a fait son apparition pour aider les équipes d'infrastructure à surveiller la santé et la sécurité de leurs configurations Transport Layer Security (TLS). Développé par Sjoerd305, cet outil va au-delà des simples alertes d'expiration en auditant les chaînes de certificats, la force des signatures et la présence de protocoles obsolètes comme TLS 1.0. Il fonctionne sous forme d'un seul binaire Go avec une base de données SQLite, conçu pour un déploiement facile dans les environnements où les équipes gèrent leurs propres piles logicielles.

Ce qui s'est passé

tlswatch interroge activement les noms d'hôtes et les adresses IP pour inspecter les certificats TLS actuellement servis. Contrairement aux moniteurs de disponibilité classiques qui se contentent souvent de vérifier si un port HTTPS est ouvert, cet outil examine chaque adresse derrière un nom de domaine. Cette capacité est cruciale pour détecter les nœuds obsolètes cachés derrière des équilibreurs de charge qui pourraient encore servir des certificats expirés ou mal configurés. Le système prend en charge les vérifications sur n'importe quel port, gérant à la fois le TLS implicite et les protocoles STARTTLS utilisés par des services tels que SMTP, IMAP, POP3, FTP et PostgreSQL.

L'outil effectue également des audits de configuration approfondis. Il exécute des tests quotidiens pour identifier les serveurs acceptant encore des connexions non sécurisées via SSL 3.0, TLS 1.0 ou TLS 1.1. Il évalue les suites de chiffrement pour détecter les faiblesses, y compris les options export-grade, NULL, anonymes, DES, RC4 et 3DES. Sur la base de ces constatations, tlswatch attribue une note de configuration allant de A à F pour chaque cible, en fournissant des raisons claires pour toute déduction. Il détecte aussi les cas limites, tels que des certificats RSA servis parallèlement à des certificats ECDSA, ou des certificats par défaut servis sans Server Name Indication (SNI), ce qui peut perturber certains clients.

Détails clés

• Déploiement en un seul binaire : L'application s'exécute sous forme d'un unique binaire Go incluant une interface web et une base de données SQLite, sans nécessiter de services supplémentaires.
• Prise en charge complète des protocoles : Vérifie tout port pour le TLS implicite ou STARTTLS, couvrant les services de messagerie, de base de données et de transfert de fichiers.
• Détection des héritages : Identifie les serveurs acceptant TLS 1.0, 1.1 ou SSL 3.0 et note la sécurité de la configuration de A à F.
• Sondage distribué : Utilise des « nœuds » pour sonder les réseaux internes inaccessibles depuis le serveur principal, ces nœuds se mettant à jour automatiquement.
• Correspondance Certificate Transparency : Compare les certificats publiquement émis avec ceux réellement servis pour détecter les certificats inutilisés ou frauduleux.
• Alertes flexibles : Envoie des notifications par e-mail, Telegram, Slack, Discord, ntfy ou webhooks, avec prise en charge des acquittements groupés.

Contexte

Transport Layer Security (TLS) est le protocole standard pour chiffrer les données transmises sur Internet. Si la plupart des administrateurs surveillent les dates d'expiration des certificats pour éviter les pannes de service, la sécurité d'une implémentation TLS dépend de bien plus que la seule période de validité. Les serveurs doivent également appliquer des normes cryptographiques fortes et rejeter les protocoles obsolètes vulnérables aux attaques. Les protocoles hérités comme TLS 1.0 et 1.1 présentent des faiblesses connues et sont dépréciés par les principaux organismes industriels, mais ils restent souvent activés par défaut ou en raison des exigences d'applications anciennes.

Certificate Transparency (CT) est un système de registre public qui journalise tous les certificats TLS émis. La surveillance des journaux CT aide les organisations à détecter les émissions de certificats non autorisées. Cependant, l'apparition d'un certificat dans le journal ne garantit pas qu'il est correctement déployé sur les serveurs prévus. Les outils qui ne surveillent que les journaux CT peuvent manquer les erreurs de configuration, tandis que ceux qui ne vérifient que les serveurs actifs peuvent ignorer les émissions non autorisées. tlswatch comble cette lacune en croisant les données publiques d'émission avec des sondages directs sur les serveurs.

Pourquoi c'est important

Pour les équipes utilisant des logiciels auto-hébergés, maintenir une posture TLS sécurisée est complexe. L'infrastructure comprend souvent un mélange de serveurs web publics et de services internes comme les bases de données ou les serveurs de mail utilisant STARTTLS. Les moniteurs de disponibilité classiques traitent généralement le TLS comme une boîte noire, se limitant à vérifier qu'une connexion peut être établie. Ils inspectent rarement la chaîne de certificats, ne vérifient pas les chiffrements faibles et ne valident pas que toutes les adresses IP derrière un équilibreur de charge utilisent le bon certificat. Cet angle mort peut entraîner des vulnérabilités de sécurité ou des défaillances intermittentes difficiles à diagnostiquer.

tlswatch répond à ces lacunes en offrant une vue unifiée de la santé des certificats et de la sécurité des configurations. En attribuant une note à chaque cible, il donne aux opérateurs un moyen rapide de prioriser les efforts de remédiation. La capacité de sonder les réseaux internes via des nœuds distribués signifie que même les services isolés de l'Internet public peuvent être surveillés pour leur conformité aux politiques de sécurité. Cela est particulièrement précieux pour les organisations qui doivent appliquer des normes cryptographiques strictes à l'ensemble de leur infrastructure, et pas seulement à leurs sites publics.

Ce que vous pouvez faire

• Déployer une instance de test : Utilisez le fichier Docker Compose fourni pour exécuter tlswatch localement et explorer son interface sans vous engager dans une mise en production.
• Auditer les services internes : Configurez des nœuds pour sonder les ports internes tels que 587 pour SMTP ou 5432 pour PostgreSQL afin de garantir que STARTTLS est correctement implémenté.
• Examiner les notes de configuration : Consultez les notes de A à F pour vos points de terminaison publics afin d'identifier et de désactiver les protocoles hérités comme TLS 1.0 ou les suites de chiffrement faibles.
• Surveiller Certificate Transparency : Activez la surveillance CT pour recevoir des alertes si des certificats sont émis pour vos domaines mais ne sont pas servis par votre infrastructure connue.
• Exporter les données d'inventaire : Utilisez la fonction d'export CSV pour maintenir un registre externe de tous les certificats, de leurs dates d'expiration et de leurs lieux de service.
• Intégrer aux alertes existantes : Connectez tlswatch à vos canaux de notification actuels, tels que Slack ou Telegram, pour assurer que les avertissements concernant les certificats parviennent aux bons membres de l'équipe.