TLS/SSL

01 — DéfinitionQu'est-ce que TLS ?

TLS (Transport Layer Security) est le protocole cryptographique standard qui sécurise la majorité des communications sur Internet. Il est spécifié par l'IETF (Internet Engineering Task Force) et constamment mis à jour.

Trois garanties de sécurité

• Confidentialité : les données sont chiffrées, personne ne peut les lire en transit.
• Intégrité : les données ne peuvent pas être modifiées sans détection (MAC, AEAD).
• Authenticité : le serveur est identifié via son certificat ; optionnellement le client aussi (mTLS).

TLS vs SSL

SSL (Secure Sockets Layer) est l'ancêtre de TLS, conçu par Netscape en 1995. Historique :

• SSL 1.0 (1994) : jamais publié — failles majeures.
• SSL 2.0 (1995) : vulnérable, déprécié dès 2011.
• SSL 3.0 (1996) : déprécié en 2015 suite à POODLE.
• TLS 1.0 (1999) : renommage + corrections. Successeur officiel SSL 3.0.
• Évolutions ensuite : TLS 1.1 (2006), TLS 1.2 (2008), TLS 1.3 (2018).

Aujourd'hui SSL est totalement obsolète et désactivé partout. Les termes « certificat SSL », « SSL/TLS » restent utilisés par habitude dans le langage commercial, mais techniquement seul TLS est en usage.

TLS au-delà du web

TLS est partout, pas seulement dans HTTPS :

• Web : HTTPS (HTTP sur TLS). Voir HTTPS.
• Emails : SMTPS (envoi sécurisé), IMAPS/POP3S (réception), TLS opportuniste en SMTP inter-serveurs.
• APIs : REST, GraphQL, gRPC (HTTP/2 avec TLS), WebSockets sécurisés.
• VPN : OpenVPN utilise TLS pour l'authentification et le handshake.
• Bases de données : PostgreSQL SSL, MySQL SSL, MongoDB TLS.
• Messageries : XMPP, IRC, Matrix tous avec TLS.
• IoT : MQTT-TLS, CoAP avec DTLS.
• Protocoles d'entreprise : LDAPS, FTPS, Kerberos, RADIUS over TLS.
• DoT/DoH : DNS sur TLS/HTTPS pour requêtes DNS sécurisées.

Architecture en couches

TLS opère entre la couche transport (TCP typiquement, UDP pour DTLS) et la couche application (HTTP, SMTP, etc.). Vu d'une application, TLS est transparent : elle écrit et lit sur un socket comme d'habitude, la bibliothèque TLS (OpenSSL, BoringSSL, LibreSSL, Rustls, schannel) gère le chiffrement.

Implémentations principales

• OpenSSL : la plus utilisée, mature, open source. Utilisée par Apache, Nginx, PHP, Python.
• BoringSSL : fork Google d'OpenSSL, utilisée par Chrome, Android, services Google.
• LibreSSL : fork OpenBSD, focus simplicité.
• Rustls : implémentation en Rust, sécurité mémoire par design. Adoption croissante.
• Schannel : implémentation Windows native.
• Secure Transport : implémentation Apple.
• NSS : utilisée par Firefox.
• mbed TLS : focus embarqué.
• GnuTLS : alternative GPL.

02 — VersionsÉvolution de SSL 2.0 à TLS 1.3

SSL 2.0 et 3.0 — obsolètes

Totalement dépréciés. SSL 2.0 interdit depuis 2011 (RFC 6176), SSL 3.0 depuis 2015 (RFC 7568). Désactivés dans tous les clients et serveurs modernes. Mentionnés uniquement pour contexte historique.

TLS 1.0 et 1.1 — dépréciés

Officiellement dépréciés par l'IETF en mars 2020 (RFC 8996). Chrome, Firefox, Safari, Edge ont supprimé le support en 2020-2021. Certains systèmes legacy peuvent encore les supporter mais ne devraient pas les exposer sur Internet. Raisons de la dépréciation :

• Primitives cryptographiques faibles ou absentes (SHA-1, pas d'AEAD).
• Vulnérabilités structurelles (BEAST sur CBC).
• Absence de support pour ECDHE performant moderne.
• Maintenance coûteuse comparée aux bénéfices.

TLS 1.2 — encore très utilisé

Publiée en 2008 (RFC 5246). Largement supportée et toujours considérée sûre avec une configuration correcte. Évolutions majeures par rapport aux versions antérieures :

• Support SHA-256 et fonctions de hash modernes.
• Support AEAD (AES-GCM, ChaCha20-Poly1305) — chiffrement et authentification combinés.
• Suites cryptographiques avec PFS (Perfect Forward Secrecy) via ECDHE.
• Flexibilité de configuration.

Piège : TLS 1.2 mal configuré (avec suites CBC, RSA key exchange, SHA-1) reste vulnérable. L'exigence moderne est TLS 1.2 avec suites AEAD + ECDHE uniquement.

TLS 1.3 — version moderne recommandée

Publiée en août 2018 (RFC 8446). Refonte majeure du protocole. Changements :

Simplification

• Suppression des primitives faibles : RC4, 3DES, RSA key exchange, CBC, MD5, SHA-1.
• Seulement 5 suites cryptographiques standardisées (vs dizaines en TLS 1.2).
• Moins de surface d'attaque, moins d'erreurs de configuration.

Performance

• 1-RTT handshake : 1 aller-retour au lieu de 2 pour TLS 1.2.
• 0-RTT optionnel : reprise de session sans aller-retour, pour reconnexions rapides (au prix d'un risque de replay).
• Gains mesurables sur les temps de connexion (~100 ms économisés).

Sécurité

• PFS obligatoire : ECDHE systématique, chaque session a sa propre clé.
• Chiffrement du handshake : certificat et paramètres post-ClientHello chiffrés.
• Signature moderne : ECDSA, EdDSA, RSA-PSS privilégiés.
• Résistance aux attaques de downgrade renforcée.

Adoption des versions

Chiffres approximatifs 2025-2026 (source SSL Pulse, Cloudflare Radar) :

• TLS 1.3 : ~65-70% des connexions.
• TLS 1.2 : ~30% des connexions.
• TLS 1.0/1.1, SSL : <1% — principalement systèmes legacy.

Futur — TLS post-quantique

Évolution en cours. Les ordinateurs quantiques pourront théoriquement casser ECDHE et RSA. Préparation :

• NIST a standardisé en 2024 : ML-KEM (Kyber) pour échange de clé, ML-DSA (Dilithium) pour signatures.
• Chrome : suite hybride X25519MLKEM768 activée par défaut en 2024 pour le handshake.
• Cloudflare, Google : support en production.
• Certificats post-quantiques : expérimentation en cours, déploiement progressif 2026-2030.
• ANSSI : guide post-quantique publié, recommandation transition pour données sensibles long terme.

L'enjeu : « harvest now, decrypt later » — les adversaires stockent du trafic chiffré aujourd'hui en vue de le déchiffrer plus tard quand les ordinateurs quantiques seront disponibles. Motivation pour passer tôt aux algorithmes résistants.

03 — HandshakeLa négociation de connexion

TLS 1.2 — 2 aller-retours

Séquence classique :

1. Client Hello : le client envoie versions supportées, suites cryptographiques, un nombre aléatoire, extensions (SNI, ALPN).
2. Server Hello : le serveur choisit la version et la suite, envoie son nombre aléatoire.
3. Certificate : le serveur envoie sa chaîne de certificats.
4. Server Key Exchange : pour ECDHE, le serveur envoie ses paramètres éphémères signés.
5. Server Hello Done : fin du premier tour.
6. Client Key Exchange : le client envoie ses paramètres ECDHE.
7. Change Cipher Spec + Finished (client) : passage au chiffrement, vérification de l'intégrité.
8. Change Cipher Spec + Finished (serveur) : confirmation.

Les deux parties ont maintenant les clés de session, peuvent échanger des données chiffrées.

TLS 1.3 — 1 aller-retour

Séquence optimisée :

1. Client Hello : le client envoie déjà ses paramètres ECDHE (Key Share), suites supportées, extensions.
2. Server Hello + Encrypted Extensions + Certificate + Certificate Verify + Finished : le serveur envoie tout d'un coup. À partir des Encrypted Extensions, tout est déjà chiffré avec les clés dérivées des ECDHE déjà partagés.
3. Finished client : vérification et confirmation.

Gain de performance : environ 100 ms économisés sur une connexion typique transatlantique. Pour des APIs avec beaucoup de petites connexions, l'impact est significatif.

Reprise de session et 0-RTT

Pour les reconnexions au même serveur :

• Session tickets : le serveur envoie un ticket chiffré au client, qui peut le réutiliser pour reprendre une session sans handshake complet.
• 0-RTT (Early Data) en TLS 1.3 : le client peut envoyer des données dès le premier paquet en utilisant la PSK (Pre-Shared Key) d'une session précédente. Gain : aucun aller-retour supplémentaire.
• Attention : les 0-RTT sont rejouables par un attaquant — usage restreint aux opérations idempotentes (GET HTTP, par exemple).

Extensions importantes

• SNI (Server Name Indication) : le client indique quel domaine il veut contacter. Permet l'hébergement HTTPS mutualisé. Problème : visible en clair pour un observateur.
• ECH (Encrypted Client Hello) : chiffre le SNI (et d'autres métadonnées). Déploiement en cours (Cloudflare, Google).
• ALPN (Application-Layer Protocol Negotiation) : négocie HTTP/1.1, HTTP/2, HTTP/3 pendant le handshake.
• OCSP Stapling : le serveur inclut la preuve de révocation OCSP, évitant au client de la demander lui-même.
• PSK : reprise de session.
• Signature Algorithms : liste des algorithmes de signature supportés.

Authentification mutuelle (mTLS)

TLS classique : le client vérifie le serveur seulement. mTLS : le serveur vérifie aussi le client via son propre certificat. Usages :

• Authentification machine-to-machine (microservices, APIs B2B).
• VPN d'entreprise.
• Accès aux ressources critiques (bases de données, services internes).
• Modèles Zero Trust : chaque appel authentifié cryptographiquement.
• Certaines plateformes (Kubernetes service mesh avec Istio/Linkerd) implémentent mTLS par défaut.

04 — CertificatsX.509 et infrastructure PKI

Qu'est-ce qu'un certificat X.509 ?

Un certificat numérique au format X.509 v3 est un document qui lie une clé publique à une identité (typiquement un nom de domaine), signé par une autorité de certification (CA). Structure simplifiée :

• Subject : l'identité du titulaire (CN = Common Name, O = Organization).
• Issuer : la CA qui a signé le certificat.
• Clé publique du titulaire.
• Dates de validité : Not Before / Not After.
• Numéro de série unique chez la CA.
• Extensions : Subject Alternative Name (liste de domaines), Extended Key Usage, CRL Distribution Points, Authority Information Access (OCSP).
• Signature de la CA sur l'ensemble.

Chaîne de confiance

Un certificat de site est signé par une autorité intermédiaire, elle-même signée par une autorité racine pré-installée dans les navigateurs et systèmes d'exploitation. Vérification :

1. Le navigateur reçoit la chaîne de certificats du serveur.
2. Il vérifie que chaque certificat est correctement signé par le suivant.
3. Il vérifie que la racine est dans son trust store.
4. Il vérifie que chaque certificat est en cours de validité et non révoqué.
5. Il vérifie que le domaine demandé correspond au Subject / SAN.

Trust stores

Chaque système maintient sa liste de racines de confiance :

• Mozilla : NSS Root Store, utilisée par Firefox, et largement répliquée ailleurs (Linux).
• Microsoft : Microsoft Trusted Root Program, utilisée par Windows et Edge.
• Apple : Apple Root Certificate Program, utilisée par macOS/iOS.
• Google : Chrome Root Store lancé en 2023 (auparavant Chrome utilisait le trust store de l'OS).
• ANSSI : liste française utilisée dans certains contextes gouvernementaux.

Ces programmes imposent des audits périodiques (WebTrust, ETSI) aux CAs. Une CA en défaut peut être expulsée — c'est arrivé à Symantec en 2018 (retrait progressif Chrome/Mozilla suite à des émissions improprement validées), à StartCom/WoSign en 2016.

Certificate Transparency

Standard RFC 9162 obligeant toute CA à publier les certificats émis dans des logs publics auditables. Impact :

• Chaque émission laisse une trace vérifiable.
• Propriétaires de domaines peuvent surveiller les émissions pour leur nom.
• Détection rapide d'une CA compromise ou d'une émission frauduleuse.
• Outils : crt.sh, Censys, Facebook CT Monitor (gratuit), Hardenize.

Conséquence directe du scandale DigiNotar (2011) qui a émis des certificats frauduleux pour Gmail utilisés contre des dissidents iraniens. CT est maintenant obligatoire pour qu'un certificat soit accepté par Chrome depuis 2018.

Révocation

Si un certificat est compromis (clé privée volée, émission frauduleuse), il doit être révoqué avant sa date d'expiration. Mécanismes :

• CRL (Certificate Revocation List) : liste des certificats révoqués publiée par la CA. Historique, peu scalable.
• OCSP (Online Certificate Status Protocol) : vérification en temps réel. Problèmes de privacy (la CA voit qui consulte quoi).
• OCSP Stapling : le serveur inclut la preuve OCSP signée récemment. Résout les problèmes de latence et de privacy.
• CRLite / CRLSets : Firefox et Chrome utilisent des listes compressées pré-téléchargées (Bloom filters) comme solutions modernes.

La révocation reste un point faible historique de la PKI. D'où la tendance à réduire la durée de validité des certificats (90 jours Let's Encrypt, 45 jours envisagés) — limite l'impact d'une compromission sans dépendre de la révocation.

Clés et algorithmes

• RSA 2048 : minimum recommandé. Encore majoritaire.
• RSA 3072 / 4096 : pour sécurité long terme, au prix de la performance.
• ECDSA P-256 : plus rapide que RSA à sécurité équivalente, tendance 2020+.
• ECDSA P-384 : pour niveaux de sécurité renforcés.
• Ed25519 / EdDSA : algorithmes modernes, supportés par TLS 1.3, performance excellente.
• Post-quantiques (Dilithium) : en expérimentation, déploiement progressif.

05 — Suites cryptographiques

Anatomie d'une suite TLS 1.2

Exemple : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• TLS : préfixe de protocole.
• ECDHE : échange de clés (Elliptic Curve Diffie-Hellman Éphémère — garantit PFS).
• RSA : authentification du serveur (type de certificat).
• AES_128_GCM : chiffrement symétrique (AES clé 128 bits, mode GCM = AEAD).
• SHA256 : fonction de hash pour la négociation.

Suites TLS 1.3 (simplifiées)

TLS 1.3 sépare authentification/échange de clés des suites. Cinq suites standardisées :

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

Plus de variations RSA, ECDSA, CBC, 3DES, MD5, SHA-1, etc. — simplification radicale qui élimine la plupart des configurations vulnérables.

Catégories à privilégier

• AEAD obligatoire : AES-GCM ou ChaCha20-Poly1305 — chiffrement et authentification combinés.
• ECDHE uniquement : PFS obligatoire.
• Hash SHA-256 minimum : SHA-1 et MD5 proscrits.
• Courbes : X25519, P-256, P-384 privilégiés.

Primitives à éviter absolument

• RC4 : cassé, interdit depuis 2015.
• 3DES : trop faible, déconseillé depuis 2016.
• DES : cassé depuis longtemps.
• CBC avec HMAC : vulnérable à plusieurs attaques (Lucky13, BEAST). Utiliser AEAD à la place.
• MD5, SHA-1 : collisions connues, dépréciés.
• Diffie-Hellman < 2048 bits : Logjam.
• Static RSA key exchange : pas de PFS, supprimé en TLS 1.3.
• NULL cipher : aucun chiffrement — existe pour tests uniquement.

Perfect Forward Secrecy (PFS)

Propriété essentielle : même si la clé privée long terme du serveur est compromise dans le futur, les sessions passées restent confidentielles. Obtenue via des échanges de clés éphémères (ECDHE, DHE).

Contre-exemple : l'ancien échange RSA non-éphémère ne fournit pas PFS — un attaquant qui capture le trafic et obtient plus tard la clé privée peut déchiffrer rétroactivement toutes les sessions.

En TLS 1.3, PFS est obligatoire — toutes les suites utilisent ECDHE ou (EC)DHE.

Générateurs de configuration

• Mozilla SSL Configuration Generator : ssl-config.mozilla.org. Génère configurations Nginx, Apache, HAProxy, AWS, selon profils Modern/Intermediate/Old.
• Cloudflare profils recommandés : publiés publiquement.
• ANSSI guide de mécanismes cryptographiques : référence française.

06 — VulnérabilitésIncidents historiques marquants

Heartbleed (avril 2014)

Vulnérabilité dans OpenSSL (CVE-2014-0160) affectant la fonctionnalité heartbeat de TLS. Permettait à un attaquant de lire la mémoire des serveurs via des requêtes heartbeat malformées, exposant potentiellement clés privées, mots de passe, tokens de session, données utilisateur. Impact :

• Centaines de milliers de serveurs affectés (environ 17% des serveurs SSL/TLS).
• Urgence mondiale de patch et renouvellement de clés/certificats.
• A révélé la fragilité de financement d'OpenSSL — projet critique mondialement, maintenu par quelques personnes.
• Conduit à la création de la Core Infrastructure Initiative (Linux Foundation) pour financer les projets open source critiques.
• BoringSSL (Google) et LibreSSL (OpenBSD) ont été forks en réaction.

Icône visuelle iconique (un cœur qui saigne), site heartbleed.com, l'un des bugs les plus médiatisés de l'histoire d'Internet.

POODLE (octobre 2014)

Padding Oracle On Downgraded Legacy Encryption (CVE-2014-3566). Exploitation du mode CBC en SSL 3.0 permettant à un attaquant MITM de déchiffrer des cookies de session. Impact :

• A signé l'arrêt définitif de SSL 3.0.
• Déprécié officiellement par l'IETF (RFC 7568, 2015).
• Désactivé partout dans les mois suivants.

BEAST (2011)

Browser Exploit Against SSL/TLS. Attaque contre le mode CBC en TLS 1.0 permettant de récupérer des cookies de session via JavaScript malveillant injecté. A accéléré la migration vers TLS 1.1+ et les suites RC4 (qui ont ensuite été elles-mêmes déconseillées).

Logjam (2015)

Affaiblissement de Diffie-Hellman en forçant l'usage de paramètres faibles (1024 bits ou moins). Impact :

• Environ 8% des sites HTTPS affectés au moment de la découverte.
• Des États-nations bien ressourcés pouvaient potentiellement précalculer les paramètres faibles communs.
• Migration vers DH 2048+ bits et ECDHE.

FREAK (2015)

Factoring RSA Export Keys. Downgrade forcé vers des cipher suites d'export (clés RSA 512 bits) encore supportées par des configurations legacy — héritage de restrictions d'exportation américaines des années 1990 qui avaient limité le chiffrement exporté. Impact : serveurs avec configurations legacy vulnérables, élimination progressive de ces suites.

DROWN (2016)

Decrypting RSA with Obsolete and Weakened eNcryption (CVE-2016-0800). Exploitation de serveurs supportant SSLv2 pour casser TLS sur le même serveur ou un autre utilisant la même clé. Impact : environ 33% des serveurs HTTPS potentiellement vulnérables, élimination définitive de SSLv2.

CRIME, BREACH, TIME (2012-2013)

Attaques exploitant la compression pour extraire des secrets (cookies, CSRF tokens). Conduisent à la désactivation de la compression TLS dans les navigateurs.

Raccoon (2020)

Timing attack sur Diffie-Hellman. Impact limité mais illustre la difficulté persistante de rendre les implémentations robustes aux attaques par canal auxiliaire.

Leçons de ces vulnérabilités

• Les primitives faibles doivent être supprimées agressivement, pas gardées pour compatibilité descendante.
• La complexité est ennemie de la sécurité — TLS 1.3 a drastiquement simplifié.
• Les implémentations comptent autant que le protocole : Heartbleed était un bug d'OpenSSL, pas de TLS.
• La cryptographie doit anticiper les attaques : préparation post-quantique alors que les ordinateurs quantiques n'existent pas encore commercialement.
• L'open source critique doit être financé : leçon Heartbleed retenue avec CII, Sovereign Tech Fund, etc.

07 — FAQQuestions fréquentes

Doit-on dire SSL ou TLS ?

Techniquement TLS est le terme correct pour tout ce qui est actuellement utilisé. SSL est obsolète depuis des années. En pratique : « certificat SSL » est employé commercialement par habitude — c'est un certificat TLS. « SSL/TLS » est accepté comme forme transitoire. Dans la communication avec des utilisateurs non-techniques, SSL peut rester plus familier. Dans la documentation technique, il est préférable d'utiliser TLS pour précision. Les standards IETF utilisent uniquement TLS depuis 1999.

Pourquoi certains sites sont-ils encore en TLS 1.2 ?

Plusieurs raisons : compatibilité avec clients anciens (systèmes embarqués, IoT, anciens navigateurs), matériel réseau (load balancers, proxies) qui ne supporte pas TLS 1.3, configurations historiques non mises à jour, contraintes réglementaires spécifiques. TLS 1.2 bien configuré (AEAD, ECDHE, algorithmes modernes) reste sûr — pas d'urgence à passer à 1.3 si 1.2 est correctement configuré. TLS 1.3 apporte surtout des gains de performance et de simplicité. L'évolution se fait naturellement : activer TLS 1.3 en plus de 1.2 pour les clients modernes, désactiver progressivement 1.2 quand les clients suivent.

Qu'est-ce que le mTLS et quand l'utiliser ?

mTLS (mutual TLS) exige que client et serveur s'authentifient mutuellement par certificat. Cas d'usage pertinents : microservices internes — service mesh avec Istio/Linkerd implémente mTLS automatique, chaque service prouve son identité. APIs B2B sensibles — au lieu ou en complément de clés API, certificat client pour authentification forte. Zero Trust — authentification cryptographique à chaque appel. IoT — certificats clients sur appareils pour authentification forte. Points d'attention : gestion du cycle de vie des certificats clients (émission, renouvellement, révocation), complexité opérationnelle, performance handshake légèrement supérieure. Outils : HashiCorp Vault, AWS Private CA, Smallstep, Google CA Service, Cert-Manager (Kubernetes).

Combien de temps prend un handshake TLS ?

Très variable. Facteurs : distance géographique (latence réseau), version TLS, reprise de session ou non, performance CPU. Ordres de grandeur : TLS 1.3 new session : 1 RTT ~50-150 ms. TLS 1.3 session resumption : 0-1 RTT. TLS 1.2 new session : 2 RTT ~100-300 ms. Sur des connexions locales (intra-datacenter), les handshakes sont de l'ordre de la ms. Sur transatlantique, 100-200 ms typiquement. Pour APIs avec beaucoup de petites connexions, réutiliser les connexions (keepalive HTTP) ou sessions TLS est crucial pour la performance.

Peut-on avoir du TLS sans certificat ?

Oui dans des cas spéciaux. PSK (Pre-Shared Key) : deux parties partagent un secret préalablement établi, utilisé pour dériver les clés TLS sans certificat. Courant dans IoT. Raw Public Keys : échange de clés publiques sans structure X.509, dans certains protocoles. Certificat auto-signé : technique du certificat mais sans CA externe, pour tests ou environnements internes avec trust store dédié. Tous ces modes gardent le chiffrement et l'intégrité de TLS, mais la partie authentification via PKI est remplacée. La PKI par certificats reste le standard pour le web public.

Quand passer aux certificats post-quantiques ?

Dépend de votre profil de risque. Données sensibles à long terme (défense, santé à 20 ans, propriété intellectuelle critique) : commencer la transition vers suites hybrides dès 2025-2026 pour le handshake, malgré coût performance. Entreprises générales : rester attentif aux évolutions, préparer inventaire des systèmes utilisant TLS et leurs versions d'OpenSSL/équivalents, suivre les recommandations ANSSI et NIST. Particuliers : les navigateurs déploient progressivement — rien à faire personnellement. Calendrier ANSSI : migration conseillée d'ici 2030 pour données nécessitant protection long terme. L'informatique quantique capable de casser RSA/ECDHE reste théoriquement à 10-20 ans, mais l'attaque « harvest now, decrypt later » justifie d'anticiper.