Ce que vérifie cet outil
Un serveur TLS peut être configuré pour accepter une plage de versions de protocole et de suites de chiffrement, mais une seule connexion ne révèle jamais que ce qui a été négocié pour cette poignée de main — généralement l'option la plus récente et la plus robuste supportée par les deux parties. Cet outil fixe délibérément chaque connexion à une version de protocole précise à la fois (de TLSv1 à TLSv1.3), pour dresser la carte de tout ce que le serveur est configuré pour accepter, pas seulement ce qu'il préfère utiliser.
Pourquoi une matrice de support compte plus qu'un résultat unique
Un serveur peut présenter une connexion TLSv1.3 parfaitement moderne à votre navigateur tout en acceptant encore silencieusement TLSv1.0 d'un client — ou d'un attaquant — qui le demande spécifiquement. C'est une surface d'attaque par rétrogradation : si un protocole ou chiffrement obsolète est encore accepté, il reste exploitable indépendamment de ce que les clients modernes utilisent réellement au quotidien. Configurer un serveur pour rejeter purement et simplement les anciens protocoles (pas seulement les déprioriser) est le seul moyen de fermer complètement cette porte.
Ce que signifie « non testé », et pourquoi ce n'est pas un faux négatif
Tester une version de protocole précise implique de forcer une connexion que de nombreux serveurs modernes refuseront simplement de tenter au niveau TCP pour les anciennes versions, et un véritable incident réseau (un délai dépassé, un paquet perdu) ressemble de l'extérieur exactement à cela. Cet outil distingue les deux cas : un rejet actif signifie « non supporté » (le résultat informatif recherché), tandis qu'une défaillance d'infrastructure est signalée comme « non testé » — à retenter, pas une preuve dans un sens ou dans l'autre.