SSL : tout ce qu'il faut savoir, choisir et déployer

SSL (Secure Sockets Layer) a été développé par Netscape et a connu trois versions. SSL 2.0, publié en 1995, présentait de graves défauts de conception, dont une vulnérabilité aux attaques de l'homme du milieu. SSL 3.0, publié en 1996, corrigeait nombre de ces problèmes mais a été lui-même cassé par l'attaque POODLE en 2014. Aucune de ces versions n'est sûre à utiliser aujourd'hui.

En 1999, l'IETF a repris le protocole et l'a renommé TLS (Transport Layer Security). TLS 1.0 correspondait techniquement à SSL 3.1, une évolution modeste. TLS 1.1 a suivi en 2006, et TLS 1.2 en 2008 a introduit les modes de chiffrement authentifié et la prise en charge de SHA-256. TLS 1.3, finalisé en 2018 sous la RFC 8446, est une refonte majeure qui élimine entièrement l'héritage cryptographique obsolète.

Les différences clés entre SSL et TLS ne sont pas cosmétiques. TLS a remplacé la construction MAC-puis-chiffrement de SSL par du chiffrement authentifié (chiffrements AEAD comme AES-GCM et ChaCha20-Poly1305), supprimé la prise en charge d'algorithmes non sûrs comme RC4, MD5 et les chiffrements de niveau export, et introduit un mécanisme de handshake plus robuste. Toutes les versions de SSL et de TLS antérieures à 1.2 sont désormais formellement dépréciées par la RFC 8996.

Lorsqu'on parle de « certificat SSL » ou de « certificat numérique SSL », il s'agit d'un certificat X.509 standard utilisé pour authentifier un serveur lors d'un handshake TLS. Le certificat lui-même est indépendant du protocole : le même certificat SSL fonctionne avec TLS 1.2 et TLS 1.3. Ce qui compte, c'est la version du protocole que le serveur et le client négocient.

Le handshake TLS est le processus par lequel un client et un serveur s'accordent sur les paramètres cryptographiques et établissent un canal chiffré. Dans TLS 1.2, cela nécessite deux allers-retours. TLS 1.3 le réduit à un seul.

Dans TLS 1.3, le handshake se termine en un seul aller-retour (1-RTT), réduisant de moitié la latence d'établissement de connexion par rapport à TLS 1.2. Un mode 0-RTT existe pour les sessions reprises, mais il sacrifie la protection contre le rejeu et doit être utilisé avec précaution.

Tous les certificats SSL ne se valent pas. Ils diffèrent par leur niveau de validation, leur portée et leur cas d'usage. Choisir le bon type a un impact à la fois sur la posture de sécurité et sur la charge opérationnelle.

TLS 1.3 n'est pas une simple montée de version. C'est une amélioration significative en matière de sécurité et de performance qui supprime des catégories entières de vulnérabilités présentes dans les versions antérieures du protocole SSL et de TLS.

La négociation des suites de chiffrement est simplifiée : TLS 1.3 ne prend en charge que cinq suites de chiffrement, toutes basées sur du chiffrement AEAD. L'échange de clés RSA a disparu, ce qui signifie que chaque connexion utilise désormais Diffie-Hellman éphémère, garantissant la confidentialité persistante par défaut. Si la clé privée d'un serveur est compromise à l'avenir, les sessions enregistrées dans le passé ne pourront pas être déchiffrées.

RSA statique, les chiffrements en mode CBC, SHA-1, RC4, DES, 3DES, la compression et la renégociation sont tous supprimés. Cela élimine la surface d'attaque exploitée par BEAST, CRIME, Lucky13, Sweet32 et d'autres attaques de niveau protocole qui ont affecté les versions antérieures.

En production, l'adoption de TLS 1.3 nécessite de vérifier que l'ensemble de votre pile la prend en charge : load balancers, reverse proxies, CDN, serveurs d'application et tout middleware qui termine ou inspecte TLS. La plupart des plateformes modernes (Nginx 1.13+, Apache 2.4.37+, HAProxy 2.0+, tous les principaux fournisseurs cloud) prennent en charge TLS 1.3 nativement. La principale préoccupation de compatibilité concerne les clients plus anciens ; certaines applications Java d'entreprise tournant sur d'anciennes versions du JDK ou des appareils IoT hérités peuvent ne pas prendre en charge TLS 1.3.

Une stratégie de migration pragmatique consiste à activer TLS 1.3 en parallèle de TLS 1.2 et à surveiller la télémétrie des connexions. Une fois que la proportion de connexions TLS 1.2 passe sous votre seuil, désactivez-le.

La plupart des défaillances de sécurité TLS ne sont pas des ruptures cryptographiques. Ce sont des erreurs de configuration qui laissent exposées des vulnérabilités connues.

Gérer une poignée de certificats SSL manuellement est faisable. En gérer des centaines ou des milliers ne l'est pas. À mesure que les organisations adoptent les microservices, les architectures multi-cloud et les modèles zero-trust, le nombre de certificats SSL dans un environnement donné croît de manière exponentielle.

Les difficultés s'accumulent. La durée de vie des certificats se réduit : le CA/Browser Forum est passé d'une validité de plusieurs années à un maximum de 398 jours, et l'industrie tend vers des durées de vie de 90 jours, voire 47 jours. Des durées de vie plus courtes améliorent la sécurité en limitant la fenêtre d'exposition en cas de compromission, mais elles rendent le renouvellement manuel opérationnellement impossible à grande échelle.

Une gestion efficace du cycle de vie des certificats requiert quatre capacités. Premièrement, la découverte : connaître chaque certificat SSL déployé dans votre infrastructure, y compris les certificats fantômes provisionnés par des équipes individuelles. Deuxièmement, l'application des politiques : s'assurer que chaque certificat respecte les standards de l'organisation en matière d'algorithme de clé, de longueur minimale de clé, de CA approuvées et de conventions de nommage. Troisièmement, le renouvellement automatisé : l'intégration de protocoles comme ACME, EST et SCEP pour renouveler les certificats SSL avant leur expiration sans intervention humaine. Quatrièmement, l'auditabilité : tenir un enregistrement complet de chaque événement de certificat pour le reporting de conformité dans des cadres comme NIS2, DORA et PCI DSS.

Sans gestion centralisée, les organisations sont inévitablement confrontées à des pannes causées par des certificats expirés, à des failles de sécurité provenant de certificats inconnus utilisant une cryptographie faible, et à des échecs d'audit dus à des inventaires de certificats incomplets.