Comment HTTPS et TLS fonctionnent vraiment : guide pratique

Security2026-11-03TryQuickToolBox

Vous avez probablement déjà vu l'icône de cadenas dans votre navigateur et supposé que cela signifiait qu'un site était sécurisé. Mais que se passe-t-il réellement lorsque vous visitez une URL HTTPS ? Pourquoi certains certificats déclenchent-ils des avertissements ? Et comment savoir si une connexion est vraiment chiffrée de bout en bout ? Ce guide décompose HTTPS et TLS en termes pratiques, en vous montrant les étapes de la poignée de main, comment les certificats sont validés et comment inspecter de vraies connexions à l'aide d'outils en ligne de commande. À la fin, vous comprendrez suffisamment la mécanique pour déboguer les problèmes TLS et prendre des décisions éclairées concernant votre propre sécurité web.

Ce qu'est réellement HTTPS

HTTPS est HTTP superposé à TLS (Transport Layer Security). TLS offre trois garanties :

Confidentialité : Les données sont chiffrées afin que les oreilles indiscrètes ne puissent pas les lire.
Intégrité : Les données ne peuvent pas être modifiées en transit sans être détectées.
Authentification : Vous parlez au serveur qui possède le domaine, pas à un imposteur.

Sans TLS, HTTP envoie tout en texte clair—mots de passe, cookies et contenu—sur le réseau. TLS enveloppe ce trafic dans un tunnel chiffré. Le cadenas signifie que la connexion est chiffrée et que le certificat est valide, mais cela ne signifie pas que le site est digne de confiance ou sécurisé d'autres manières (par exemple, il pourrait toujours avoir des vulnérabilités).

La poignée de main TLS en termes simples

Avant tout échange de données HTTP, le client et le serveur effectuent une poignée de main TLS. Les étapes exactes varient légèrement entre TLS 1.2 et 1.3, mais l'idée centrale est la même : s'accorder sur les algorithmes, authentifier le serveur et établir des clés partagées. Voici un flux simplifié pour TLS 1.3 (la norme moderne) :

Client Hello : Le client envoie une liste de suites de chiffrement prises en charge, une valeur aléatoire et un échange de clés (pour l'échange de clés).
Server Hello : Le serveur choisit une suite de chiffrement, envoie sa propre valeur aléatoire et son échange de clés, et fournit sa chaîne de certificats.
Validation du certificat : Le client vérifie la validité du certificat, le nom de domaine et la chaîne de confiance.
Dérivation de clé : Les deux parties calculent le même secret partagé à l'aide de Diffie-Hellman (souvent X25519). À partir de cela, elles dérivent des clés de session symétriques.
Finished : Les deux parties envoient un MAC sur la transcription de la poignée de main pour confirmer que rien n'a été altéré.

Après la poignée de main, les données applicatives (requêtes/réponses HTTP) sont chiffrées avec les clés de session. TLS 1.3 réduit la poignée de main à un aller-retour (1-RTT) et prend en charge la reprise 0-RTT, ce qui le rend plus rapide que TLS 1.2.

Validation des certificats : comment votre navigateur décide de faire confiance à un site

Lorsque le serveur envoie son certificat, le client doit le vérifier. Le navigateur (ou votre client HTTP) effectue plusieurs contrôles :

Chaîne de confiance : Le certificat doit être signé par une autorité de certification (CA) de confiance ou une CA intermédiaire qui remonte à une CA racine dans le magasin de confiance du client.
Nom de domaine : Le Subject Alternative Name (SAN) du certificat doit inclure le nom d'hôte auquel vous vous connectez.
Période de validité : Le certificat ne doit pas être expiré ou pas encore valide.
Révocation : Le client peut vérifier OCSP ou CRL pour voir si le certificat a été révoqué (bien que cela soit souvent fait au mieux).

Si l'un des contrôles échoue, le navigateur affiche un avertissement. Par exemple, un certificat auto-signé déclenche « Votre connexion n'est pas privée » car il n'est pas signé par une CA de confiance.

Inspecter une vraie connexion TLS

Vous pouvez voir les détails de la poignée de main vous-même en utilisant OpenSSL. Exécutez cette commande dans votre terminal (remplacez le nom d'hôte) :

openssl s_client -connect example.com:443 -servername example.com -showcerts

La sortie inclut la chaîne de certificats, le chiffrement négocié et la version TLS. Recherchez des lignes comme :

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit

Cela vous indique que la connexion utilise TLS 1.3 avec AES-256-GCM. Vous pouvez également utiliser curl -v https://example.com pour voir le résumé de la poignée de main TLS.

Mauvaises configurations TLS courantes et comment les repérer

Même avec HTTPS activé, des erreurs de configuration peuvent affaiblir la sécurité. Voici les problèmes fréquents :

Problème	Risque	Comment vérifier
Protocoles faibles (TLS 1.0/1.1)	Vulnérable aux attaques connues	`openssl s_client -tls1_1 -connect host:443` devrait échouer
Certificat expiré	Avertissements du navigateur, confiance rompue	Vérifiez l'expiration avec `openssl s_client \| openssl x509 -noout -dates`
Certificats intermédiaires manquants	Certains clients ne parviennent pas à valider	Utilisez `-showcerts` et vérifiez la complétude de la chaîne
En-tête HSTS absent	Attaques par rétrogradation possibles	Vérifiez la présence de l'en-tête `Strict-Transport-Security`

Corriger ces problèmes implique généralement de mettre à jour la configuration du serveur (par exemple, dans Nginx : ssl_protocols TLSv1.2 TLSv1.3;) et de s'assurer que votre chaîne de certificats est complète.

HTTPS en pratique : ce que les développeurs doivent faire

Utilisez uniquement TLS 1.2 ou 1.3 ; désactivez les versions plus anciennes.
Obtenez des certificats auprès d'une CA de confiance (Let's Encrypt est gratuit et automatisé).
Activez HSTS pour forcer HTTPS.
Renouvelez régulièrement les certificats et surveillez leur expiration.
Testez votre configuration avec des outils comme SSL Labs (qualys.com/ssllabs) ou testssl.sh.

Si vous déboguez des journaux de serveur, l'Analyseur de journaux Nginx peut vous aider à repérer les échecs de poignée de main TLS et les erreurs de certificat dans vos journaux d'accès.

FAQ

Quelle est la différence entre TLS et SSL ?

SSL est le prédécesseur de TLS. SSL 2.0 et 3.0 sont obsolètes et non sécurisés ; les systèmes modernes utilisent TLS 1.2 ou 1.3. Les gens disent souvent « SSL » familièrement, mais ils veulent dire TLS.

HTTPS rend-il un site web complètement sécurisé ?

Non. HTTPS chiffre le trafic et authentifie le serveur, mais il ne protège pas contre des vulnérabilités comme l'injection SQL, XSS ou des permissions mal configurées. C'est une couche de sécurité.

Comment puis-je vérifier si un site prend en charge TLS 1.3 ?

Utilisez openssl s_client -connect host:443 -tls1_3. Si la poignée de main réussit, TLS 1.3 est pris en charge. Vous pouvez également vérifier le protocole dans les outils de développement de votre navigateur sous l'onglet Sécurité.

Comprendre la poignée de main TLS et la validation des certificats vous aide à construire et maintenir des services web sécurisés. Lorsque vous avez besoin d'analyser les journaux du serveur pour des erreurs TLS ou des problèmes de performance, essayez l'Analyseur de journaux Nginx pour analyser et filtrer rapidement les entrées de journal.