Ce qui sécurise réellement les connexions aujourd'hui n'est pas SSL — obsolète et interdit depuis 2015 (RFC 7568) — mais TLS, désormais en version 1.3 (RFC 8446), qui réduit la négociation à un seul aller-retour (1-RTT), élimine les algorithmes non sécurisés comme RC4 et MD5, et impose la forward secrecy.
Chaque fois qu'un navigateur affiche le cadenas dans la barre d'adresse, il confirme qu'un canal chiffré de bout en bout existe entre le client et le serveur. Ce canal est fourni par TLS (Transport Layer Security), le protocole qui a hérité de l'ancien SSL et l'a remplacé. Bien que le terme « certificats SSL » ait persisté par habitude, SSL 3.0 est obsolète et interdit depuis la RFC 7568 (2015) : ce qui protège réellement les connexions aujourd'hui, c'est TLS, et comprendre son fonctionnement est essentiel pour tout administrateur système souhaitant garantir la confidentialité, l'intégrité et l'authentification des données en transit.
Ce que TLS garantit réellement
TLS apporte simultanément trois propriétés de sécurité. La confidentialité empêche un tiers qui intercepte le trafic de le lire, grâce au chiffrement symétrique. L'intégrité garantit que les données n'ont pas été altérées en transit, grâce à des codes d'authentification de message (MAC) ou à un chiffrement authentifié (AEAD). Et l'authentification vérifie que le serveur est bien celui qu'il prétend être, grâce à des certificats numériques signés par une autorité de certification (CA) de confiance. Sans cette dernière propriété, le chiffrement ne servirait à rien : nous parlerions en privé avec un attaquant.
La négociation TLS étape par étape
Le protocole résout un problème élégant : comment deux parties qui ne se sont jamais rencontrées s'accordent-elles sur une clé secrète via un canal public que n'importe qui peut espionner. La solution combine la cryptographie asymétrique (pour établir la confiance) avec la cryptographie symétrique (pour chiffrer les données, ce qui est bien plus rapide). En TLS 1.3, le processus est le suivant :
- ClientHello. Le client annonce les versions de protocole et les suites cryptographiques qu'il prend en charge, et envoie sa part d'un échange de clés Diffie-Hellman éphémère (ECDHE).
- ServerHello. Le serveur sélectionne la suite cryptographique, envoie son certificat et sa part de l'échange Diffie-Hellman.
- Dérivation de clé. Les deux parties calculent indépendamment la même clé de session symétrique, qui ne circule jamais sur le réseau.
- Finished. L'intégrité de la négociation est vérifiée et l'échange de données chiffrées commence.
La principale amélioration de TLS 1.3 (RFC 8446, 2018) par rapport à TLS 1.2 est la réduction de la négociation à un seul aller-retour (1-RTT), avec un mode optionnel 0-RTT pour la reprise de session, ce qui améliore sensiblement la latence. Il supprime aussi les anciens algorithmes non sécurisés : l'échange de clés RSA n'est plus autorisé (rendant la forward secrecy obligatoire), et les modes RC4, MD5 et CBC vulnérables sont éliminés.
La différence entre les deux versions ne se limite pas à la vitesse ; elle concerne la surface d'attaque. TLS 1.2 permettait de négocier des suites cryptographiques désormais considérées comme non sécurisées, et de nombreuses attaques historiques (BEAST, POODLE, Lucky 13) ont exploité précisément ces combinaisons obsolètes ou la négociation de rétrogradation de version. TLS 1.3 réduit drastiquement le catalogue des suites autorisées à un petit ensemble d'options modernes avec chiffrement authentifié (AEAD), rendant impossible le choix accidentel d'une combinaison faible par mauvaise configuration. Cette simplification est en elle-même une amélioration de la sécurité : moins d'options signifie moins de façons de se tromper.
Forward secrecy : pourquoi l'échange de clés éphémère compte
La Perfect Forward Secrecy (PFS) est l'une des propriétés les plus importantes et les moins bien comprises. Avec l'échange de clés éphémère (ECDHE), chaque session génère des clés uniques qui sont détruites une fois la session terminée. Cela signifie que même si un attaquant capture le trafic chiffré aujourd'hui et vole la clé privée du serveur dans cinq ans, il ne pourra pas déchiffrer les sessions passées. Sans PFS, compromettre une seule clé privée expose rétroactivement tout l'historique des communications. TLS 1.3 rend la PFS obligatoire.
Certificats numériques : types et chaîne de confiance
Un certificat X.509 lie une identité (un domaine) à une clé publique, et cette liaison est signée par une CA en laquelle les navigateurs ont confiance par défaut. Il existe trois niveaux de validation :
| Type | Validation | Utilisation typique |
|---|---|---|
| DV (validation de domaine) | Contrôle du domaine uniquement | Blogs, sites personnels, API internes |
| OV (validation d'organisation) | Domaine + existence légale de l'organisation | Entreprises, e-commerce |
| EV (validation étendue) | Vérification juridique approfondie | Banque, secteurs réglementés |
La chaîne de confiance part du certificat du serveur, passe par un ou plusieurs certificats intermédiaires et aboutit enfin à un certificat racine que le système d'exploitation ou le navigateur a déjà préinstallé. Mal configurer la chaîne (oublier d'inclure l'intermédiaire) est l'une des causes les plus fréquentes d'erreurs « certificat non fiable », même lorsque le certificat feuille lui-même est valide. Des initiatives comme Let's Encrypt ont démocratisé les certificats DV gratuits et automatisés grâce au protocole ACME.
Révocation : quand un certificat valide n'est plus digne de confiance
Un certificat peut perdre son statut de confiance avant sa date d'expiration — par exemple, si sa clé privée est compromise. Plusieurs mécanismes de révocation existent pour gérer cela. Les CRL (Certificate Revocation Lists, listes de révocation de certificats) sont des listes que le client est censé télécharger pour vérifier si un certificat a été révoqué, mais leur taille et leur latence les rendent peu pratiques. L'OCSP (Online Certificate Status Protocol) permet d'interroger en temps réel le statut d'un certificat spécifique, bien qu'il introduise un problème de confidentialité et une latence supplémentaire, car le navigateur contacte la CA à chaque connexion.
La solution moderne est l'OCSP stapling : le serveur lui-même récupère périodiquement auprès de la CA une réponse OCSP signée et horodatée, et l'attache (« l'agrafe ») à la négociation TLS. Le client reçoit ainsi une preuve de validité sans contacter la CA, ce qui élimine la fuite de confidentialité et la latence. Activer l'OCSP stapling est l'une des optimisations de performance et de confidentialité les plus rentables pour tout déploiement sérieux.
HSTS, certificate pinning et durcissement
Avoir TLS actif ne suffit pas ; il faut aussi empêcher un attaquant de forcer une rétrogradation vers HTTP. L'en-tête HSTS (HTTP Strict Transport Security) indique au navigateur de ne se connecter qu'en HTTPS pendant une période définie, éliminant la fenêtre d'attaque créée par la première redirection. Le certificate pinning va plus loin : l'application (en particulier sur mobile) mémorise quel certificat ou quelle clé publique spécifique attendre du serveur, en rejetant tout autre même s'il est signé par une CA valide, ce qui atténue les attaques impliquant une CA compromise. Le pinning doit être géré avec précaution, car une mauvaise configuration peut rendre une application inaccessible lors du renouvellement du certificat.
Étapes de mise en œuvre et de vérification
- Générer une clé privée forte (RSA 2048+ ou, de préférence, ECDSA P-256) et la CSR.
- Obtenir le certificat auprès d'une CA de confiance et installer la chaîne complète (feuille + intermédiaires).
- Configurer le serveur pour n'accepter que TLS 1.2 et TLS 1.3, en désactivant SSL 3.0, TLS 1.0 et TLS 1.1.
- Sélectionner des suites cryptographiques garantissant la forward secrecy (ECDHE) et l'AEAD (AES-GCM ou ChaCha20-Poly1305).
- Activer HSTS, une redirection 301 de HTTP vers HTTPS et, le cas échéant, l'OCSP stapling.
- Automatiser le renouvellement (les certificats publics tendent vers des durées de validité plus courtes) et surveiller l'expiration.
- Vérifier la configuration avec des outils d'analyse externes avant de considérer le déploiement comme terminé.
Erreurs courantes
La première est de laisser le certificat expirer : cela provoque des interruptions totales de service et, pire, habitue les utilisateurs à ignorer les avertissements de sécurité. La deuxième est de maintenir des protocoles obsolètes actifs pour la compatibilité avec des clients anciens, ce qui rouvre des vulnérabilités connues. La troisième est de servir du contenu mixte : une page HTTPS qui charge des ressources en HTTP rompt les garanties de sécurité et le navigateur la marque comme non sécurisée. La quatrième est de ne protéger que le front-end tout en laissant le trafic interne service à service non chiffré, une pratique incompatible avec les modèles de sécurité zero trust.
Questions fréquentes
SSL et TLS sont-ils la même chose ? Non. SSL est le protocole prédécesseur, désormais obsolète et non sécurisé. TLS en est le successeur. Le terme « certificat SSL » persiste par convention commerciale, mais les certificats servent au TLS.
Un certificat EV améliore-t-il le classement SEO ? Pas directement. Les moteurs de recherche valorisent l'utilisation d'HTTPS, mais ils ne font pas de différence entre DV, OV et EV pour le classement. Le type de certificat se choisit en fonction de la confiance et des exigences de conformité, pas du SEO.
Let's Encrypt est-il sûr malgré la gratuité ? Oui. La sécurité provient du protocole TLS et de la robustesse de la clé, pas du prix du certificat. Un certificat DV gratuit offre exactement le même chiffrement qu'un certificat payant de même niveau.
Dois-je aussi chiffrer le trafic entre microservices internes ? Oui. Les bonnes pratiques actuelles recommandent le TLS de bout en bout même au sein du réseau (mTLS, authentification mutuelle), car le périmètre réseau n'est plus considéré comme une frontière de confiance fiable.
Conclusion
Le chiffrement en transit est passé d'un supplément optionnel à une exigence minimale pour tout service qui déplace des données sur un réseau. Cependant, « avoir HTTPS » et « avoir TLS correctement configuré » sont deux choses très différentes : la différence réside dans l'application de TLS 1.3 avec forward secrecy, le maintien de la chaîne complète de certificats, l'activation de HSTS et l'automatisation des renouvellements pour qu'aucun certificat expiré ne mette le service à l'arrêt. La cryptographie qui protège ces connexions est solide ; les incidents ne proviennent presque jamais de l'algorithme lui-même, mais de configurations obsolètes et de certificats mal gérés. Chez Summum, nous auditons les déploiements TLS, éliminons les protocoles obsolètes et laissons le processus de renouvellement automatisé et surveillé, afin que le cadenas du navigateur signifie exactement ce que l'utilisateur croit qu'il signifie.