TLS / SSL — Transport Layer Security
Couche OSI : L6 — Présentation
Ports courants : 443 (HTTPS) · 465 (SMTPS) · 993 (IMAPS) · 8443 (HTTPS alternatif)
TLS (anciennement SSL) est le protocole qui chiffre les communications réseau. Il s’intercale entre la couche transport (TCP) et la couche application (HTTP, SMTP…) pour garantir confidentialité, intégrité et authenticité.
SSL est obsolète (SSL 2.0, 3.0 — vulnérables). On dit encore “SSL” par habitude, mais on utilise TLS 1.2 ou 1.3.
Ce que TLS garantit
| Propriété | Mécanisme | Ce que ça évite |
|---|---|---|
| Confidentialité | Chiffrement symétrique (AES-256-GCM) | Un intermédiaire lit les données |
| Intégrité | AEAD / HMAC-SHA256 | Modification du contenu en transit |
| Authentification | Certificat X.509 signé par une CA | Se connecter à un faux serveur (MITM) |
| Forward Secrecy | Clés Diffie-Hellman éphémères | Déchiffrer les sessions passées si la clé privée fuite |
TLS Handshake — TLS 1.3
Client Serveur
│ │
│── ClientHello ──────────────────────────► │
│ versions TLS supportées : [1.3, 1.2] │
│ suites crypto : [AES-256-GCM, ...] │
│ clé publique DH éphémère (key_share) │
│ │
│◄── ServerHello + EncryptedExtensions ───── │
│ suite choisie : TLS_AES_256_GCM_SHA384 │
│ clé publique DH éphémère (key_share) │
│ Certificate (cert X.509 du serveur) │
│ CertificateVerify (signature) │
│ Finished (chiffré) │
│ │
│ [client calcule le secret partagé via DH] │
│ [client vérifie la chaîne de certificats] │
│ │
│── Finished (chiffré) ───────────────────► │
│ │
│════════ Données chiffrées (HTTP...) ══════ │
TLS 1.3 complète le handshake en 1 aller-retour (1-RTT) contre 2 pour TLS 1.2. Il supporte aussi le 0-RTT pour les reconnexions (mais avec des risques de replay).
Versions TLS
| Version | Statut | Notes |
|---|---|---|
| SSL 2.0 | Obsolète ❌ | Vulnérabilités critiques — à bannir |
| SSL 3.0 | Obsolète ❌ | Vulnérabilité POODLE — à bannir |
| TLS 1.0 | Déprécié ⚠️ | RFC 8996 — ne plus utiliser |
| TLS 1.1 | Déprécié ⚠️ | RFC 8996 — ne plus utiliser |
| TLS 1.2 | Accepté ✅ | Encore très répandu, compatible |
| TLS 1.3 | Recommandé ✅ | Plus rapide, plus sécurisé, forward secrecy obligatoire |
Certificats X.509
Un certificat TLS prouve l’identité du serveur. Il est signé par une CA (Certificate Authority) de confiance.
Certificat de monentreprise.fr
├── Sujet : CN=monentreprise.fr
├── Émetteur : Let's Encrypt Authority X3
├── Valide du : 01/01/2026
├── Valide jusqu'au : 01/04/2026
├── Clé publique : RSA 2048 bits ou ECDSA P-256
├── SAN (Subject Alt Names) : monentreprise.fr, www.monentreprise.fr
└── Signature : [signée par la clé privée de Let's Encrypt]
Chaîne de confiance
Certificat du serveur (monentreprise.fr)
└── signé par → CA intermédiaire (Let's Encrypt R3)
└── signé par → CA racine (ISRG Root X1)
└── dans le store de confiance du navigateur ✅
Pour le détail complet des champs X.509, les formats de fichiers et les commandes openssl → X.509 — Format des certificats
Pour la hiérarchie des CA, le trust store et créer sa propre PKI → PKI — Infrastructure à Clés Publiques
Pour le cycle CSR → émission → renouvellement → révocation (OCSP, CRL) → Cycle de vie et révocation
Pour Let’s Encrypt et l’automatisation ACME/cert-manager → Let’s Encrypt et ACME
Suites cryptographiques (Cipher Suites)
Une suite définit l’ensemble des algorithmes utilisés pour un handshake TLS :
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│ │ │ │ │
│ │ │ │ └── Hash pour l'intégrité (SHA-384)
│ │ │ └── Chiffrement symétrique + mode (AES-256-GCM)
│ │ └── Authentification du serveur (RSA)
│ └── Échange de clés (ECDHE = Diffie-Hellman sur courbe elliptique, éphémère)
└── Protocole
En TLS 1.3, les suites sont simplifiées (l’échange de clés est toujours éphémère) :
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
mTLS — TLS mutuel
Dans TLS standard, seul le serveur présente un certificat. En mTLS (Mutual TLS), les deux parties s’authentifient mutuellement via des certificats X.509.
TLS standard vs mTLS
TLS standard :
Client ──────────────────────────────► Serveur
Client ◄── Certificate (cert serveur) Serveur ← seul le serveur prouve son identité
[communication chiffrée — client anonyme]
mTLS :
Client ──── Certificate (cert client) ──────────► Serveur ← le serveur vérifie le client
Client ◄─── Certificate (cert serveur) ───────── Serveur ← le client vérifie le serveur
[communication chiffrée ET les deux identités sont vérifiées]
Handshake mTLS complet
Client Serveur
│── ClientHello ────────────────────────────► │
│◄── ServerHello + Certificate ───────────── │ cert serveur
│◄── CertificateRequest ───────────────────── │ "présente ton certificat"
│◄── ServerHelloDone ──────────────────────── │
│ │
│── Certificate (cert client) ──────────────► │ cert client
│── CertificateVerify (signature) ──────────► │ prouve que tu as la clé privée
│── ChangeCipherSpec + Finished ─────────────► │
│◄── ChangeCipherSpec + Finished ──────────── │
│ │
│════════════ Données chiffrées ══════════════ │
Ce que mTLS ajoute à TLS
| Propriété | TLS | mTLS |
|---|---|---|
| Chiffrement | ✅ | ✅ |
| Authentification serveur | ✅ | ✅ |
| Authentification client | ❌ | ✅ |
| Révocation granulaire | N/A | ✅ (par certificat client) |
| Modèle de confiance | PKI publique (CA Let’s Encrypt) | PKI interne (CA privée) |
Cas d’usage : Zero Trust
mTLS est le fondement des architectures Zero Trust : “Ne jamais faire confiance, toujours vérifier.”
Sans mTLS (périmètre de confiance) :
Service A ──► Service B [si A est dans le réseau, B lui fait confiance]
→ Si un attaquant compromet A, il peut parler à tous les services
Avec mTLS (Zero Trust) :
Service A ──► Service B [B vérifie le certificat de A avant toute réponse]
→ Chaque service prouve son identité, même sur le réseau interne
→ Un service compromis ne peut pas usurper l'identité d'un autre
mTLS dans Kubernetes
Kubernetes utilise mTLS pour toutes les communications critiques du control plane :
kubectl ──── mTLS ──► kube-apiserver (cert kubectl + cert apiserver)
kube-apiserver ── mTLS ──► etcd (cert apiserver-etcd + cert etcd)
kube-apiserver ── mTLS ──► kubelet (cert apiserver-kubelet + cert kubelet)
kubelet ── mTLS ──► container runtime (via CRI/gRPC + mTLS)
Composants concernés : etcd, kubelet, container runtime
Les certificats sont gérés par :
kubeadmà l’installation (dans/etc/kubernetes/pki/)- cert-manager pour les certificats applicatifs
mTLS avec Istio / Cilium (service mesh)
Les service meshes injectent un sidecar proxy qui gère le mTLS automatiquement entre tous les pods :
Pod A Pod B
│ │
│ [appli A parle HTTP en clair à localhost] │
▼ │
Sidecar Envoy (Istio) ── mTLS ──► Sidecar Envoy │
▼ │
[appli B reçoit HTTP en clair]
L’application ne sait pas que mTLS est utilisé — c’est transparent.
Vérification et diagnostic
# Inspecter le certificat d'un serveur
openssl s_client -connect monentreprise.fr:443 -servername monentreprise.fr
# Voir les détails du certificat
echo | openssl s_client -connect monentreprise.fr:443 2>/dev/null | openssl x509 -noout -text
# Vérifier la date d'expiration
echo | openssl s_client -connect monentreprise.fr:443 2>/dev/null \
| openssl x509 -noout -dates
# Tester les versions TLS supportées
nmap --script ssl-enum-ciphers -p 443 monentreprise.fr
# Grade SSL (outil en ligne)
# → https://www.ssllabs.com/ssltest/En relation avec
- Protocoles OSI - Index — tous les protocoles par couche
- Certificats — Vue d’ensemble — hub : types, usages, DV/OV/EV, wildcards
- X.509 — Format des certificats — structure complète, extensions, openssl
- PKI — Infrastructure à Clés Publiques — hiérarchie CA, trust store, PKI privée
- Cycle de vie et révocation — CSR, renouvellement, CRL, OCSP, stapling
- Let’s Encrypt et ACME — certificats gratuits, challenges HTTP-01 / DNS-01
- Requêtes HTTP et HTTPS — HTTPS = HTTP dans TLS
- RPC — gRPC utilise TLS/mTLS pour sécuriser les appels distants
- Authentification API — TLS/mTLS comme mécanisme d’authentification inter-services
- cert-manager — gère les certificats TLS dans Kubernetes
- SSH — utilise des mécanismes cryptographiques similaires (mais pas TLS)
- DNS - CAA — contrôle quelles CA peuvent émettre des certificats
- etcd, kubelet, container runtime — composants Kubernetes sécurisés par mTLS