Protocoles de Chiffrement TLS HTTPS

Versions TLS et suites cryptographiques

TLS 1.3 (recommandé) : suppression des algorithmes faibles (RSA key exchange, CBC mode, MD5, SHA-1), Perfect Forward Secrecy (PFS) imposé pour tous les échanges de clés (ECDHE uniquement), handshake réduit à 1-RTT (vs 2-RTT en TLS 1.2), support du 0-RTT pour les reconnexions (avec précautions sur les risques de replay). Suites cryptographiques TLS 1.3 : TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256 — toutes sécurisées.

TLS 1.2 (acceptable, vérifier la configuration) : le niveau de sécurité dépend fortement des suites cryptographiques activées. Suites recommandées : ECDHE-RSA-AES256-GCM-SHA384, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384. Suites à désactiver : celles utilisant RC4, 3DES, DES, MD5, SHA-1, RSA key exchange (sans PFS — vulnérable au déchiffrement rétroactif si la clé privée est compromise). Des outils d'évaluation de la configuration TLS : SSL Labs (Qualys), testssl.sh (CLI), nmap avec le script ssl-enum-ciphers.

Perfect Forward Secrecy et gestion des clés

Le Perfect Forward Secrecy (PFS) est une propriété cryptographique garantissant que la compromission de la clé privée du serveur ne permet pas de déchiffrer rétroactivement les communications passées. Avec PFS (ECDHE ou DHE key exchange), une clé de session éphémère est générée pour chaque connexion et détruite après usage — la clé privée du serveur n'est jamais directement utilisée pour chiffrer les données.

Sans PFS (RSA key exchange en TLS 1.2), un attaquant qui enregistre les communications chiffrées aujourd'hui et obtient la clé privée du serveur dans le futur peut déchiffrer toutes les communications passées. Cette technique (Harvest Now, Decrypt Later — HNDL) est une préoccupation croissante face aux futurs ordinateurs quantiques. L'adoption de TLS 1.3 (PFS obligatoire) et la migration vers des algorithmes post-quantiques (NIST PQC — Kyber, Dilithium) préparent les organisations à la menace quantique.

Certificate Transparency et gestion des certificats

Certificate Transparency (CT) impose que tous les certificats TLS publics soient enregistrés dans des logs CT immuables et publics avant d'être acceptés par les navigateurs modernes. CT permet de détecter les certificats frauduleux émis sans l'accord du propriétaire du domaine (ex. : compromission d'une CA, émission de certificats par erreur). Les organisations peuvent surveiller les logs CT pour détecter tout nouveau certificat émis pour leurs domaines (services de monitoring CT : crt.sh, Facebook CT Monitor, Cert Spotter).

La gestion du cycle de vie des certificats (Certificate Lifecycle Management — CLM) est un défi opérationnel : les organisations avec des centaines ou milliers de certificats doivent suivre leurs dates d'expiration et renouveler proactivement. Des solutions CLM (AppViewX, Venafi, Keyfactor, AWS Certificate Manager, Azure Key Vault pour les certificats) automatisent la découverte, le suivi, et le renouvellement des certificats. L'expiration inattendue d'un certificat TLS peut causer une indisponibilité de service — des incidents majeurs ont été causés par des certificats expirés (Microsoft Teams 2020, O2 UK 2012).