Comment HTTPS et TLS fonctionnent vraiment : le handshake expliqué

Vous tapez une URL, appuyez sur Entrée, et un cadenas apparaît. Mais que se passe-t-il réellement entre votre navigateur et le serveur pour sécuriser cette connexion ? Beaucoup de développeurs considèrent HTTPS comme une boîte noire—jusqu'à ce qu'un problème survienne, comme une erreur de certificat ou un souci de performance. Cet article lève le voile sur TLS, le protocole derrière HTTPS, et explique le handshake en termes simples.

Ce qu'est vraiment HTTPS

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

• Confidentialité – les données sont chiffrées pour que les indiscrets 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 vrai serveur, pas à un imposteur.

Sans TLS, HTTP envoie tout en clair : mots de passe, cookies et données de formulaire sont visibles par quiconque sur le chemin réseau.

Le handshake TLS en langage clair

Le handshake est la négociation qui a lieu avant l'envoi de toute donnée applicative. Son objectif : s'accorder sur les algorithmes de chiffrement, vérifier l'identité du serveur et établir des clés secrètes partagées. Voici le déroulement pour TLS 1.3, le standard moderne :

1. Client Hello – le navigateur envoie une liste de suites de chiffrement prises en charge, une valeur aléatoire et sa part de clé (pour l'échange de clés).
2. Server Hello – le serveur choisit une suite de chiffrement, envoie sa propre valeur aléatoire et sa part de clé, et fournit sa chaîne de certificats.
3. Vérification du certificat – le navigateur vérifie le certificat par rapport aux autorités de certification racines de confiance, valide le nom de domaine et vérifie l'expiration.
4. Dérivation des clés – les deux parties calculent le même secret partagé grâce à l'échange de clés (généralement ECDHE). Les clés de session sont dérivées.
5. Finished – les deux parties envoient un MAC sur la transcription du handshake pour confirmer que rien n'a été altéré.

Ensuite, les données applicatives chiffrées circulent. En TLS 1.3, le handshake prend un aller-retour (1-RTT), et la reprise peut atteindre 0-RTT.

TLS 1.2 vs TLS 1.3

TLS 1.2 nécessitait deux allers-retours et prenait en charge des algorithmes plus faibles. TLS 1.3 a supprimé les chiffrements obsolètes, simplifié le handshake et chiffre davantage le handshake lui-même. Préférez toujours TLS 1.3 ; la plupart des serveurs et navigateurs modernes le prennent en charge.

Les certificats : l'ancre de confiance

Un certificat lie une clé publique à un nom de domaine et est signé par une autorité de certification (CA). Les navigateurs embarquent un magasin d'autorités racines de confiance. Lors de la vérification, le navigateur construit une chaîne depuis le certificat du serveur jusqu'à une racine de confiance.

Types de certificats courants :

• DV (Domain Validation) – prouve le contrôle du domaine ; rapide et gratuit (par ex. Let's Encrypt).
• OV (Organization Validation) – inclut les détails vérifiés de l'entreprise.
• EV (Extended Validation) – vérifications d'identité plus strictes ; n'affiche plus de barre verte dans la plupart des navigateurs.

Les certificats expirent. Automatisez le renouvellement avec des clients ACME comme Certbot pour éviter les interruptions.

Échange de clés et confidentialité persistante

Le TLS moderne utilise un échange de clés éphémère (ECDHE). Chaque session génère une nouvelle paire de clés, donc même si la clé privée du serveur est compromise plus tard, les sessions passées ne peuvent pas être déchiffrées. Cette propriété est appelée confidentialité persistante (forward secrecy). Évitez l'échange de clés RSA statique, qui n'offre pas cette protection.

Pièges HTTPS courants et comment les éviter

• Contenu mixte – charger des ressources HTTP sur une page HTTPS déclenche des avertissements du navigateur. Utilisez des URL relatives ou passez à HTTPS.
• Certificats expirés – mettez en place une surveillance et un renouvellement automatique.
• Suites de chiffrement faibles – désactivez TLS 1.0/1.1 et RC4/3DES. Utilisez un outil comme SSL Labs pour tester.
• HSTS manquant – ajoutez l'en-tête Strict-Transport-Security pour forcer HTTPS.

Déboguer les problèmes TLS

Lorsqu'un handshake échoue, utilisez openssl s_client pour inspecter la connexion :

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

Cela affiche la chaîne de certificats, le protocole négocié et le chiffrement. Pour les erreurs spécifiques au navigateur, consultez le panneau Sécurité dans les DevTools.

FAQ

HTTPS est-il identique à TLS ?

HTTPS est HTTP sur TLS. TLS est le protocole cryptographique ; HTTPS est la version sécurisée du protocole applicatif HTTP.

Ai-je besoin d'un certificat distinct pour chaque sous-domaine ?

Pas nécessairement. Un certificat wildcard couvre tous les sous-domaines de premier niveau, et un certificat multi-domaines (SAN) peut lister plusieurs noms.

Comment TLS 1.3 améliore-t-il les performances ?

TLS 1.3 réduit le handshake à un aller-retour (et zéro en reprise), et simplifie la négociation de chiffrement, ce qui réduit la latence.

Prêt à inspecter la sécurité de votre propre site ? Utilisez notre analyseur de logs Nginx pour repérer les erreurs TLS suspectes et les échecs de handshake dans vos logs.