TLS expliqué simplement : fonctionnement 2026

TLS (Transport Layer Security) est le protocole de chiffrement qui sécurise la majorité des communications Internet en 2026 : HTTPS (web), SMTP STARTTLS (email), LDAPS, FTPS, gRPC, API REST sécurisées, et bien plus. Successeur de SSL historique (1994-1996), TLS a évolué de 1.0 (1999) à 1.3 (RFC 8446, août 2018, version moderne dominante en 2026). Son rôle : fournir confidentialité (chiffrement symétrique AES-GCM ou ChaCha20-Poly1305), authentification (certificats X.509 signés par CA), intégrité (AEAD garantit non-modification en transit), et forward secrecy (une compromission future de clés ne révèle pas les communications passées). Le protocole s'articule en deux phases : handshake (négociation de clés et authentification, 1-RTT en TLS 1.3) puis record layer (chiffrement des données applicatives avec les clés négociées). En 2026, TLS 1.3 domine les nouveaux déploiements (75 %+ du trafic web selon Cloudflare), TLS 1.2 reste acceptable pour legacy, TLS 1.0 et 1.1 interdits depuis mars 2021 (RFC 8996). Cet article explique simplement le fonctionnement TLS pour des développeurs et administrateurs non-cryptographes : versions et évolution, handshake TLS 1.3 étape par étape, cipher suites AEAD modernes, forward secrecy, 0-RTT resumption, extensions (SNI, ALPN, ECH), configuration serveur durcie (Mozilla profiles), TLS post-quantum (hybrides X25519MLKEM768 déployés 2024+), CVE historiques, outils d'audit (SSL Labs, testssl.sh, Mozilla Observatory).

Rôle de TLS : 4 garanties simultanées

TLS fournit quatre propriétés cryptographiques aux communications qu'il protège.

Sans TLS, un observateur réseau (FAI, attaquant sur WiFi public, gouvernement) peut lire, modifier ou injecter des données dans les communications.

Historique des versions

Chronologie complète SSL → TLS.

RFC 8996 (mars 2021) : fin officielle de TLS 1.0 et 1.1

L'IETF a formalisé en mars 2021 la dépréciation de TLS 1.0 et TLS 1.1 via RFC 8996. Navigateurs majeurs ont retiré le support : Chrome 98, Firefox 78, Safari 14, Edge 98 (tous 2020-2022). En 2026, un serveur acceptant encore TLS 1.0/1.1 est visible par SSL Labs comme grade F.

Adoption TLS 1.3 en 2026

Selon Cloudflare Radar et SSL Pulse :

• 75 %+ du trafic web mondial utilise TLS 1.3.
• 95 %+ des sites top Alexa supportent TLS 1.3.
• 5 % supporte encore TLS 1.0 ou 1.1 (sites obscurs, IoT, embedded legacy).

Progression continue, TLS 1.3 devient le standard de facto.

Les 2 phases : handshake + record layer

TLS fonctionne en deux phases séquentielles.

Phase 1 — Handshake

Négociation initiale : choix des algorithmes, échange de clés, authentification serveur (et optionnellement client). Objectif : établir un secret partagé que seuls client et serveur connaissent. Utilise cryptographie asymétrique (lente mais authentifiée).

Phase 2 — Record layer

Une fois le handshake réussi, toutes les données applicatives sont chiffrées avec les clés symétriques dérivées du secret partagé. Utilise cryptographie symétrique (rapide, AEAD).

┌─────────────────────────────────────────────────┐
│ HANDSHAKE (secondes, asymétrique lent)          │
│ - Négociation cipher suite                      │
│ - Échange de clés (ECDHE)                       │
│ - Authentification (certificats X.509)          │
│ - Dérivation de clés symétriques                │
└─────────────────────────────────────────────────┘
                    │
                    │ Secret partagé établi
                    ▼
┌─────────────────────────────────────────────────┐
│ RECORD LAYER (toute la session, symétrique rapide)│
│ - Chiffrement des données applicatives          │
│ - AEAD (AES-GCM ou ChaCha20-Poly1305)           │
│ - Intégrité et anti-replay                      │
└─────────────────────────────────────────────────┘

Handshake TLS 1.3 étape par étape

TLS 1.3 révolutionne le handshake : 1-RTT (un seul aller-retour réseau) au lieu de 2-RTT pour TLS 1.2. Gain de latence majeur.

Diagramme simplifié

Client                                          Serveur
  │                                                │
  │ 1. ClientHello                                 │
  │    - Versions TLS supportées (1.3, 1.2, ...)   │
  │    - Cipher suites proposées                   │
  │    - Extensions (SNI, ALPN, signature algos)   │
  │    - Key share : clés éphémères ECDH X25519    │
  │      (ou P-256) ou hybride X25519MLKEM768      │
  ├───────────────────────────────────────────────►│
  │                                                │
  │ 2. ServerHello                                 │
  │    - Version choisie : TLS 1.3                 │
  │    - Cipher suite choisi (par exemple :        │
  │      TLS_AES_256_GCM_SHA384)                   │
  │    - Key share : clé éphémère serveur          │
  │◄───────────────────────────────────────────────┤
  │                                                │
  │    --- À partir d'ici, échanges chiffrés       │
  │        avec clés dérivées du ECDH ---          │
  │                                                │
  │ 3. EncryptedExtensions                         │
  │    - ALPN (HTTP/2 ou HTTP/3 negotiated)       │
  │    - Autres extensions                         │
  │◄───────────────────────────────────────────────┤
  │                                                │
  │ 4. Certificate                                 │
  │    - Certificat X.509 serveur                  │
  │    - Chaîne intermédiaire                      │
  │◄───────────────────────────────────────────────┤
  │                                                │
  │ 5. CertificateVerify                           │
  │    - Signature du serveur sur transcript       │
  │    - Prouve possession clé privée              │
  │◄───────────────────────────────────────────────┤
  │                                                │
  │ 6. Finished (serveur)                          │
  │    - MAC de toutes les données handshake       │
  │◄───────────────────────────────────────────────┤
  │                                                │
  │ 7. [Client vérifie certificat + signature]     │
  │                                                │
  │ 8. Finished (client)                           │
  │    - MAC de toutes les données handshake       │
  ├───────────────────────────────────────────────►│
  │                                                │
  │     === SESSION TLS ÉTABLIE ===                │
  │                                                │
  │ 9. Application Data (chiffré AEAD)             │
  ├───────────────────────────────────────────────►│
  │                                                │
  │ 10. Application Data (chiffré AEAD)            │
  │◄───────────────────────────────────────────────┤

Détail critique : étape 1 (ClientHello) avec key share

Dans TLS 1.3, le client envoie dès le ClientHello sa clé publique éphémère ECDH. Il "devine" quelle courbe le serveur va choisir (X25519 par défaut pour la majorité des serveurs modernes). Cela permet au serveur de répondre avec sa propre clé éphémère dans le ServerHello et de dériver immédiatement le secret partagé.

Si le client devine mal (le serveur veut une autre courbe), un HelloRetryRequest permet une seconde tentative. Coût : 2-RTT au lieu de 1-RTT. En pratique rare car X25519 est le standard de facto.

Comparaison handshake TLS 1.2 vs 1.3

TLS 1.3 est plus simple, plus rapide, plus sûr par construction.

Cipher suites modernes

TLS 1.3 réduit drastiquement le nombre de cipher suites autorisés. Toutes sont AEAD (Authenticated Encryption with Associated Data).

Cipher suites TLS 1.3 (RFC 8446)

Seulement 5 cipher suites standardisées :

En 2026, la configuration recommandée accepte les 3 premiers (AES-GCM + ChaCha20-Poly1305) et exclut CCM sauf pour IoT contraint.

AES-NI : pourquoi AES est rapide en 2026

Tous les processeurs x86_64 depuis 2010 (Intel Westmere, AMD Bulldozer) intègrent AES-NI (AES New Instructions) qui accélère matériellement AES. Performance AES-128-GCM 2026 sur CPU moderne : 3-10 GB/s single-thread. ChaCha20-Poly1305 est plus rapide en pur software, donc recommandé pour mobiles sans AES-NI (ARM ancien) ou environnements à latence critique sans hardware accéléré.

Cipher suites TLS 1.2 à éviter absolument

Configuration Mozilla Intermediate exclut :

• TLS_RSA_* (pas de forward secrecy)
• Tout ce qui utilise RC4, 3DES, DES, export-grade
• MD5, SHA-1 pour signatures
• CBC mode (remplacé par AEAD GCM)

Forward Secrecy

Forward Secrecy (FS), aussi appelée Perfect Forward Secrecy (PFS), garantit que la compromission future d'une clé privée ne permet pas de déchiffrer les communications passées interceptées.

Mécanisme

Clé privée serveur = clé de signature long-terme, utilisée uniquement pour authentifier. Clés de session = générées éphémèrement (ECDHE, Ephemeral ECDH) à chaque handshake, détruites après.

Sans Forward Secrecy (TLS 1.2 avec RSA key exchange) :
- Attaquant enregistre tout le trafic chiffré aujourd'hui
- Dans 5 ans, il compromet la clé privée du serveur
- Il peut déchiffrer tout le trafic enregistré rétroactivement
 
Avec Forward Secrecy (TLS 1.3 ou TLS 1.2 ECDHE) :
- Clés de session générées éphémèrement, détruites après handshake
- Compromission future de la clé privée serveur = pas d'impact sur passé
- Chaque session a des clés uniques, indépendantes

TLS 1.3 : forward secrecy par construction

TLS 1.3 impose forward secrecy : pas de key exchange RSA, uniquement ECDHE. Impossible de configurer TLS 1.3 sans forward secrecy.

TLS 1.2 permet les deux modes :

• Avec FS : ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES256-GCM-SHA384 (recommandés).
• Sans FS : RSA-AES256-SHA256 (déprécié, à retirer de la configuration).

Impact de "harvest now, decrypt later"

Les adversaires d'état-nation interceptent et stockent massivement le trafic TLS aujourd'hui en anticipation des futurs ordinateurs quantiques. Sans forward secrecy + sans migration post-quantum, tout ce trafic sera déchiffré rétroactivement. Forward secrecy limite l'impact à la durée entre handshake et hypothétique quantum, pas toute l'histoire du serveur.

0-RTT Session Resumption

TLS 1.3 ajoute une optimisation : 0-RTT (Zero Round Trip Time), aussi appelé Early Data.

Principe

Lors d'un handshake initial, le serveur peut émettre un session ticket au client. Le client le stocke. Lors d'une reconnexion ultérieure, il peut envoyer ses données applicatives dans le premier paquet ClientHello (avant même la fin du handshake).

Handshake initial (1-RTT) :
Client → ClientHello → Serveur
Client ← ServerHello + Certificate + Finished + SessionTicket ← Serveur
Client → Finished → Serveur
Client → Application Data → Serveur
 
Reconnexion 0-RTT :
Client → ClientHello + EarlyData (GET /) → Serveur
Client ← ServerHello + Finished + Application Data (200 OK) ← Serveur
Client → Finished → Serveur

Latence réduite : Client peut recevoir les premières données avant même que le handshake complet soit fini.

Risque : Replay attacks

Les requêtes 0-RTT ne sont pas naturellement protégées contre le replay : un attaquant qui intercepte la requête chiffrée peut la rejouer côté serveur (qui ne sait pas distinguer).

Configuration conservative 2026

• Activer 0-RTT uniquement pour requêtes idempotentes : GET sur contenu statique, GET sur contenu cached.
• Désactiver 0-RTT pour requêtes non-idempotentes : POST/PUT/DELETE, mutations d'état, paiements.
• Détection de replay côté serveur : cache des nonce/timestamp dans fenêtre glissante (imparfait mais mitigating).

Cloudflare et Google Cloud activent par défaut pour performance. Applications sensibles (banking, santé) devraient désactiver explicitement.

Record layer : après le handshake

Une fois le handshake réussi, tous les échanges ultérieurs utilisent le record layer : chiffrement symétrique AEAD.

Fonctionnement simplifié

Pour chaque "record" TLS (fragment de données applicatives) :
1. Préfixer avec un nonce incrémenté (anti-replay)
2. Chiffrer le payload avec AES-GCM ou ChaCha20-Poly1305
3. Générer tag d'authentification AEAD
4. Préfixer avec header (type, version, longueur)
 
Structure record TLS 1.3 :
[ Type 1o | Version 2o | Length 2o | Encrypted Payload (variable) | Auth Tag 16o ]

L'AEAD garantit que tout récepteur peut vérifier l'intégrité du record (pas modifié en transit) et le déchiffrer s'il possède la clé symétrique.

Performance

AES-256-GCM sur CPU moderne avec AES-NI : 3-10 GB/s throughput single-thread. ChaCha20-Poly1305 sur ARM sans AES hardware : 1-3 GB/s. Dans les deux cas, overhead crypto négligeable vs bande passante réseau.

Extensions TLS importantes

Le ClientHello peut contenir des extensions qui activent des features additionnelles.

SNI (Server Name Indication, RFC 6066)

Le client inclut dans le ClientHello le nom du domaine auquel il veut se connecter. Permet à un serveur d'héberger plusieurs domaines sur une seule IP (mutualisation, scale).

Avant SNI (2003), chaque domaine HTTPS nécessitait sa propre IP. Depuis SNI (obligatoire dans TLS 1.3), un serveur peut servir des milliers de domaines sur une IP.

Limitation : SNI est transmis en clair dans TLS 1.2 et la plupart des déploiements TLS 1.3. Un observateur réseau (FAI, gouvernement) voit quel domaine vous visitez.

ALPN (Application-Layer Protocol Negotiation, RFC 7301)

Permet de négocier le protocole applicatif (HTTP/1.1, HTTP/2, HTTP/3, gRPC) directement dans le handshake TLS. Économise un aller-retour vs négociation post-handshake.

ECH (Encrypted Client Hello, RFC 9460 et drafts)

Chiffre le SNI dans le ClientHello pour préserver la privacy. Le ClientHello contient :

• Outer ClientHello : visible, avec SNI fictif ou générique.
• Inner ClientHello : chiffré avec clé publique du provider TLS (HPKE), contient le vrai SNI.

Déploiement 2026 :

• Cloudflare : ECH actif par défaut pour tous les sites derrière Cloudflare depuis 2023.
• Google Chrome : support depuis 2024.
• Firefox : support depuis 2023.
• Edge, Safari : support progressif.

Impact : anti-censure (Great Firewall China bloque via SNI depuis 2016), anti-traçage FAI, privacy améliorée.

OCSP Stapling (RFC 8740)

Le serveur pré-récupère la réponse OCSP signée et l'envoie dans le handshake. Le client n'a pas besoin de contacter la CA. Détaillé dans l'article sur les certificats TLS.

Session Tickets (RFC 5077)

Permettent au serveur d'externaliser l'état de session chez le client (chiffré). Économie de stockage côté serveur pour les sessions.

Configuration serveur durcie

Mozilla maintient un générateur de configuration TLS à jour : ssl-config.mozilla.org. Trois profils disponibles.

Profil Modern (recommandé 2026 nouveaux sites)

TLS 1.3 uniquement. Cipher suites AEAD modernes. Curve X25519 préférée. Compatible avec tous les navigateurs récents (Chrome 70+, Firefox 63+, Safari 12.1+, Edge 75+).

# Mozilla Modern configuration (nginx)
server {
    listen 443 ssl http2;
    
    ssl_certificate /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/key.pem;
    
    # Modern profile
    ssl_protocols TLSv1.3;
    ssl_prefer_server_ciphers off;
    
    # TLS 1.3 configuration
    ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;
    
    # ECDH curves
    ssl_ecdh_curve X25519:prime256v1:secp384r1;
    
    # Session settings
    ssl_session_tickets off;
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;
    
    # OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/nginx/ssl/ca-bundle.pem;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    
    # HSTS (2 ans)
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
}

Profil Intermediate (compatibilité large)

TLS 1.2 et 1.3. Cipher suites AEAD + ECDHE. Compatible avec plus de clients legacy (Firefox 27+, Chrome 31+, IE 11 on Windows 7, Safari 9+, Android 5+). Recommandé si support required pour clients older que 5 ans.

Profil Old (legacy)

TLS 1.0, 1.1, 1.2 et 1.3. À éviter absolument en 2026 (TLS 1.0 et 1.1 dépréciés RFC 8996). Uniquement pour compatibilité avec systèmes très anciens (Windows XP, Android 2.x) — en 2026 quasi jamais justifiable.

TLS post-quantum : hybrides déployés 2024+

Premiers déploiements en production depuis 2024.

X25519MLKEM768 : le hybride de référence

Combinaison de :

• X25519 : échange de clé classique ECDH (Curve25519).
• ML-KEM-768 : échange de clé post-quantum (FIPS 203, ex-Kyber).

Le secret partagé final est dérivé des deux. Si l'un tombe, l'autre protège.

Déploiements 2024-2026

• Chrome 124+ (avril 2024) : X25519MLKEM768 activé par défaut pour les serveurs qui le supportent.
• Cloudflare : activé par défaut côté serveur depuis octobre 2024 pour tous les sites derrière Cloudflare.
• Edge : support depuis 2024.
• Firefox : support progressif 2024-2025.
• OpenSSL 3.5+ (janvier 2025) : support natif hybrides PQ.
• Google Cloud Load Balancer : support PQ depuis 2024.

Bande passante

Clés ML-KEM-768 volumineuses : 1184 octets (vs 32 octets pour X25519). Handshake hybride ajoute ~1.2 KB par connexion. Impact bande passante négligeable sur web moderne, significatif sur IoT contraint.

CVE TLS historiques

Incidents crypto TLS marquants à connaître.

CVE-2011-3389 BEAST (septembre 2011)

Attaque sur CBC mode TLS 1.0 permettant déchiffrement cookie HTTPS via contrôle de plaintext adjacent. Exploitable via JavaScript navigateur. Mitigation browser 1/n-1 split puis migration vers TLS 1.1+ ou cipher suites non-CBC. Leçon : CBC TLS legacy dangereux, AEAD GCM résout le problème.

CVE-2014-0160 Heartbleed (avril 2014)

Buffer over-read dans extension TLS heartbeat d'OpenSSL 1.0.1 à 1.0.1f. Permet lecture jusqu'à 64 KB de mémoire serveur à chaque heartbeat malformé, exposant clés privées, mots de passe, données utilisateur. Estimé 17 % du web vulnérable. Patch urgent déployé partout. Conséquence durable : audits crypto plus rigoureux, projet OpenSSL réformé, naissance de BoringSSL.

CVE-2014-3566 POODLE (octobre 2014)

Attaque sur SSL 3.0 exploitant padding CBC. Exploitable via fallback HTTPS → SSL 3.0. Mitigation : désactivation SSL 3.0 partout (Chrome, Firefox, navigateurs). Fin définitive de SSL 3.0. RFC 7568 formalise l'interdiction en juin 2015.

CVE-2015-4000 Logjam (mai 2015)

Attaque sur DHE export-grade TLS. Permet downgrade vers cryptographie faible. Mitigation : désactivation export-grade cipher suites, augmentation taille clés DH (>=2048 bits). Motive transition vers ECDHE.

CVE-2015-0204 FREAK (mars 2015)

Attaque similaire à Logjam sur RSA export-grade. Mitigation : désactivation export-grade cipher suites.

CVE-2016-0800 DROWN (mars 2016)

Attaque cross-protocol : SSL 2.0 actif sur un serveur peut compromettre connexions TLS 1.2. Motivation forte pour désactivation totale SSL 2.0.

Pattern commun

Toutes ces CVE exploitent des protocoles obsolètes, des cipher suites faibles, ou des downgrades. TLS 1.3 par construction élimine ces classes (pas de RSA key exchange, pas de CBC legacy, pas de cipher suites export-grade, pas de compression, etc.). D'où importance migration TLS 1.3.

Outils d'audit TLS

Stack 2026 pour auditer la configuration TLS d'un serveur.

SSL Labs (Qualys)

qualys.com/ssl-labs — test en ligne gratuit, référence industrielle. Note de A+ à F basée sur :

• Version TLS supportées.
• Cipher suites et curves.
• Taille des clés.
• Vulnérabilités connues (BEAST, POODLE, FREAK, Logjam, DROWN, Heartbleed).
• Configuration HSTS, OCSP stapling.

Cible recommandée : A+ (nécessite HSTS preload, TLS 1.3, configuration Modern).

testssl.sh

Outil open source CLI en Bash, scriptable pour intégration CI.

# Installation
git clone https://github.com/drwetter/testssl.sh.git
cd testssl.sh
 
# Test complet
./testssl.sh https://example.test
 
# Test spécifique
./testssl.sh --protocols --ciphers --vulnerabilities https://example.test
 
# Sortie JSON pour automation
./testssl.sh --jsonfile result.json https://example.test

Intégrable en pipeline CI pour alerter sur régressions TLS.

sslyze

Alternative Python à testssl.sh, plus rapide.

pip install sslyze
sslyze --regular https://example.test

Mozilla Observatory

observatory.mozilla.org — audit combiné TLS + HTTP headers (HSTS, CSP, X-Frame-Options, etc.).

Hardenize

hardenize.com — audit très complet incluant DNSSEC, DNS CAA, TLS, email (SPF, DKIM, DMARC, MTA-STS).

Browser DevTools

Chrome DevTools → Security tab affiche la version TLS, cipher suite, certificat de la connexion courante. Diagnostic rapide.

mTLS : authentification client

Configuration étendue où le serveur exige aussi un certificat client.

# Configuration Nginx avec mTLS
server {
    listen 443 ssl;
    
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
    
    # mTLS : exiger certificat client
    ssl_client_certificate /etc/nginx/ssl/ca-clients.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;
    
    location / {
        proxy_pass http://backend:8080;
        proxy_set_header X-Client-Cert-Subject $ssl_client_s_dn;
        proxy_set_header X-Client-Cert-Verify $ssl_client_verify;
    }
}

Cas d'usage mTLS 2026 : microservices internes via service mesh (Istio, Linkerd auto-mTLS), partner B2B FAPI 2.0 banking, IoT devices, Zero Trust Network Access.

Anti-patterns fréquents

Six erreurs observées sur configurations TLS 2024-2026.

1. TLS 1.0 / 1.1 encore activés

Configuration ancienne jamais révisée. SSL Labs grade F. Solution : désactiver immédiatement, configuration Mozilla Modern ou Intermediate.

2. Cipher suites RC4, 3DES, MD5

Même pattern. Configuration legacy non nettoyée. Solution : Mozilla SSL Config Generator, régénérer configuration.

3. Certificat expiré ou auto-signé en production

Expiration certificat = downtime total (navigateurs bloquent). Auto-signé = warning navigateur. Solution : automation ACME (Let's Encrypt, certbot, Caddy auto-HTTPS), monitoring expiration.

4. HSTS absent ou trop court

Sans HSTS, attaquant SSL-stripping peut downgrader vers HTTP sur première visite. Solution : Strict-Transport-Security: max-age=63072000; includeSubDomains; preload et inclusion HSTS preload list.

5. OCSP Stapling désactivé

Performance dégradée + privacy compromise. Activation triviale (Nginx, Apache, Caddy auto).

6. Configuration non auditée

Configuration installée en 2019 jamais re-vérifiée. Solution : audit trimestriel SSL Labs, testssl.sh en CI.

Outils modernes qui simplifient TLS

Stack 2026 pour déploiement TLS zéro-friction.

Caddy

Serveur web Go avec TLS automatique natif via ACME. Configuration minimale :

# Caddyfile
example.test {
    reverse_proxy localhost:8080
}

Caddy gère automatiquement : obtention certificat Let's Encrypt, renouvellement, configuration HTTPS durcie par défaut, HSTS. Zéro gestion manuelle.

Cloudflare

Solution managed : Cloudflare gère TLS complet en frontage. Origine serveur peut rester HTTP interne (Flexible SSL) ou HTTPS (Full SSL / Strict). Post-quantum hybride activé par défaut. Bot management, WAF, DDoS protection inclus.

AWS Certificate Manager + ALB

Pour workloads AWS : ACM gère certificats gratuitement pour ALB/CloudFront/API Gateway. Renouvellement automatique transparent. Configuration TLS via security policies AWS managées.

Traefik

Reverse proxy avec ACME natif. Configuration K8s-friendly via annotations.

Points clés à retenir

• TLS (Transport Layer Security) est le protocole de chiffrement qui sécurise 95 %+ du web en 2026. Successeur de SSL, versions actuelles : TLS 1.2 (2008, legacy acceptable) et TLS 1.3 (2018, recommandé).
• Handshake TLS 1.3 : 1-RTT (un aller-retour) au lieu de 2-RTT en TLS 1.2. Gain de latence 50 %. Forward secrecy obligatoire (ECDHE), cipher suites AEAD uniquement (AES-GCM, ChaCha20-Poly1305).
• Configuration durcie 2026 : Mozilla Modern (TLS 1.3 seul) pour nouveaux sites, Mozilla Intermediate (TLS 1.2+1.3) pour compatibilité. TLS 1.0 et 1.1 interdits depuis mars 2021 (RFC 8996).
• TLS post-quantum en déploiement : hybride X25519MLKEM768 activé Chrome avril 2024, Cloudflare octobre 2024. OpenSSL 3.5+ depuis janvier 2025. Migration recommandée 2025-2028.
• Audit TLS trimestriel avec SSL Labs (cible A+), testssl.sh ou sslyze en CI, Mozilla Observatory. Utiliser Caddy, Cloudflare, AWS ACM pour automation TLS zéro-friction.

Pour aller plus loin

• Qu'est-ce qu'un certificat TLS - les certificats X.509 utilisés pour authentifier les serveurs TLS.
• Chiffrement asymétrique expliqué - ECDH et signatures RSA/ECDSA utilisées dans le handshake TLS.
• Chiffrement symétrique expliqué - AES-GCM et ChaCha20-Poly1305 utilisés dans le record layer TLS.
• Qu'est-ce que la cryptographie - vue d'ensemble dont TLS est une application majeure.