Comment HTTPS et TLS fonctionnent vraiment : guide pratique

Vous avez vu l'icône de cadenas dans votre navigateur des milliers de fois, mais savez-vous ce qui se passe réellement en coulisses lorsque vous visitez un site HTTPS ? Le protocole qui rend la navigation web sécurisée possible est TLS (Transport Layer Security), anciennement connu sous le nom de SSL. Comprendre comment TLS fonctionne vraiment n'est pas seulement théorique—cela vous aide à déboguer les problèmes de configuration, à prendre des décisions éclairées concernant vos propres serveurs, et à apprécier les garanties de sécurité sur lesquelles vous comptez chaque jour.

Le problème : HTTP non sécurisé

Avant HTTPS, HTTP envoyait tout en texte clair. Toute personne sur le chemin réseau—un point d'accès Wi-Fi, un FAI, un routeur—pouvait lire vos mots de passe, cookies et données personnelles. Pire encore, un attaquant pouvait modifier le contenu en transit, injectant des logiciels malveillants ou des pages factices. La solution consiste à chiffrer les données et à vérifier l'identité du serveur. C'est exactement ce que fait TLS.

Comment TLS s'intègre dans HTTPS

HTTPS est simplement HTTP exécuté sur une connexion TLS. Le protocole TLS se situe entre la couche application (HTTP) et la couche transport (TCP). Il fournit trois services essentiels :

• Chiffrement – les données sont brouillées pour que les oreilles indiscrètes ne puissent pas les lire.
• Authentification – vous pouvez vérifier que le serveur est bien celui qu'il prétend être grâce aux certificats numériques.
• Intégrité – toute altération des données est détectée.

Mais comment un client et un serveur s'accordent-ils sur les clés de chiffrement et prouvent-ils leurs identités ? C'est le rôle de la poignée de main TLS.

La poignée de main TLS étape par étape

Lorsque vous visitez un site HTTPS, votre navigateur et le serveur effectuent une poignée de main—une série de messages qui établissent une session sécurisée. Voici une version simplifiée de la poignée de main moderne TLS 1.3 :

1. ClientHello : Le client envoie un message listant les versions TLS prises en charge, les suites de chiffrement et un nombre aléatoire.
2. ServerHello : Le serveur choisit une suite de chiffrement et envoie son propre nombre aléatoire.
3. Certificat du serveur : Le serveur envoie son certificat numérique, qui contient sa clé publique et son identité.
4. Échange de clés : En utilisant la clé publique du serveur et une technique comme Diffie-Hellman, les deux parties calculent un secret partagé—la clé de session.
5. Terminé : Les deux parties envoient un message chiffré confirmant que tout est en ordre. Désormais, toutes les données sont chiffrées avec la clé de session.

Dans TLS 1.3, cela se produit en un seul aller-retour, rendant les connexions plus rapides que les versions précédentes.

Qu'en est-il des certificats ?

Le certificat du serveur est un document numérique émis par un tiers de confiance appelé Autorité de Certification (CA). Il lie une clé publique à un nom de domaine. Votre navigateur vérifie la validité du certificat, son expiration et s'il a été émis par une CA de confiance. Si le domaine ne correspond pas ou si le certificat est expiré, vous verrez un avertissement.

Pour obtenir un certificat, les propriétaires de sites web utilisent le protocole ACME (souvent avec des outils comme Let's Encrypt) pour prouver qu'ils contrôlent le domaine. La CA signe ensuite le certificat avec sa propre clé privée. Cela crée une chaîne de confiance de votre navigateur à la CA puis au site web.

Chiffrement symétrique vs asymétrique

TLS utilise deux types de chiffrement :

• Chiffrement asymétrique (clé publique/privée) est utilisé pendant la poignée de main pour échanger des secrets en toute sécurité sans partager une clé à l'avance.
• Chiffrement symétrique (même clé pour le chiffrement et le déchiffrement) est utilisé pour le transfert de données réel car il est beaucoup plus rapide.

Par exemple, RSA est couramment utilisé pour l'échange de clés initial (bien que TLS 1.3 préfère Diffie-HHellman), et AES-GCM est un chiffrement symétrique populaire pour les données en volume.

Suites de chiffrement : les éléments de base

Une suite de chiffrement est une combinaison d'algorithmes qui définissent comment la poignée de main et le chiffrement fonctionnent. Par exemple, la suite TLS_AES_256_GCM_SHA384 signifie :

• Échange de clés : (impliqué par la suite dans TLS 1.3)
• Chiffrement en volume : AES en mode GCM avec une clé de 256 bits
• Hachage pour l'intégrité : SHA-384

Lors de la configuration d'un serveur, vous choisissez les suites de chiffrement à activer. Les suites plus anciennes comme ECDHE-RSA-AES128-GCM-SHA256 sont encore courantes. L'objectif est de privilégier les suites qui offrent une confidentialité persistante—ce qui signifie que même si la clé privée du serveur est compromise plus tard, les sessions passées restent sécurisées.

Voici une petite comparaison des versions TLS courantes :

Pièges courants et comment les éviter

Même avec TLS activé, des erreurs peuvent compromettre la sécurité :

• Contenu mixte : Servir certaines ressources via HTTP sur une page HTTPS. Les navigateurs bloquent de nombreux types de contenu mixte. Utilisez toujours des URL relatives ou HTTPS pour toutes les sous-ressources.
• Protocoles obsolètes : Laisser TLS 1.0 ou 1.1 activé expose les utilisateurs à des attaques. Désactivez-les sur votre serveur.
• Suites de chiffrement faibles : Certaines anciennes suites utilisent RC4 ou DES, qui sont facilement cassées. Utilisez des suites modernes avec confidentialité persistante.
• Expiration du certificat : Un certificat expiré provoque des erreurs. Automatisez le renouvellement avec certbot ou le renouvellement automatique de votre fournisseur.
• HSTS manquant : HTTP Strict Transport Security indique aux navigateurs d'utiliser toujours HTTPS, empêchant les attaques de déclassement. Ajoutez l'en-tête Strict-Transport-Security.

Pour tester la configuration TLS de votre serveur, vous pouvez utiliser des scanners en ligne comme le test de serveur SSL de SSL Labs (non affilié à nous). Ils évalueront votre configuration et signaleront les faiblesses.

Déboguer TLS avec OpenSSL

Parfois, vous avez besoin de voir ce qui se passe sur le fil. L'outil en ligne de commande openssl est votre ami. Par exemple, pour afficher le certificat d'un serveur :

openssl s_client -connect example.com:443 -showcerts

Cela affiche la chaîne de certificats et d'autres détails. Vous pouvez également tester une version TLS spécifique :

openssl s_client -tls1_2 -connect example.com:443

Si vous dépannez un client qui échoue à se connecter, cela vous montre exactement quels protocoles et chiffrements le serveur prend en charge.

Pourquoi TLS est important pour votre site web

Au-delà de la sécurité, HTTPS est un signal de classement pour les moteurs de recherche et une exigence pour de nombreuses fonctionnalités modernes des navigateurs comme la géolocalisation et les service workers. Si vous n'avez pas encore migré, faites-le maintenant. Des outils comme Let's Encrypt rendent cela gratuit et facile.

Une fois que vous êtes sur HTTPS, vous devriez également envisager d'utiliser un outil pour inspecter les journaux de votre serveur web afin de détecter toute anomalie. Par exemple, si vous utilisez un serveur Nginx, analyser vos journaux d'accès peut vous aider à repérer des échecs de poignée de main répétés ou des requêtes suspectes. Notre Analyseur de journaux Nginx peut vous aider à analyser et comprendre ces journaux rapidement.

FAQ

Quelle est la différence entre SSL et TLS ?

SSL (Secure Sockets Layer) est le prédécesseur de TLS. Toutes les versions de SSL sont obsolètes et non sécurisées. TLS est le protocole moderne, avec TLS 1.2 et 1.3 comme normes actuelles. Les gens disent souvent « SSL » pour désigner « TLS », mais techniquement, ce sont des choses différentes.

Comment le navigateur vérifie-t-il un certificat ?

Le navigateur vérifie la signature numérique du certificat en utilisant la clé publique de la CA émettrice. Il vérifie également que le certificat n'est pas expiré, que le domaine correspond et que la CA est dans son magasin de racines de confiance. Si l'une des vérifications échoue, le navigateur affiche un avertissement.

Qu'est-ce que la confidentialité persistante ?

La confidentialité persistante (ou confidentialité persistante parfaite) est une propriété des méthodes d'échange de clés comme ECDHE. Elle garantit que même si la clé privée à long terme du serveur est compromise, les clés de session passées ne peuvent pas être dérivées, donc le trafic enregistré reste confidentiel. TLS 1.3 impose des suites de chiffrement à confidentialité persistante.

Conclusion

HTTPS et TLS ne sont pas de la magie—c'est une combinaison bien conçue de cryptographie et de confiance. En comprenant la poignée de main, les certificats et les suites de chiffrement, vous pouvez prendre de meilleures décisions pour vos propres projets et résoudre les problèmes en toute confiance. Gardez vos protocoles à jour, utilisez des suites de chiffrement robustes et testez toujours votre configuration.

Prêt à mettre vos connaissances en pratique ? Si vous gérez un serveur Nginx, essayez notre Analyseur de journaux Nginx pour voir qui se connecte à votre site et repérer les problèmes de sécurité potentiels dans vos journaux.