Sélecteur de versions TLS et de ciphers

Comment ce sélecteur de versions TLS et de ciphers décide quoi activer

Ce sélecteur de versions TLS et de ciphers s'appuie sur le SSL Configuration Generator de Mozilla, juste tiré jusqu'en 2026. La logique tourne autour de deux boutons et d'un veto. Le profil de sécurité que tu vises. L'audience que tu ne peux pas casser. Puis la compliance, qui écrase discrètement ton choix si une règle l'exige. Quoi que tu lui donnes, la sortie a toujours la même forme : un jeu fixe de versions de TLS, de cipher suites et une ligne HSTS, déposés dans la directive exacte que ton serveur attend vraiment. Pas besoin de deviner la syntaxe.

Honnêtement, si tu hésites, prends Intermediate (TLS 1.2 + 1.3) et passe à autre chose. C'est la bonne réponse pour à peu près tout site public en 2026 qui n'a pas un legacy bizarre braqué sur la tempe. Chaque attaque concrète sur la couche TLS ? Bloquée. Chaque navigateur des sept dernières années environ ? Toujours fonctionnel. Mozilla, l'IETF, le NIST et PCI-DSS 4.0 pointent tous vers ce niveau comme plancher raisonnable. Modern (TLS 1.3 uniquement), c'est pour les API et les trucs internes où tu maîtrises tous les clients. Et Old, c'est la sortie de secours « bon, j'ai vraiment besoin d'IE11 ou d'Android 4 », avec la matrice qui te détaille exactement ce que tu sacrifies, histoire de ne pas avancer à l'aveugle.

Pourquoi TLS 1.0 et 1.1 ne sont plus acceptables

Ils sont vieux. TLS 1.0 date de 1999, TLS 1.1 de 2006, et l'IETF les a officiellement enterrés en mars 2021 (RFC 8996). Les navigateurs d'aujourd'hui refusent même de les négocier : Chrome 84+, Firefox 78+, Safari 14+, Edge 84+, tous les rejettent par défaut. PCI-DSS a arrêté d'accepter TLS 1.0 sur un endpoint de traitement de carte dès juin 2018. POODLE en 2014, SWEET32 en 2016, c'étaient deux vraies attaques fonctionnelles sur les modes de chiffrement de TLS 1.0, pas de la théorie. Donc en 2026, il n'existe tout simplement aucune version de « réactiver TLS 1.0 sur un endpoint public » qui finisse bien. Même le cas legacy est mieux servi par un endpoint legacy séparé, avec une date de mise à mort écrite quelque part.

TLS 1.2, c'est une autre histoire, et je pense que c'est là que les gens se prennent les pieds dans le tapis. C'est encore tout à fait correct en 2026, parce que le numéro de version n'a jamais été ce qui te protégeait. C'est ton cipher (AES-GCM, ChaCha20-Poly1305) et ton key exchange (ECDHE) qui assurent la défense. TLS 1.2 n'est que l'enveloppe dans laquelle ils voyagent. Quand un scanner pointe « TLS 1.2 » comme le problème, creuse un peu et c'est presque toujours la mauvaise compagnie qu'il fréquente : 3DES, RC4, les modes CBC boulonnés à HMAC-SHA1. Choisis Modern ou Intermediate ici et tout ça saute pour toi, sans chirurgie manuelle de la cipher string.

Le choix des cipher suites en 2026

La base de référence 2026 se résume vraiment à une poignée d'éléments mobiles. Le key exchange, c'est ECDHE sur X25519 ou P-256. L'authentification, c'est RSA-2048 ou ECDSA-P256, signé avec SHA-256 ou SHA-384. Et le chiffrement de masse, c'est l'un de AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305. Tout ce qui n'est pas sur cette courte liste dégage : RSA key exchange, static DH, les modes AES-CBC, tout ce qui touche à MD5 ou SHA1, RC4, 3DES, le vieux bric-à-brac EXPORT. Modern taille encore plus dur, jusqu'aux seuls ciphers AEAD (AES-GCM et ChaCha20-Poly1305) sur TLS 1.3 uniquement, ce qui est une façon brutale de faire en sorte qu'aucune faiblesse connue ne soit même une option.

Un mot sur ChaCha20-Poly1305, parce qu'il est sous-estimé. Sur mobile, c'est un gain discret. Les puces ARM sans hardware AES (pense au vieil Android, à pas mal d'IoT) le digèrent peut-être 2 à 3 fois plus vite que l'AES-GCM. Les navigateurs le savent déjà et le réclament quand le client annonce qu'il n'a pas d'accélération AES. Donc place-le devant l'AES-GCM dans ton ordre. Une petite modif, un vrai gain de vitesse côté mobile, et tes utilisateurs desktop ne voient aucune différence.

Les contraintes de compliance qui changent la sortie

Choisis un référentiel et l'outil plie discrètement la sortie pour coller à ses règles. PCI-DSS 4.0 veut TLS 1.2 comme plancher (1.3 si tu peux), interdit tout cipher en dessous de 112 bits de force réelle, et exige que tu écrives une procédure d'exception pour le moindre endpoint TLS 1.0/1.1 qui traîne encore en boitant en pleine migration. HIPAA, qui s'en remet surtout au NIST SP 800-52 Rev. 2, demande TLS 1.2 minimum, une préférence cipher côté serveur, plus un véritable inventaire des services qui parlent seulement TLS. FIPS 140-3 est le tatillon : uniquement des algorithmes approuvés FIPS, donc ChaCha20-Poly1305 est hors-jeu et l'AES-GCM ne compte qu'avec la bonne implémentation derrière. Et il lui faut un module crypto validé, ce qui veut dire que la bibliothèque TLS de ton OS doit figurer sur la liste FIPS, point barre. NIST SP 800-52 Rev. 2 est la base de référence du secteur public. Il reflète surtout Intermediate, puis ajoute par-dessus des exigences plus strictes sur l'OCSP stapling et le préchargement HSTS.

Comment déployer la config générée sans danger

Générer la config, c'est facile. La livrer sans pulvériser le trafic en prod, c'est là que les gens se brûlent. Donc vas-y doucement. Mets-la en place quelque part qui n'est pas la prod, lance le test Qualys SSL Labs, et vérifie que la note tombe là où tu la voulais (A+ pour Modern, A pour Intermediate). Seulement après, tu la pousses. La partie HSTS mérite une vraie prudence : commence avec un max-age minuscule, disons 600 secondes, laisse reposer une journée entière, surveille la moindre casse, et seulement après tu montes vers un an. Ne te précipite pas non plus sur la preload list. Attends un mois d'uptime ennuyeux et sans histoire d'abord, parce que se retirer de cette liste plus tard prend des semaines et c'est pénible. Ah, et mets une alarme à J-30 avant l'expiration sur ton certificat. Je vais être direct : la panne TLS numéro un en 2026, c'est encore un pauvre type qui oublie de renouveler un certificat. C'en est presque drôle. Ça l'est nettement moins quand c'est toi.

Questions fréquentes

Est-ce que je peux faire du TLS 1.3 only sans rien casser ?

Ça dépend de qui frappe à la porte. Sur du trafic public, tu perdrais Chrome avant la 70, Firefox avant la 63, Safari avant la 14, tout navigateur Android plus ancien que la version 10, toute la famille IE, les clients Java avant 11.0.3, et la plupart du matériel IoT d'avant 2019. Alors va regarder tes analytics. Si vraiment aucun de ceux-là n'apparaît, bien sûr, le TLS 1.3 only est le choix propre. S'ils apparaissent, lance plutôt Intermediate (TLS 1.2 + 1.3). Les mêmes clients modernes, mais ça rattrape la longue traîne que tu aurais sinon discrètement exclue.

Je devrais préférer l'ordre des ciphers côté serveur ou côté client ?

Pour TLS 1.2, va côté serveur. C'est ssl_prefer_server_ciphers on sur nginx. Pour TLS 1.3, ça n'a quasiment aucune importance. La liste de ciphers est courte, la préférence serveur et la préférence client te donnent la même sécurité dans les deux cas, et en pratique les deux bouts atterrissent souvent sur le même premier choix de toute façon. Donc je ne perdrais pas le sommeil sur le cas 1.3.

Est-ce que j'ai besoin de l'OCSP stapling ?

Oui, active-le. Le stapling permet à ton serveur de fournir lui-même le statut de révocation du certificat, ce qui économise un aller-retour vers la CA à chaque nouvelle connexion. Active-le (ssl_stapling on sur nginx) et pointe-le vers un resolver. Si tu l'oublies, les navigateurs font l'une de deux choses peu réjouissantes : ils haussent les épaules et arrêtent carrément de vérifier la révocation, ou ils font traîner la connexion pendant qu'une CA poussive prend son temps.

Et les certificats ECDSA face au RSA ?

Va vers ECDSA-P256. C'est plus rapide, et la clé publique est minuscule à côté du RSA, environ 80 octets contre 320. En 2026, c'est juste le choix par défaut sensé. Le hic, c'est que quelques clients legacy têtus exigent encore du RSA-2048, donc pas mal de machines en prod servent simplement les deux avec un setup à double certificat et n'en parlent plus. Choisis Intermediate et l'outil écrit ces directives pour toi.

À quelle fréquence je devrais régénérer cette config ?

Une fois par an, au strict minimum. Et aussi à chaque fois qu'une CVE liée à TLS tombe (il y en a eu environ 4 par an entre 2020 et 2025), et à chaque fois que tu changes de serveur web. C'est calme en 2026, mais ne t'installe pas trop confortablement. La migration post-quantique démarre autour de 2027 à 2028 avec Kyber et Dilithium, donc note dès maintenant une vraie remise à plat de la couche TLS pour cette fenêtre et tu ne te feras pas prendre de court.