Chaque fois qu'un navigateur affiche le cadenas dans la barre d'adresse, il confirme l'existence d'un canal chiffré de bout en bout entre le client et le serveur. Ce canal est fourni par TLS (Transport Layer Security), le protocole qui a hérité et remplacé l'ancien SSL. Bien qu'on parle encore couramment de « certificats SSL » par habitude, SSL 3.0 est obsolète et interdit depuis la RFC 7568 (2015) : ce qui protège aujourd'hui les connexions, c'est TLS, et en comprendre le fonctionnement est indispensable pour tout responsable de systèmes souhaitant garantir la confidentialité, l'intégrité et l'authentification des données en transit.
Ce que TLS garantit réellement
TLS offre simultanément trois propriétés de sécurité. La confidentialité empêche un tiers interceptant le trafic de pouvoir 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, via des codes d'authentification de messages (MAC) ou le 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 serait inutile : on communiquerait de façon privée avec un attaquant.
La poignée de main 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 écouter ? La solution combine la cryptographie asymétrique (pour établir la confiance) avec la cryptographie symétrique (pour chiffrer les données, beaucoup plus rapide). Avec TLS 1.3, le processus est le suivant :
- ClientHello. Le client annonce les versions et suites de chiffrement qu'il prend en charge et envoie sa part d'un échange de clés Diffie-Hellman éphémère (ECDHE).
- ServerHello. Le serveur choisit la suite, envoie son certificat et sa part de l'échange Diffie-Hellman.
- Dérivation des clés. Les deux parties calculent indépendamment la même clé de session symétrique sans qu'elle ne transite jamais par le réseau.
- Finished. On vérifie que la poignée de main n'a pas été manipulée et l'échange chiffré commence.
La grande amélioration de TLS 1.3 (RFC 8446, 2018) par rapport à TLS 1.2 est la réduction de la poignée de main à un seul aller-retour (1-RTT), avec l'option 0-RTT pour reprendre des sessions, ce qui améliore sensiblement la latence. De plus, TLS 1.3 élimine les algorithmes hérités non sécurisés : il n'autorise plus RSA pour l'échange de clés (imposant le forward secrecy), ni RC4, ni MD5, ni les modes CBC vulnérables.
La différence entre les deux versions n'est pas uniquement une question de vitesse, mais de surface d'attaque. TLS 1.2 permettait de négocier des suites de chiffrement considérées aujourd'hui comme non sécurisées, et de nombreuses attaques historiques (BEAST, POODLE, Lucky 13) exploitaient précisément ces combinaisons obsolètes ou la négociation de rétrogradation de version. TLS 1.3 réduit drastiquement le catalogue de suites admises à une poignée d'options modernes avec chiffrement authentifié (AEAD), éliminant ainsi toute possibilité de choisir, par erreur de configuration, une combinaison faible. Cette simplification est en soi une amélioration de la sécurité : moins d'options signifie moins de façons de se tromper.
Forward secrecy : pourquoi l'échange éphémère est essentiel
Le Perfect Forward Secrecy (PFS) est l'une des propriétés les plus importantes et les moins bien comprises. Avec un échange de clés éphémère (ECDHE), chaque session génère des clés uniques qui sont détruites à la fin. 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 exposerait rétroactivement l'ensemble de l'historique des communications. TLS 1.3 rend le 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 le navigateur fait confiance par défaut. Il existe trois niveaux de validation :
| Type | Validation | Usage typique |
|---|---|---|
| DV (Domain Validation) | Contrôle du domaine uniquement | Blogs, sites personnels, API internes |
| OV (Organization Validation) | Domaine + existence légale de l'organisation | Sites d'entreprise, e-commerce |
| EV (Extended Validation) | Vérification juridique exhaustive | Banque, secteurs réglementés |
La chaîne de confiance va du certificat du serveur à un ou plusieurs certificats intermédiaires, puis à un certificat racine déjà préinstallé par le système d'exploitation ou le navigateur. Mal configurer la chaîne (omettre l'intermédiaire) est l'une des causes les plus fréquentes d'erreur « certificat non approuvé », même lorsque le certificat final est valide. Des initiatives comme Let's Encrypt ont démocratisé les certificats DV gratuits et automatisés via le protocole ACME.
Révocation : quand un certificat valide cesse de l'être
Un certificat peut cesser d'être digne de confiance avant sa date d'expiration, par exemple si sa clé privée est compromise. Pour ces cas, des mécanismes de révocation existent. Les CRL (listes de révocation de certificats) sont des listes que le client devrait télécharger pour vérifier si un certificat y figure, mais leur taille et leur latence les rendent peu pratiques. Le protocole OCSP (Online Certificate Status Protocol) permet de consulter l'état d'un certificat précis en temps réel, même s'il introduit un problème de confidentialité et de latence, car le navigateur contacte la CA à chaque connexion.
La solution moderne est l'OCSP stapling : le serveur lui-même obtient périodiquement de la CA une réponse OCSP signée et horodatée, et l'agrafe à la poignée de main TLS. Ainsi, le client reçoit la preuve de validité sans contacter la CA, éliminant la fuite de confidentialité et la latence. Activer l'OCSP stapling est l'une des optimisations de performance et de confidentialité les plus recommandables dans tout déploiement sérieux.
HSTS, certificate pinning et durcissement
Avoir TLS actif ne suffit pas ; il faut éviter qu'un attaquant force une rétrogradation vers HTTP. L'en-tête HSTS (HTTP Strict Transport Security) indique au navigateur qu'il ne doit se connecter que via HTTPS pendant une période définie, éliminant la fenêtre d'attaque du premier redirection. Le certificate pinning va plus loin : l'application (notamment sur mobile) mémorise quel certificat ou quelle clé publique précise elle attend du serveur, de sorte qu'elle rejette tout autre certificat même signé par une CA valide, atténuant les attaques liées à des CA compromises. Le pinning doit être géré avec soin car, mal configuré, il peut rendre une application inaccessible lors du renouvellement du certificat.
Étapes d'implémentation et de vérification
- Générer une clé privée robuste (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 de chiffrement garantissant le forward secrecy (ECDHE) et AEAD (AES-GCM ou ChaCha20-Poly1305).
- Activer HSTS, la 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é de plus en plus courtes) et surveiller l'expiration.
- Vérifier la configuration avec des outils d'analyse externe avant de considérer le déploiement comme terminé.
Erreurs courantes
La première est de laisser expirer le certificat : cela provoque des interruptions totales de service et, pire encore, habitue les utilisateurs à ignorer les avertissements de sécurité. La deuxième est de maintenir des protocoles obsolètes actifs par compatibilité avec d'anciens clients, ce qui rouvre des vulnérabilités connues. La troisième est de servir du contenu mixte (mixed content) : 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 protéger uniquement le frontal et de laisser le trafic entre services internes non chiffré, une pratique incompatible avec les modèles de confiance zéro.
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 habitude commerciale, mais les certificats servent à TLS.
Un certificat EV améliore-t-il le référencement SEO ? Pas directement. Les moteurs de recherche valorisent l'utilisation de HTTPS, mais ne distinguent pas DV, OV et EV en termes de classement. Le type de certificat se choisit selon les exigences de confiance et de conformité, pas selon le SEO.
Let's Encrypt est-il sécurisé puisqu'il est gratuit ? Oui. La sécurité provient du protocole TLS et de la robustesse de la clé, non du prix du certificat. Un certificat DV gratuit offre exactement le même chiffrement qu'un certificat payant du même niveau.
Dois-je aussi chiffrer le trafic entre microservices internes ? Oui, dans les architectures actuelles on recommande TLS de bout en bout, même à l'intérieur 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 a cessé d'être un complément optionnel pour devenir l'exigence minimale de tout service qui fait transiter des données sur un réseau. Mais « avoir HTTPS » et « avoir TLS bien configuré » sont deux choses très différentes : la différence réside dans l'imposition de TLS 1.3 avec forward secrecy, le maintien d'une chaîne de certificats complète, l'activation de HSTS et l'automatisation des renouvellements pour qu'aucune expiration ne mette le service hors ligne. La cryptographie qui protège ces connexions est robuste ; les incidents ne résultent presque jamais de l'algorithme, mais de configurations obsolètes et de certificats mal gérés. Chez Summum, nous auditons les déploiements TLS, éliminons les protocoles hérités et mettons en place un renouvellement automatisé et surveillé, de sorte que le cadenas du navigateur signifie exactement ce que l'utilisateur croit qu'il signifie.