Analyse et interprétation des données de négociation TLS
L'analyse des configurations de sécurité des serveurs web repose souvent sur l'examen de rapports textuels issus de scanners de vulnérabilités ou de captures de flux réseau. Le traitement manuel de ces données s'avère complexe en raison de la diversité des formats de notation des suites de chiffrement, qui varient selon les outils entre les dénominations de l'IANA, les alias d'OpenSSL ou les identifiants hexadécimaux.
Le traitement de ces informations s'effectue localement afin de garantir la confidentialité des données d'infrastructure. Les données soumises restent dans le navigateur et ne font l'objet d'aucun transfert ni d'aucun enregistrement sur un serveur externe.
Protocoles et suites de chiffrement: principes de reconnaissance
L'analyse textuelle permet d'extraire et de classifier les composants d'une négociation TLS selon des rôles précis et des niveaux de sécurité définis.
Identification des rôles des paramètres
Lors d'une négociation TLS, les protocoles et les suites de chiffrement identifiés se voient attribuer un rôle spécifique selon le contexte extrait du texte:
- Négocié: Le protocole ou la suite de chiffrement final choisi d'un commun accord par le client et le serveur pour sécuriser la session.
- Offert: Les options proposées par le client dans son message ClientHello.
- Observé: Les paramètres détectés lors de l'analyse des échanges sans distinction stricte de négociation.
Évaluation de la sécurité des suites de chiffrement
Chaque suite de chiffrement identifiée est classée selon quatre niveaux d'évaluation technique:
- Moderne: Algorithmes robustes et conformes aux exigences de sécurité actuelles.
- Examen: Configurations nécessitant une attention particulière ou une analyse de contexte spécifique.
- Obsolète: Algorithmes dépassés dont l'usage est fortement déconseillé ou interdit.
- Inconnu: Suite non répertoriée dans la base de correspondance locale.
Algorithmes obsolètes et vulnérabilités associées
L'analyse des suites de chiffrement permet de détecter la présence d'algorithmes anciens ou affaiblis qui compromettent la sécurité des échanges.
| Algorithme ou configuration | Évaluation et risques associés |
|---|---|
| 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 de clés 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 mécanismes d'échange
Le protocole TLS 1.3 a profondément modifié la structure des suites de chiffrement par rapport aux versions précédentes (TLS 1.2 et antérieures).
Dans les versions antérieures, le nom d'une suite de chiffrement englobait l'ensemble des algorithmes nécessaires à la session: l'échange de clés (par exemple, ECDHE ou RSA), l'authentification (par exemple, RSA ou ECDSA), le chiffrement symétrique (par exemple, AES-GCM) et le hachage pour le PRF (par exemple, SHA256).
Avec TLS 1.3, la négociation de l'échange de clés et de l'authentification s'effectue de manière totalement indépendante de la suite de chiffrement. Par conséquent, les suites TLS 1.3 ne contiennent plus que les indications relatives au chiffrement des enregistrements et au hachage de la prise de contact (par exemple, TLS_AES_256_GCM_SHA384). Les mécanismes d'échange de clés et d'authentification ne peuvent donc pas être déduits du seul nom de la suite de chiffrement.
Limites de l'analyse statique des données TLS
L'analyse de texte présente des caractéristiques strictement statiques qu'il convient de distinguer d'un audit actif:
- Absence de connexion réseau: L'analyse s'effectue uniquement sur la base du texte fourni. Aucun paquet n'est envoyé sur le réseau, et aucune tentative de connexion n'est initiée vers un hôte distant.
- Pas de validation de certificat: L'outil ne valide pas la chaîne de certification, la date de validité ou la révocation des certificats du serveur.
- Pas de mesure de taille de clé: Les longueurs réelles des clés publiques utilisées lors d'une session active ne peuvent pas être mesurées à partir du simple nom de la suite.
- Pas de test de rétrogradation: L'analyse ne permet pas de vérifier si le serveur est vulnérable aux attaques de rétrogradation (downgrade attacks).
- Vision partielle: Seuls les éléments explicitement présents dans le texte soumis sont analysés. Les suites de chiffrement supportées par le serveur mais absentes du rapport restent inconnues.
Gestion des erreurs et limites de saisie
Pour garantir un traitement optimal, la soumission des données doit respecter certaines règles structurelles:
- Limite de taille: Le texte soumis ne doit pas dépasser 200 000 caractères. En cas de dépassement, le message d'erreur suivant s'affiche: "Ce résumé est inhabituellement volumineux. Gardez-le sous 200 000 caractères."
- Saisie vide: Si l'analyse est lancée sans texte préalable, l'outil affiche: "Collez d'abord un résumé d'analyse ou de prise de contact TLS."
- Absence de correspondance: Si le texte ne contient aucun élément identifiable, le message d'erreur est: "Aucune version ou suite de chiffrement de TLS n'a été reconnue. Collez les champs lisibles du scanner ou de la négociation."
- Données non structurées: Les fichiers binaires bruts ou les fichiers de capture de paquets (pcap) ne sont pas pris en charge. Le texte doit être lisible et issu de scanners ou de commandes telles que
openssl s_client.
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.