Defaults.Exposed › Corrections › Chiffrement moderne (version TLS et suites de chiffrement)

Comment corriger Chiffrement moderne (version TLS et suites de chiffrement)

Le TLS est la serrure qui brouille les données circulant entre vos visiteurs et votre site web. Deux choses rendent cette serrure fiable : utiliser une version moderne de TLS (pas les anciennes, cassées) et utiliser des suites de chiffrement robustes (la recette de brouillage proprement dite). Cette page couvre les deux — plus quelques réglages connexes qui n'affectent pas votre note mais valent la peine d'être connus.

En clair, pour votre entreprise : Si votre site tourne sur un chiffrement dépassé ou des suites de chiffrement faibles, les informations privées que vos clients saisissent — identifiants, numéros de carte, coordonnées — peuvent être discrètement interceptées et lues sur les réseaux partagés, et vous pouvez échouer aux contrôles de sécurité que les banques, prestataires de paiement et clients plus importants exigent désormais avant de faire affaire avec vous.

Ce que cela peut vous coûter

• Un client paie ou se connecte via le Wi-Fi d'un hôtel ou d'un café, une connexion dépassée ou une suite de chiffrement faible laisse un inconnu de ce réseau lire sa carte et son mot de passe, et la fraude — et l'appel furieux — remonte droit jusqu'à votre site.
• Vous demandez à accepter les paiements par carte (ou votre prestataire vous réaudite) et essuyez un refus parce qu'un TLS dépassé ou une suite de chiffrement bannie enfreint les règles de sécurité des paiements — votre commande en ligne est gelée jusqu'à correction.
• L'équipe informatique d'un client plus important effectue un scan de sécurité de routine avant de signer, voit que votre site autorise encore un chiffrement cassé, et vous signale comme un risque — le contrat cale pour un problème qui ne coûte rien à corriger.
• Une plainte ou une violation liée à la protection des données atterrit sur votre bureau et la première question des régulateurs est de savoir si vous avez protégé les données clients « de façon appropriée » — faire tourner un chiffrement publiquement connu comme cassé depuis des années est une réponse très difficile à donner.
• Votre site affiche un cadenas, donc tout le monde le croit parfaitement sûr, et cette lacune passe inaperçue des années — jusqu'à ce qu'un seul identifiant ou numéro de carte intercepté se transforme en incident bien plus coûteux que ne l'aurait été la correction gratuite.

Pourquoi c'est important. Un chiffrement sûr est invisible ; un chiffrement dépassé ou faible est une bombe à retardement qui dort tranquillement jusqu'au jour où elle vous coûte un client, un contrat ou un passage de conformité. Les contrôles de version TLS et de suite de chiffrement sont les deux volets qui font réellement bouger votre note, et tous deux relèvent généralement d'un seul réglage gratuit — il n'y a aucun intérêt à laisser activées les anciennes options cassées.

En clair

Quand quelqu’un visite votre site web, tout ce qu’il saisit — identifiants, numéros de carte, noms, numéros de téléphone, messages — est brouillé en transit pour que des inconnus ne puissent pas le lire. La technologie qui assure le brouillage s’appelle TLS (vous l’entendrez aussi appeler SSL, son ancien nom). Pour que ce brouillage soit réellement sûr, deux choses doivent être correctes :

1. La version TLS — quelle génération de la technologie vous utilisez. Les premières versions (TLS 1.0 et 1.1) sont publiquement cassées depuis des années ; les sûres sont TLS 1.2 et TLS 1.3.
2. La suite de chiffrement — la recette précise que TLS utilise pour brouiller. Certaines suites (comme RC4, DES et 3DES) ont été cassées et sont désormais bannies ; les suites modernes restent robustes.

Cette page couvre les deux, car un site peut avoir l’un correct et l’autre erroné. Vous pouvez avoir une serrure moderne avec une vieille recette cassable encore activée — ou une recette robuste protégée par une serrure dépassée. L’une comme l’autre est une porte ouverte. Les deux se ferment généralement par le même unique changement gratuit des réglages de votre serveur ou hébergement.

Ce que cela peut vous coûter

• Un client dévalisé sur le Wi-Fi public. Quelqu’un se connecte à son compte ou paie depuis un hôtel, un café ou un aéroport. Comme votre site autorise encore une ancienne version TLS ou une suite de chiffrement faible, un inconnu sur ce même réseau force la connexion vers l’option cassable et lit son mot de passe et son numéro de carte en temps réel. La fraude retombe sur le client, mais le blâme — et l’appel à l’assistance — retombe sur vous.
• Vos paiements par carte sont coupés. Les règles de sécurité des paiements (PCI DSS) exigent TLS 1.2 au minimum et bannissent explicitement les suites faibles comme RC4. Quand votre prestataire vous réaudite, ou quand vous demandez à accepter les cartes, une configuration dépassée échoue au contrôle et votre commande est gelée jusqu’à correction — exactement au mauvais moment pour la trésorerie.
• Une affaire cale en revue de sécurité. Avant qu’un client plus important signe, son équipe informatique effectue un scan de routine. Il signale immédiatement que votre site accepte encore un chiffrement cassé — le genre de constat qui paraît négligent et fait se demander à l’acheteur ce qui traîne d’autre. Le contrat reste dans les limbes pour un problème qui ne coûte rien à corriger.
• Un régulateur pose la question gênante. Après toute plainte ou violation, la première chose qu’une autorité de protection des données veut savoir est si vous avez protégé les données personnelles « de façon appropriée ». Faire tourner un chiffrement publiquement connu comme cassé depuis des années est très difficile à défendre, et « nous n’avions pas réalisé que l’ancienne version était encore activée » n’est pas une réponse confortable.
• Cela se cache derrière le cadenas pendant des années. Comme votre site affiche encore un cadenas normal, personne ne remarque la lacune — jusqu’à ce qu’un seul identifiant ou numéro de carte intercepté devienne un incident public bien plus coûteux que ne l’aurait été la correction de cinq minutes.

Ce que c’est réellement

La version TLS

Un site ne prend pas en charge qu’une seule version de TLS — il peut en proposer plusieurs à la fois et laisser le navigateur de chaque visiteur choisir. Un visiteur moderne utilisera la version la plus récente disponible et verra un cadenas normal. Le danger, c’est que les anciennes versions cassées peuvent rester là, à côté des bonnes, comme une porte dérobée ouverte : un attaquant peut forcer la connexion d’un visiteur à « rétrograder » vers TLS 1.0 ou 1.1 puis exploiter les faiblesses connues de ces versions (les attaques BEAST et POODLE en sont les exemples célèbres) pour déchiffrer le trafic.

Notre contrôle se connecte donc à votre site et teste chaque version individuellement — TLS 1.0, 1.1, 1.2 et 1.3 — pour voir lesquelles votre serveur accepte encore. Voici à quoi ressemble le « bon » réglage et comment il se note :

• TLS 1.3 (avec ou sans 1.2), et aucune version héritée : le meilleur résultat — une configuration moderne et propre. Note maximale.
• TLS 1.2 seul, sans 1.3 : sûr et réussi, mais vous laissez de côté la version la plus récente et la plus rapide. Quasiment toute la note ; activer 1.3 vaut la peine.
• TLS 1.0 ou 1.1 encore accepté : un échec automatique, noté zéro et signalé comme critique — peu importe que 1.2/1.3 fonctionnent aussi, car les versions cassées sont la porte ouverte. C’est ce que vous devez corriger.

La suite de chiffrement

Une fois une version choisie, TLS sélectionne une suite de chiffrement — l’algorithme proprement dit qui brouille les données. La plupart des suites modernes sont robustes. Une poignée sont cassées et ne doivent jamais être utilisées : RC4 (son brouillage est biaisé et laisse fuir le texte en clair), DES (sa clé est si courte qu’elle peut être cassée par force brute), 3DES (vulnérable à l’attaque « Sweet32 »), plus NULL (aucun chiffrement du tout), les suites de qualité EXPORT (délibérément affaiblies — les attaques FREAK et Logjam), et les suites anonymes (aucun contrôle d’identité, donc un imposteur peut se placer au milieu).

Notre contrôle des suites fait deux choses. D’abord, il regarde la suite que votre serveur a réellement négociée avec nous. Ensuite — et c’est la partie importante — il tente activement une poignée de mains avec plusieurs suites connues comme cassées (RC4, 3DES, EXPORT, NULL et variantes anonymes). Un serveur peut choisir une suite robuste en parlant à un client moderne tout en acceptant une suite faible si un attaquant insiste — et c’est un vrai risque de rétrogradation. Si votre serveur accepte une suite bannie, le contrôle le signale ; accepter une suite critique (comme RC4 ou NULL) est un échec. (En TLS 1.3, il n’y a rien à craindre ici — cette version a supprimé par conception toutes les suites faibles, donc les sondes sont ignorées.)

Les trois extras informatifs

Trois éléments connexes sont rapportés mais n’affectent pas votre note — ils sont signalés comme informatifs parce qu’ils ne peuvent pas être vérifiés de façon fiable depuis l’extérieur, et que sur tout serveur ou CDN moderne ils sont déjà gérés correctement :

• La compression TLS (l’attaque CRIME) : une vieille fonctionnalité qui, si elle est laissée activée, pourrait permettre à un attaquant d’extraire des cookies de session. Elle est désactivée par défaut sur tout serveur web moderne depuis plus d’une décennie, donc c’est aujourd’hui un non-problème.
• L’agrafage OCSP : un avantage de performance et de confidentialité où votre serveur récupère à l’avance la preuve que son certificat n’a pas été révoqué, pour que chaque visiteur n’ait pas à le demander lui-même à l’autorité de certification (ce qui est plus lent et révèle des données de navigation). Les CDN comme Cloudflare le font automatiquement.
• La renégociation sécurisée : un correctif pour une vieille faille (CVE-2009-3555) qui permettait aux attaquants d’injecter des données dans une session. TLS 1.3 a entièrement supprimé la renégociation, donc c’est un non-problème là, et les serveurs TLS 1.2 modernes implémentent le correctif par défaut.

Nous les faisons remonter pour que votre informaticien ait le tableau complet, mais pour la grande majorité des propriétaires il n’y a rien à faire — votre score est déterminé par les contrôles de version et de suite ci-dessus.

Comment corriger (gratuit, ~30 minutes)

Transmettez ceci à votre informaticien — la correction est gratuite. Cette section est destinée à la personne qui gère votre domaine, votre site web ou votre hébergement. La correction est une modification de configuration, pas un achat ; nous facturons uniquement la surveillance du maintien d’un chiffrement correctement configuré dans le temps. L’unique configuration moderne ci-dessous corrige d’un coup les constats de version et de suite.

L’approche fiable la plus simple est de générer une configuration éprouvée plutôt que d’en écrire une à la main : collez votre type de serveur dans le générateur de configuration SSL de Mozilla sur https://ssl-config.mozilla.org/ et choisissez le profil « Intermediate » (large compatibilité) ou « Modern » (TLS 1.3 uniquement, si vous n’avez pas besoin de prendre en charge quoi que ce soit d’ancien). Il produit pour vous les lignes ssl_protocols et ssl_ciphers correctes.

Par plateforme :

1. Cloudflare ou un hébergeur managé — généralement un ou deux clics. Dans Cloudflare : SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.2, et les suites de chiffrement y sont gérées pour vous (la plateforme ne proposera pas de suites bannies). La plupart des hébergeurs managés et créateurs de sites (Squarespace, Wix, Shopify, hébergeurs WordPress modernes) imposent déjà TLS 1.2+ avec des suites robustes — confirmez simplement qu’aucune option « TLS hérité » ou « compatibilité ancien navigateur » n’est encore activée.
2. Nginx. Réglez les versions modernes uniquement et une liste de suites robustes explicite, puis rechargez :

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
   ssl_prefer_server_ciphers on;
   

   (TLS 1.3 nécessite OpenSSL 1.1.1+ sur la machine.)
3. Apache. Désactivez les anciennes versions et fixez une liste de suites robustes, puis redémarrez :

   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
   SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
   SSLHonorCipherOrder on
   

4. Windows / IIS. Utilisez l’outil gratuit IIS Crypto (ou les réglages de registre équivalents) pour désactiver TLS 1.0 et 1.1, désactiver les suites RC4/DES/3DES/NULL/EXPORT, et laisser TLS 1.2 et 1.3 avec des suites robustes activées. Le modèle « Best Practices » de l’outil fait tout cela en un clic.
5. Les extras informatifs (optionnel, gratuit). Si vous voulez le grand nettoyage : sur Nginx ajoutez ssl_stapling on; ssl_stapling_verify on; (avec une ligne resolver) pour l’agrafage OCSP ; sur Apache, SSLUseStapling On. La compression TLS et la renégociation sécurisée sont déjà sûres par défaut sur les serveurs modernes — aucune action nécessaire. Sur Cloudflare, les trois sont gérés automatiquement.
6. Vérifiez, puis recontrôlez ici. Confirmez que seules les versions et suites sûres subsistent — par exemple avec nmap --script ssl-enum-ciphers -p 443 votredomaine.com, ou testez avec les outils liés sur https://ssl-config.mozilla.org/ — puis relancez ce contrôle. Quand c’est possible, activez TLS 1.3 à côté de 1.2 : il est à la fois plus rapide et plus sûr.

Erreurs fréquentes

• « Nous avons un cadenas, donc tout va bien. » Le cadenas prouve seulement qu’une connexion sécurisée existe. Il ne dit rien sur le fait qu’une ancienne version ou une suite bannie soit encore acceptée en arrière-plan — ce qui est précisément la lacune que ces contrôles trouvent.
• Corriger la version mais pas les suites (ou l’inverse). Désactiver TLS 1.0/1.1 ne supprime pas automatiquement RC4 ou 3DES, et fixer des suites robustes ne désactive pas automatiquement les anciennes versions. Réglez les deux — la configuration générée ci-dessus le fait.
• Laisser activés les boutons « hérité » ou « compatibilité ancien navigateur ». Beaucoup d’hébergeurs et de CDN ont une option qui réactive discrètement les versions cassées ou les suites faibles « pour la compatibilité ». Elle n’aide presque jamais un vrai visiteur et provoque directement ce constat.
• Oublier de réellement recharger/redémarrer le serveur. Les modifications de configuration ne prennent effet qu’une fois le serveur web rechargé — une raison étonnamment fréquente pour qu’un site « corrigé » échoue toujours au recontrôle.
• Configurer un serveur mais pas tous. Si vous avez un répartiteur de charge, plusieurs serveurs web, ou des sous-domaines distincts (boutique, blog, app), chaque point d’extrémité TLS a besoin de la même configuration — c’est le plus faible que vise un attaquant.

Ce qu’il faut retenir

La version TLS et la suite de chiffrement sont les deux volets de votre chiffrement qui font réellement bouger votre note, et tous deux se résument à désactiver des options cassées publiquement depuis des années. La correction est gratuite, c’est généralement une ligne de configuration moderne par serveur, et pour un visiteur ordinaire elle ne change rien sinon rendre sa connexion véritablement sûre. Les éléments connexes — compression, agrafage OCSP, renégociation sécurisée — valent la peine d’être connus mais n’affecteront pas votre score, et sur toute configuration moderne ils sont déjà gérés pour vous.

FAQ