TLS de la messagerie, de l'annuaire et des bases de données (STARTTLS)
TLS de la messagerie, de l'annuaire et des bases de données (STARTTLS)
Atteignez les services qu'une analyse HTTPS ne couvre pas : messagerie, annuaire, transfert de fichiers, messagerie instantanée, bases de données et files de messages. Obtenez leur certificat, leur configuration TLS et le verdict post-quantique de leur échange de clés, et repérez ceux qui communiquent encore en clair.
Vue d'ensemble
Une analyse TLS classique ne fonctionne que si le premier octet échangé est un handshake TLS, ce qui couvre HTTPS et peu d'autres choses. La messagerie, l'annuaire et la plupart des bases de données commencent par un court échange en clair avant de passer en TLS, et plusieurs bases et files de messages ne servent TLS sur leur propre port que si l'exploitant l'a activé.
Ce type d'analyse (nommé starttls dans l'API et la CLI) traite les deux cas. Une fois la connexion prête pour TLS, il exécute le même handshake de certificat et la même sonde d'échange de clés post-quantique qu'une analyse de domaine : les résultats sont directement comparables à ceux de vos endpoints HTTPS. Il n'envoie aucun identifiant et ne lit aucune donnée.
Protocoles pris en charge
Passage en TLS dans la session
Un échange en clair précède TLS. Le scanner effectue cet échange, puis confie la connexion aux sondes TLS.
| Protocole | Port par défaut | Passage en TLS |
|---|---|---|
| SMTP (soumission) | 587 | EHLO, puis STARTTLS |
| IMAP | 143 | Commande STARTTLS |
| POP3 | 110 | Commande STLS |
| LDAP | 389 | Opération étendue StartTLS (RFC 4511) |
| FTP | 21 | AUTH TLS |
| XMPP | 5222 | En-tête de flux, puis <starttls/> |
| PostgreSQL | 5432 | SSLRequest |
| MySQL / MariaDB | 3306 | Handshake du serveur, vérification de la capacité SSL, puis requête SSL |
TLS sur le port du service
Ces services parlent TLS dès le premier octet quand TLS est activé, et en clair sinon. Il n'y a rien à négocier : le handshake TLS est le test lui-même.
| Service | Port par défaut | Remarque |
|---|---|---|
| MongoDB | 27017 | Même port avec ou sans TLS |
| Redis | 6379 | Même port avec ou sans TLS (Redis 6+) |
| Kafka | 9093 | Listener SSL dédié |
| AMQP (par ex. RabbitMQ) | 5671 | AMQPS ; 5672 est le port en clair |
| Cassandra | 9142 | Port TLS natif CQL |
SMTPS (465), IMAPS (993), POP3S (995) et LDAPS (636) parlent TLS dès le premier octet. Analysez-les plutôt avec une analyse de domaine / TLS sur ce port. Si vous pointez cette analyse sur l'un de ces ports, le résultat vous le signale au lieu de déclarer l'hôte injoignable.
Ce qui est rapporté
| Résultat | Ce qu’il vous apprend |
|---|---|
| Échange de clés post-quantique | Le groupe TLS 1.3 négocié par le serveur et s'il est post-quantique (par exemple l'hybride X25519MLKEM768), ainsi que les groupes post-quantiques et classiques acceptés. Un serveur uniquement classique est signalé pour que vous activiez un groupe hybride ; un serveur sans TLS 1.3 reçoit un « indéterminé » explicite plutôt qu'une supposition. |
| Configuration TLS | Version de TLS et suite de chiffrement négociées. TLS 1.2 est signalé car seul TLS 1.3 transporte un échange de clés hybride standardisé ; les versions antérieures à TLS 1.2 et les suites sans confidentialité persistante sont classées High. |
| Chaîne de certificats | Le certificat du serveur et sa chaîne, avec algorithmes et tailles de clés, inventoriés comme pour tout autre endpoint TLS. |
| Service en clair | Voir ci-dessous : un service qui refuse TLS est un résultat Critical. |
Le clair est un résultat, pas une erreur d'analyse
| Situation | Sévérité |
|---|---|
| Le serveur a répondu mais a refusé de passer en TLS (par exemple un serveur de messagerie qui ne propose pas STARTTLS) | Critical : le trafic vers ce serveur circule en clair |
| MongoDB ou Redis : le port accepte TCP mais aucun handshake TLS n’aboutit | Critical : ce même port transporte le trafic en clair |
| Kafka, AMQP ou Cassandra : le port TLS dédié accepte TCP mais aucun handshake TLS n’aboutit | High : le listener TLS est défaillant ; vérifiez que les clients ne se rabattent pas sur le port en clair |
| Le serveur a accepté le passage en TLS mais le handshake a échoué | Info : TLS est proposé, mais son certificat n’a pas pu être inventorié |
| L'hôte n'a pas répondu, ou a répondu comme un autre protocole | Info : vérifiez l'hôte, le port et les règles de pare-feu |
Chaque résultat est accompagné de recommandations : activer TLS, refuser les connexions clientes non chiffrées, passer à TLS 1.3 et configurer un échange de clés hybride post-quantique. Le trafic des bases, des files et de la messagerie a une longue durée de vie et est souvent archivé, ce qui le place pleinement dans le périmètre « récolter maintenant, déchiffrer plus tard ».
Quand l'utiliser
Messagerie et annuaire
Répondre à : notre trafic de messagerie et LDAP est-il vulnérable au quantique, voire simplement chiffré ?
Bases et files de messages
Trouver les endpoints de bases de données et de files qui servent en clair ou sans échange de clés post-quantique
Comment lancer l'analyse
Depuis le Cockpit
Ouvrir Lancer une analyse
Dans le Cockpit, accédez à Lancer une analyse.
Choisir la source
À l'étape 1 (Source), choisissez Services de messagerie, d'annuaire et de données.
Configurer et lancer
Saisissez un ou plusieurs hôtes (séparés par des virgules), choisissez le protocole et, si besoin, modifiez le port. Lancez l'analyse et consultez les résultats.
L'analyse part du Cockpit : les cibles doivent donc être joignables depuis celui-ci. Pour des services sur un réseau interne, lancez l'analyse avec l'agent de scan à l'intérieur de ce réseau (voir ci-dessous).
Via l'API
curl -X POST "$COCKPIT/api/pqc/scans" \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d '{
"scan_type": "starttls",
"target": "mail1.example.com,mail2.example.com",
"options": { "starttls_protocol": "smtp" }
}'
| Option | Description | Défaut |
|---|---|---|
starttls_protocol | smtp, imap, pop3, ldap, ftp, xmpp, postgres, mysql, mongodb, redis, cassandra, kafka ou amqp | smtp |
port | Port TCP | Port par défaut du protocole (tableaux ci-dessus) |
timeout_seconds | Délai par étape | 10 |
starttls_no_pq_probe | Ignorer la sonde d'échange de clés post-quantique. Ouvre beaucoup moins de connexions par hôte, mais le résultat n'a pas de verdict post-quantique | false |
Avec l'agent de scan (CLI)
# Serveurs de soumission de messagerie
dke-scanner-agent starttls --target mail1.example.com,mail2.example.com --protocol smtp
# Un serveur PostgreSQL sur un port non standard, résumé lisible
dke-scanner-agent starttls --target db.internal.example.com --protocol postgres --port 6432 --format summary
# Brokers Kafka, JSON écrit dans un fichier
dke-scanner-agent starttls --target kafka1,kafka2,kafka3 --protocol kafka -o kafka-tls.json
Toutes les options figurent dans la référence CLI.
Depuis un assistant IA (MCP)
Le serveur MCP du Cockpit expose un outil scan_starttls avec les mêmes paramètres (target, protocol, port, skip_pq_probe), jusqu'à 64 hôtes par appel. Voir MCP.
Beaucoup d'hôtes à analyser ? Combinez cette analyse avec une analyse de domaine de vos endpoints HTTPS : les verdicts d'échange de clés utilisent la même sonde, les résultats s'alignent donc dans le même inventaire et le même Quantum Risk Score.