Suites de chiffrement TLS : le registre IANA complet

Qu'est-ce qu'une suite de chiffrement TLS ?

Une suite de chiffrement est un ensemble nommé de choix cryptographiques qu'un client et un serveur TLS s'accordent pendant la poignée de main : comment ils établissent une clé partagée, comment ils s'authentifient, et comment ils chiffrent et authentifient les données qui suivent. Chaque ensemble porte un identifiant de deux octets, et l'IANA en tient le registre.

Ce registre compte 448 entrées. 356 sont des suites nommées ; le reste sont des plages non attribuées et des valeurs réservées. Les noms se lisent comme une spécification parce qu'ils en sont une : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 annonce un Diffie-Hellman éphémère sur courbe elliptique pour l'échange de clés, RSA pour l'authentification, AES-128 en mode GCM pour les données et SHA-256 pour la poignée de main. TLS 1.3 les a raccourcis : il a retiré du nom l'échange de clés et l'authentification, si bien que TLS_AES_128_GCM_SHA256 ne nomme plus que la protection des enregistrements.

Le registre porte en outre une colonne appelée Recommended, et c'est à cause d'elle que cette page existe. Presque tous les tableaux que l'on trouve la reproduisent sous forme de coche ou de croix. Elle compte quatre valeurs, et la différence entre deux d'entre elles est précisément ce que l'on comprend de travers.

Comment l'utiliser

1. Collez un identifiant dans n'importe quelle écriture : 0x13,0x01 comme dans le registre, 1301 depuis une capture réseau, 13 01 ou 13:01 depuis un fichier de configuration. Vous obtenez le nom de la suite, son marquage, si DTLS peut l'employer, et des liens vers les RFC qui la définissent.
2. Ou cherchez par nom : tapez CHACHA20, ou GCM, ou un numéro de RFC. Le tableau en dessous n'affiche par défaut que les suites nommées ; une case à cocher ramène aussi les entrées réservées et non attribuées.
3. Lisez le marquage comme une déclaration, pas comme une note : chaque résultat explicite le sens de sa lettre avec les mots employés par la RFC qui la définit, car c'est la version courte qui induit en erreur.

La colonne Recommended compte quatre valeurs

La RFC 8447 a créé la colonne, et la RFC 9847 l'a amendée en décembre 2025 pour qu'elle porte quatre valeurs. Y signifie recommandée, et la modifier dans un sens ou dans l'autre exige une action de normalisation de l'IETF. D signifie découragée — la RFC 9847 y voit le marquage d'un algorithme cryptographique faible, ou susceptible de poser des problèmes d'interopérabilité en déploiement. Le vide sert aux valeurs non attribuées ou réservées.

N est celle qui trompe. Selon les mots mêmes de la RFC, elle signifie que l'IETF n'a pas évalué l'élément et ne s'est pas prononcé sur sa pertinence — et le texte précise explicitement que cela ne veut pas nécessairement dire que le mécanisme est défectueux, seulement qu'aucun consensus n'existe. N est l'absence d'avis. C'est ce que reçoit par défaut tout ce que personne n'a fait passer par le processus.

Cette distinction est exactement la raison d'être du D. Avant qu'il existe, le N portait les deux sens à la fois : rien à dire, et c'est une mauvaise idée. Les séparer était l'objet de l'amendement de 2025, et en juillet 2026 la RFC 10015 a basculé un large bloc de méthodes d'échange de clés de N vers D. Tout tableau publié avant ces dates diverge de celui-ci, et la divergence n'est pas une coquille.

Compté aujourd'hui : sur les 356 suites nommées, 14 sont recommandées, 248 sont découragées et 94 ne font l'objet d'aucune prise de position. Moins de quatre pour cent portent un Y, et cet ensemble se résume aux suites de TLS 1.3 plus les suites ECDHE à chiffrement AEAD.

Les lettres ne classent pas la robustesse

Voici la paire qui tranche. TLS_RSA_WITH_3DES_EDE_CBC_SHA — pas de confidentialité persistante, un chiffrement par blocs de 64 bits, un algorithme à la retraite depuis longtemps — porte un D. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA — échange de clés éphémère, AES — porte un N.

Lue comme un classement, la colonne affirme que la suite en 3DES est la mieux considérée des deux, ce qui est absurde. Lue correctement, elle dit tout autre chose : l'IETF a activement découragé la première et ne s'est tout simplement jamais prononcé sur la seconde. Ce sont des affirmations sur le processus de normalisation, pas des mesures de robustesse cryptographique, et aucun plissement des yeux ne transforme l'une en l'autre.

C'est pourquoi l'outil détaille le sens sur chaque résultat au lieu d'afficher une pastille. Une pastille est un classement, que ce soit voulu ou non.

Les entrées qui ne sont pas des suites

Soixante-neuf entrées sont des plages non attribuées et sept sont réservées, mais seize méritent d'être connues une par une. Ce sont les valeurs GREASE, enregistrées par la RFC 8701, et elles existent pour ne rien signifier. Leurs identifiants ont tous la forme 0x0A,0x0A, 0x1A,0x1A et ainsi de suite, et les clients les envoient exprès, en attendant des serveurs qu'ils les ignorent.

Le but est d'empêcher le protocole de se scléroser. Si les implémentations ne voient jamais que les valeurs existant aujourd'hui, certaines se mettront discrètement à rejeter tout le reste, et la prochaine véritable extension deviendra indéployable. Envoyer des valeurs dénuées de sens maintient chaque implémentation honnête quant à ignorer ce qu'elle ne reconnaît pas. En chercher une ici la renvoie comme GREASE plutôt que comme inconnue, car qui trouve 0x1A,0x1A dans une capture mérite une réponse.

Ce que cette page ne fera pas

Elle ne vous dira pas quelles suites activer. Cela dépend de ce que vos clients gèrent, du régime de conformité dont vous relevez et de ce que votre bibliothèque TLS met réellement en œuvre — et le registre ne répond à aucune de ces questions. Il consigne ce que l'IETF a dit de chaque entrée, et cette page le rapporte fidèlement au lieu de le convertir en une configuration à coller quelque part.

C'est aussi un instantané. Le registre gagne des entrées et les marquages changent ; deux des trois RFC qui définissent cette colonne ont moins d'un an, ce qui en dit long sur sa vivacité. Tout ce que vous lisez ici au sujet d'une suite précise mérite d'être confirmé auprès de l'IANA avant d'entrer dans une politique.

Enfin, qu'une suite soit enregistrée ne dit rien de sa prise en charge par votre logiciel, et qu'elle soit recommandée ne dit rien de la solidité du reste de votre configuration. L'essentiel des vrais problèmes TLS tient aux certificats, aux versions du protocole et aux tailles de clés, pas à la liste des suites de chiffrement.

Pourquoi est-ce gratuit ?

Le registre entier tient en quelques kilo-octets livrés avec la page et consultés dans votre navigateur. Rien de ce que vous tapez n'est envoyé, rien n'est journalisé, et il n'y a aucun compte à créer.

Sans inscription, sans limite, et sans filigrane sur ce que vous copiez.