Le protocole TLS (Transport Layer Security) sécurise les communications sur les réseaux informatiques en chiffrant les données échangées entre les clients et les serveurs. L'analyse des configurations TLS, souvent obtenue par des outils de diagnostic ou des captures de paquets, permet de valider la robustesse de cette sécurité. Le traitement des données soumises à cet outil s'effectue localement: les renseignements TLS collés demeurent dans votre navigateur, et l'application ne les téléverse pas et ne les conserve pas.
Analyse des protocoles et des suites de chiffrement
L'évaluation d'une connexion TLS repose sur l'identification des versions du protocole et des suites de chiffrement configurées ou négociées lors de la prise de contact (handshake). Les outils d'analyse textuelle permettent d'extraire ces informations à partir de journaux de serveurs, de sorties de commandes ou de rapports de numérisation.
Rôles des paramètres identifiés
Lors de l'inspection des données textuelles, les éléments détectés sont classés selon leur rôle fonctionnel au sein de la session TLS:
- Négocié: Représente la version du protocole ou la suite de chiffrement effectivement sélectionnée et validée par les deux parties pour sécuriser la session.
- Offert: Correspond aux options proposées par le client dans son message initial (ClientHello).
- Observé: Indique les paramètres détectés lors de l'observation passive ou active d'un échange.
Évaluation de la sécurité des suites
Chaque suite de chiffrement identifiée reçoit une évaluation de sécurité basée sur les standards actuels:
- Moderne: Suites conformes aux exigences de sécurité contemporaines, utilisant des algorithmes robustes.
- Examen: Suites nécessitant une attention particulière ou une validation selon le contexte d'utilisation.
- Obsolète: Algorithmes ou configurations qui ne répondent plus aux critères de sécurité minimaux et doivent être désactivés.
- Inconnu: Suites non répertoriées dans la base de référence locale.
Algorithmes obsolètes et vulnérabilités courantes
L'analyse des suites de chiffrement permet de détecter la présence d'algorithmes historiques présentant des faiblesses cryptographiques avérées. Le tableau suivant récapitule les constatations associées aux algorithmes non sécurisés ou dépréciés:
| Algorithme ou configuration | Constat de sécurité |
|---|---|
| RC4 | RC4 est obsolète et ne doit pas être négocié. |
| DES | DES n'est pas sécurisé pour une utilisation générale du TLS. |
| 3DES | 3DES a une petite taille de bloc et est obsolète pour TLS. |
| Chiffrement NULL | Le cryptage NULL n’assure pas la confidentialité. |
| Suites EXPORT | Les suites EXPORT utilisent intentionnellement une cryptographie faible et sont obsolètes. |
| Suites anonymes | Les suites anonymes n'authentifient pas l'homologue et sont vulnérables à l'interception. |
| MD5 | MD5 n’est pas sécurisé pour une utilisation générale de TLS. |
| SHA-1 | Cette suite utilise SHA-1, qui est obsolète pour une utilisation générale de TLS. |
| Suites CBC | Les suites CBC sont héritées. Préférez une suite AEAD comme AES-GCM ou ChaCha20-Poly1305. |
| Échange RSA statique | L’échange de clés statique RSA ne fournit pas de confidentialité transmise. |
| CCM-8 | CCM-8 utilise une balise d'authentification plus courte et nécessite un examen spécifique au protocole. |
Spécificités de TLS 1.3 et gestion des clés
Le protocole TLS 1.3 a profondément modifié la structure des suites de chiffrement par rapport aux versions antérieures (TLS 1.2 et antérieures). Dans les versions précédentes, la suite de chiffrement définissait à la fois l'algorithme d'échange de clés, le mécanisme d'authentification, le chiffrement symétrique et la fonction de hachage.
Avec TLS 1.3, la négociation est segmentée: TLS 1.3 négocie l'échange de clés et l'authentification séparément de la suite de chiffrement. Par conséquent, le nom d'une suite TLS 1.3 ne contient que les indications relatives au chiffrement des enregistrements et au hachage de la prise de contact. Les mécanismes d'échange de clés (comme ECDHE ou DHE) et d'authentification (comme RSA ou ECDSA) sont négociés via des extensions distinctes lors du handshake et ne peuvent pas être déduits de la seule lecture de la suite de chiffrement.
Interprétation des formats et limites de l'analyse statique
L'analyseur traite les données textuelles issues de diverses sources techniques, telles que les sorties de la commande openssl s_client, les rapports de scanners de vulnérabilités ou les résumés de paquets réseau. Il prend en charge les noms standardisés par l'IANA, les alias utilisés par la bibliothèque OpenSSL ainsi que les identifiants hexadécimaux des suites de chiffrement.
Règles de validation et messages d'erreur
Le traitement du texte soumis obéit à des règles strictes pour garantir la pertinence des résultats:
- Si le champ de saisie est vide, l'outil affiche le message: « Collez d'abord un résumé d'analyse ou de prise de contact TLS. »
- Si la taille du texte dépasse la limite maximale de traitement, le message suivant apparaît: « Ce résumé est inhabituellement volumineux. Gardez-le sous 200 000 caractères. »
- Si le texte ne contient aucun élément identifiable, l'outil renvoie: « Aucune version ou suite de chiffrement de TLS n'a été reconnue. Collez les champs lisibles du scanner ou de la négociation. »
- En l'absence de protocole spécifique détecté dans un texte par ailleurs valide, la mention suivante est générée: « Aucune version du protocole n'a été trouvée dans le texte fourni. »
- Si aucune suite de chiffrement n'est extraite, le système indique: « Aucune suite de chiffrement n'a été trouvée dans le texte fourni. »
- Pour les suites non répertoriées dans la base de données interne, le système affiche: « Cette suite ne figure pas dans la carte des suites communes intégrée. Consultez la documentation actuelle du registre ou du scanner IANA. »
Il convient de noter que cet outil effectue uniquement une analyse statique du texte fourni. Il ne réalise aucune connexion réseau vers un hôte externe, ne valide pas la chaîne de certification, ne mesure pas la longueur réelle des clés publiques et ne peut pas tester la résistance du serveur aux attaques de rétrogradation (downgrade).
FAQ
Quels formats de sortie TLS puis-je coller? Collez le texte des scanners TLS courants, openssl s_client, des résumés d'analyse de paquets ou une courte note ClientHello ou ServerHello. Le vérificateur reconnaît les noms IANA courants, les alias OpenSSL et plusieurs identifiants de suite hexadécimaux courants; il ne décode pas les octets bruts des paquets.
Pourquoi une suite de chiffrement TLS 1.3 n'affiche-t-elle pas RSA ou ECDHE? Les noms des suites de chiffrement TLS 1.3 décrivent le chiffrement des enregistrements et le hachage de la prise de contact. L'échange de clés et l'authentification sont négociés séparément, ils ne peuvent donc pas être déduits du seul nom d'une suite.
Ce résultat prouve-t-il qu'un serveur est sécurisé? Non, cela explique uniquement le texte que vous collez. Il ne se connecte pas à l'hôte, ne vérifie pas le certificat, ne mesure pas la taille des clés, ne teste pas le comportement de rétrogradation et n'affiche pas toutes les suites acceptées par le serveur.