Outil de diagnostic de version du protocole TLS

Saisissez un nom de domaine pour vérifier les versions TLS (1.0 à 1.3) prises en charge. Vérifiez gratuitement si votre serveur autorise encore des versions obsolètes.

Qu'est-ce que le diagnostic de version TLS ?

TLS (Transport Layer Security) est le protocole qui chiffre les échanges entre un site web et le navigateur de ses visiteurs, empêchant l'interception ou la falsification des données en transit. Il existe actuellement quatre versions en circulation : TLS 1.0, 1.1, 1.2 et 1.3. Les versions 1.0 et 1.1, en raison de vulnérabilités connues comme les attaques BEAST et POODLE, ont été formellement dépréciées par l'IETF en 2021 — mais rien ne les désactive automatiquement : elles restent actives sur un serveur tant que son administrateur ne l'a pas fait explicitement. Cet outil vous permet de saisir un nom de domaine et de diagnostiquer, depuis l'extérieur, les versions que le serveur accepte réellement.

Le mécanisme est simple à comprendre : l'outil tente une poignée de main TLS sur le port 443 (HTTPS) en imposant explicitement chaque version, de 1.0 à 1.3, l'une après l'autre, puis enregistre si la connexion aboutit ou échoue pour chacune d'elles. Il n'examine ni le contenu ni la validité du certificat — il se concentre uniquement sur les versions de protocole que le serveur est disposé à négocier. Cette approche ciblée en fait un outil idéal pour s'auto-évaluer face à des exigences d'audit externe telles que la norme PCI DSS (norme de sécurité de l'industrie des cartes de paiement), qui impose de désactiver les protocoles jugés obsolètes.

Comment utiliser le diagnostic de version TLS

  1. Saisissez le nom de domaine à vérifier Indiquez simplement le domaine, par exemple example.com, sans préfixe https:// ni chemin d'accès particulier.
  2. Lancez le diagnostic Cliquez sur le bouton « Diagnostiquer » : l'outil tente une poignée de main pour TLS 1.0, 1.1, 1.2 et 1.3 sur le port 443.
  3. Consultez le tableau de résultats par version Chaque version affiche « connexion possible » ou « connexion impossible (désactivé) » selon le résultat de la négociation.
  4. Repérez le verdict global Le statut Bon, Attention ou Danger vous permet de juger d'un coup d'œil si la configuration mérite votre attention.
  5. Corrigez la configuration si nécessaire Désactivez les versions obsolètes encore actives, ou soupçonnez une erreur de configuration si aucune version moderne n'est prise en charge, puis contactez votre administrateur serveur ou hébergeur.

Astuces pour en tirer le meilleur parti

  • La norme PCI DSS (sécurité de l'industrie des cartes de paiement) exige depuis 2018 la désactivation de TLS 1.0/1.1, jugés « protocoles insuffisamment sécurisés ». Les sites traitant des paiements devraient vérifier cela en priorité.
  • Contrairement à un vérificateur de certificat SSL, qui examine la date d'expiration et l'émetteur d'un certificat, cet outil diagnostique la configuration au niveau du protocole lui-même — les versions que le serveur est prêt à négocier. Utiliser les deux ensemble donne une vue plus complète.
  • Laisser TLS 1.0/1.1 activé n'interrompt pas immédiatement le trafic habituel, mais les principaux navigateurs tendent de plus en plus à les rejeter par défaut, donc les désactiver tôt réduit les risques de compatibilité futurs.
  • À l'inverse, si TLS 1.2 et 1.3 sont tous deux désactivés, cela suggère fortement une erreur de configuration, car les navigateurs modernes pourraient ne pas pouvoir se connecter du tout — traitez ce cas en priorité absolue.
  • Si votre site fonctionne sur un hébergement mutualisé ou derrière un CDN, les paramètres de version TLS sont généralement contrôlés par l'hébergeur ; signalez tout problème détecté à son support technique.

Scénarios d'utilisation

Vérification après une migration de serveur

Changer d'hébergeur ou mettre à jour le système d'exploitation peut réinitialiser silencieusement les paramètres TLS aux valeurs par défaut. Un diagnostic en fin de migration permet de s'assurer que rien n'a régressé.

Préparation à un audit de sécurité

Avant un audit ou une évaluation de vulnérabilités, vérifier à l'avance que les protocoles obsolètes sont bien désactivés permet de réduire le nombre de constats relevés par l'auditeur.

Auto-contrôle de conformité PCI DSS

Les sites traitant des paiements doivent, selon la norme PCI DSS, désactiver TLS 1.0/1.1. Un auto-contrôle régulier entre deux audits formels permet de détecter tout écart rapidement.

Vérification d'un site e-commerce ou d'espace membres

Les sites qui manipulent des données personnelles ou bancaires ont le plus à perdre d'un protocole obsolète négligé ; un contrôle régulier y est particulièrement recommandé.

Audit de plusieurs domaines à la fois

Si vous gérez plusieurs sous-domaines ou sites apparentés, diagnostiquer chacun d'eux permet de révéler des incohérences de configuration entre eux.

Glossaire

TLS
Transport Layer Security, le protocole qui chiffre les échanges entre un site web et un navigateur. Les versions actuellement en usage actif sont 1.2 et 1.3 ; l'icône de cadenas affichée dans la barre d'adresse du navigateur signale que TLS est bien en place.
SSL
Le prédécesseur de TLS. SSL 2.0 et 3.0 présentaient des défauts de conception fondamentaux et ont depuis été remplacés par TLS, bien que le nom « SSL » reste couramment employé par habitude (on parle encore, par exemple, de « certificat SSL »).
Poignée de main (handshake)
La négociation qu'un client et un serveur effectuent avant de démarrer une communication chiffrée, afin de s'accorder sur la version de TLS et la suite cryptographique à utiliser. C'est précisément cette négociation que cet outil vérifie pour chaque version.
Suite cryptographique (cipher suite)
La combinaison d'algorithmes utilisée pour l'échange de clés, le chiffrement et la détection d'altération des données. Les suites disponibles diffèrent selon la version de TLS ; TLS 1.3 supprime entièrement les options les plus anciennes et vulnérables.
PCI DSS
La norme de sécurité applicable aux organisations qui traitent des données de cartes bancaires. Depuis 2018, elle impose la désactivation de TLS 1.0/1.1, jugés « protocoles insuffisamment sécurisés ».
Attaque de rétrogradation (downgrade attack)
Une technique d'attaque qui pousse une connexion à utiliser, en cours de négociation, une version de protocole plus ancienne et plus faible. Laisser des versions obsolètes activées offre un point d'appui à ce type d'attaque.
Obsolète / déprécié
Un statut indiquant qu'une norme n'est plus formellement recommandée. TLS 1.0/1.1 ont été formellement dépréciés par l'IETF en 2021, mais continuent de fonctionner tant qu'un administrateur serveur ne les désactive pas explicitement.

Questions fréquentes

TLS 1.0, normalisé en 1999, est un protocole ancien affecté par des faiblesses cryptographiques exploitées par des attaques telles que BEAST et POODLE. La norme PCI DSS a imposé l'abandon de TLS 1.0/1.1 avant fin juin 2018, et les principaux navigateurs en retirent progressivement la prise en charge depuis.

Il suffit de saisir votre domaine dans cet outil. Il tente une véritable poignée de main pour chaque version de TLS 1.0 à 1.3 et indique lesquelles réussissent, sans nécessiter d'outils en ligne de commande comme openssl.

Des systèmes d'exploitation et navigateurs très anciens (comme le navigateur par défaut de Windows XP) pourraient perdre l'accès, mais tous les navigateurs et systèmes d'exploitation courants actuels prennent déjà en charge TLS 1.2 ou une version supérieure, donc l'impact pratique reste généralement limité.

TLS 1.3, normalisé en 2018, offre des poignées de main plus rapides et une sélection de suites cryptographiques plus simple et plus sûre. TLS 1.2 ne présente lui non plus aucune faille critique connue, si bien qu'une approche courante consiste à activer les deux : les clients récents utilisent 1.3 tandis que les plus anciens se rabattent sur 1.2.

Cet outil ne diagnostique que la prise en charge de la version du protocole. Pour vérifier la date d'expiration, l'émetteur ou les entrées SAN du certificat, utilisez le vérificateur de certificat SSL de la même catégorie.
Tool-kun

Anecdote — L'évolution des versions de TLS et de leurs vulnérabilités

SSL, le prédécesseur de TLS, a été développé par Netscape au milieu des années 1990, mais SSL 2.0 comme 3.0 présentaient des défauts de conception fondamentaux. TLS 1.0, normalisé en 1999 en tant que successeur de SSL 3.0, souffrait encore, dans certaines implémentations, d'un traitement incorrect des vecteurs d'initialisation dans les chiffrements en mode CBC — une faiblesse démontrée par l'attaque BEAST en 2011.

En 2014, l'attaque POODLE a révélé un défaut de conception dans SSL 3.0 lui-même, et l'inquiétude s'est rapidement étendue à TLS 1.0/1.1, d'architecture similaire. La norme PCI DSS a annoncé en 2015 une interdiction progressive de TLS 1.0 et fixé juin 2018 comme échéance finale pour une migration complète hors de TLS 1.1 et des versions inférieures.

TLS 1.3, normalisé en 2018, a tiré les leçons de ces vulnérabilités passées en supprimant de la spécification les suites cryptographiques propices aux faiblesses (comme RC4 et les chiffrements par blocs en mode CBC) et en réduisant le nombre d'allers-retours de la poignée de main. Aujourd'hui, la plupart des grands navigateurs et logiciels serveurs activent TLS 1.3 par défaut et ont déjà abandonné la prise en charge de TLS 1.0/1.1.

Malgré cela, il existe encore dans le monde des serveurs dépendant de systèmes anciens, et il n'est pas rare de trouver TLS 1.0/1.1 laissé activé sans que personne ne s'en aperçoive. Rendre visible d'un coup d'œil une configuration que les administrateurs peuvent facilement négliger, c'est précisément la valeur qu'apporte un outil de diagnostic comme celui-ci.