Versions de TLS, suites cryptographiques et confidentialité persistante parfaite

TLS (Transport Layer Security) est le protocole cryptographique qui sécurise la majorité des communications Internet — HTTPS, SMTPS, IMAPS, LDAPS et les VPN reposent tous sur TLS. TLS fournit trois propriétés de sécurité : la confidentialité (le chiffrement empêche l'écoute), l'intégrité (le MAC empêche les altérations) et l'authentification (les certificats vérifient l'identité du serveur). TLS a évolué à partir de SSL (Secure Sockets Layer), qui est désormais obsolète. Les versions actuelles sont TLS 1.2 (largement déployée) et TLS 1.3 (plus rapide et plus sécurisée, recommandée pour tout nouveau déploiement).

TLS a connu plusieurs versions, dont les plus anciennes contiennent des vulnérabilités critiques. SSL 2.0/3.0 : obsolètes et vulnérables aux attaques POODLE et DROWN. TLS 1.0 : déclaré obsolète par NIST et PCI-DSS en 2020 (vulnérable à BEAST et à POODLE avec les chiffrements par blocs). TLS 1.1 : déclaré obsolète en même temps que TLS 1.0. TLS 1.2 : norme minimale actuelle, sécurisée lorsqu'elle est correctement configurée avec des suites de chiffrement robustes. TLS 1.3 : publiée en 2018 ; supprime tous les algorithmes faibles, impose la confidentialité persistante, accélère considérablement la négociation (1-RTT au lieu de 2-RTT) et empêche les attaques par rétrogradation. PCI-DSS 4.0 exige au minimum TLS 1.2 et recommande TLS 1.3.

Une suite de chiffrement est un ensemble d'algorithmes cryptographiques utilisés conjointement dans une session TLS. Chaque suite de chiffrement précise : un algorithme d'échange de clés (la manière dont les clés de session sont établies), un algorithme d'authentification (la manière dont le serveur est vérifié), un algorithme de chiffrement en masse (celui qui chiffre les données) et un algorithme de code d'authentification de message (MAC) (la manière dont l'intégrité est vérifiée). Le client et le serveur négocient la suite de chiffrement à utiliser pendant la négociation TLS ; le serveur sélectionne la suite la plus robuste prise en charge par les deux parties.

La phase d'échange de clés établit la clé de session sans la transmettre. Échange de clés RSA (TLS 1.2) : le client chiffre un secret prém maître avec la clé publique du serveur ; si la clé privée est compromise ultérieurement, toutes les sessions passées peuvent être déchiffrées. DHE (Diffie-Hellman Ephemeral) : génère une nouvelle paire de clés pour chaque session ; assure la confidentialité persistante, mais est lent. ECDHE (Elliptic Curve DHE) : offre la même confidentialité persistante que DHE, mais avec des clés plus courtes et de meilleures performances ; il s'agit de l'échange de clés privilégié dans TLS 1.2 comme dans TLS 1.3. TLS 1.3 impose ECDHE ou DHE et supprime entièrement l'échange de clés RSA.

La confidentialité persistante parfaite (PFS) garantit que même si la clé privée à long terme du serveur est compromise ultérieurement, les sessions enregistrées précédemment ne peuvent pas être déchiffrées. La PFS est obtenue grâce à l'échange de clés éphémères (ECDHE ou DHE), qui génère une nouvelle paire de clés temporaire pour chaque session et la supprime après utilisation. Sans PFS (échange de clés RSA), un attaquant peut enregistrer aujourd'hui toutes les sessions TLS chiffrées, puis les déchiffrer rétroactivement lorsqu'il obtient finalement la clé privée. La stratégie de surveillance « collecter maintenant, déchiffrer plus tard » de la NSA part du principe que les cibles passeront finalement à des clés plus robustes ou que des ordinateurs quantiques finiront par casser les clés actuelles.

Plusieurs composants de chiffrement hérités sont cassés sur le plan cryptographique et doivent être désactivés. Chiffrements NULL : aucun chiffrement. Chiffrements de niveau export (attaque FREAK) : volontairement affaiblis pour respecter les réglementations américaines sur l'exportation des années 1990. RC4 : chiffrement par flot présentant des biais statistiques exploités lors d'attaques. DES et 3DES : chiffrements par blocs dont la taille de bloc est trop petite (attaque SWEET32) ou dont les longueurs de clé sont insuffisantes. MD5 et SHA-1 pour les MAC : vulnérabilités liées aux collisions. Chiffrements anonymes (aNULL) : aucune authentification du serveur. Les configurations TLS modernes devraient uniquement autoriser AES-GCM, ChaCha20-Poly1305, AES-CCM comme chiffrements en masse.

TLS 1.3 apporte plusieurs améliorations importantes en matière de sécurité par rapport à TLS 1.2. PFS obligatoire : l'échange de clés RSA est supprimé ; toutes les sessions utilisent ECDHE ou DHE. Moins de suites de chiffrement : seules 5 suites de chiffrement AEAD sont autorisées ; aucune négociation de chiffrement faible n'est possible. Négociation plus rapide : un aller-retour (1-RTT) contre 2-RTT avec TLS 1.2, et 0-RTT pour la reprise de session (bien que 0-RTT présente des risques d'attaque par rejeu). Négociation chiffrée : le certificat du serveur est chiffré pendant la négociation, ce qui empêche les observateurs passifs d'identifier le certificat utilisé et donc le site auquel le client se connecte.

Les attaques par rétrogradation trompent un serveur et un client TLS afin qu'ils utilisent une version de TLS ou une suite de chiffrement plus ancienne et plus faible que celle que tous deux prennent en charge. POODLE (Padding Oracle On Downgraded Legacy Encryption) exploitait le fait que les implémentations de TLS revenaient à SSL 3.0 en cas d'erreurs de connexion. La mesure corrective consistait à désactiver SSL 3.0. FREAK et Logjam exploitaient les chiffrements de niveau export. TLS_FALLBACK_SCSV est une pseudo-suite de chiffrement que les clients incluent pour signaler « il ne s'agit pas de ma version préférée » ; si un serveur la détecte et prend en charge une version supérieure, il interrompt la tentative de rétrogradation.

L'authentification du serveur TLS repose sur la vérification, par le client, de la chaîne de certificats jusqu'à une autorité racine CA approuvée. Vérifications essentielles : expiration (le certificat doit être dans sa période de validité), révocation (la vérification CRL ou OCSP confirme que le certificat n'est pas révoqué), nom d'hôte (le SAN ou le CN doit correspondre au domaine auquel la connexion est établie) et chaîne de signatures (les signatures de l'autorité CA intermédiaire et de l'autorité CA racine sont valides). La transparence des certificats (CT) exige que tous les certificats approuvés publiquement soient consignés dans des journaux CT auxquels on ne peut qu'ajouter des entrées, ce qui permet de détecter les certificats mal émis quelques minutes après leur émission.

Qualys SSL Labs (ssllabs.com/ssltest) est l'outil de référence pour évaluer la configuration TLS d'un serveur web. Il attribue une note allant de A+ (excellente) à F (problèmes critiques) en fonction des éléments suivants : versions de TLS prises en charge, robustesse des suites de chiffrement, validité du certificat, configuration HSTS, prise en charge de la confidentialité persistante et résistance aux attaques connues. Une note A+ exige : TLS 1.2 ou version ultérieure uniquement, tous les chiffrements ECDHE, un certificat valide et HSTS avec préchargement. Les organisations devraient effectuer des tests SSL Labs après la configuration initiale, puis après toute modification de la pile TLS. De nombreux référentiels de conformité (PCI-DSS) exigent des évaluations périodiques de la configuration TLS.

Les certificats TLS expirés provoquent des interruptions de service et des avertissements de confiance qui peuvent être exploités par des attaquants. La gestion du cycle de vie des certificats comprend : le suivi de tous les certificats dans un inventaire de certificats, la configuration d'alertes d'expiration au moins 30 jours avant l'expiration, l'automatisation du renouvellement avec le protocole ACME (Let's Encrypt, Certbot), l'utilisation de durées de validité courtes (90 jours pour les certificats publics) afin de réduire la fenêtre de risque en cas de compromission, et l'utilisation prudente de certificats génériques (*.example.com), car la compromission d'un certificat générique affecte tous les sous-domaines. Les plateformes de gestion des certificats (Venafi, DigiCert CertCentral) automatisent la découverte et la gestion du cycle de vie dans les grands inventaires de certificats.

Testez votre compréhension des concepts de CompTIA Security+ (SY0-701) abordés dans cette leçon.

Dans cette leçon, vous avez appris que TLS 1.0/1.1 sont obsolètes et que TLS 1.2 constitue la norme minimale, tandis que TLS 1.3 est préférable avec une PFS obligatoire et des négociations chiffrées, que les suites de chiffrement précisent l'échange de clés (privilégier ECDHE), le chiffrement en masse (AES-GCM, ChaCha20) et les algorithmes MAC, et que la confidentialité persistante parfaite nécessite un échange de clés éphémères (DHE/ECDHE) afin que les sessions passées ne puissent pas être déchiffrées, même après une compromission de clé. Nous allons maintenant étudier le DNS sécurisé : DNSSEC et DNS sur HTTPS.