Comment HTTPS et TLS fonctionnent vraiment : le handshake expliqué

Vous avez ajouté un certificat, le navigateur affiche un cadenas, et vous passez à autre chose. Puis un jour, un client API échoue avec SSL_ERROR_RX_RECORD_TOO_LONG, une application mobile rejette votre chaîne, ou une boucle de redirection apparaît après avoir activé HSTS. Soudain, HTTPS ressemble à une boîte noire.

Cet article ouvre cette boîte. Nous allons parcourir ce qui se passe réellement pendant un handshake TLS, pourquoi les certificats existent, où le chiffrement symétrique et asymétrique intervient, et comment déboguer les échecs que vous rencontrerez concrètement en production.

Ce qu'est réellement HTTPS

HTTPS n'est pas un protocole séparé. C'est du HTTP simple envoyé sur une connexion chiffrée TLS. Le schéma d'URL change, le port par défaut passe de 80 à 443, et tout le reste — méthodes, en-têtes, codes de statut, cookies — se comporte de la même manière.

TLS vous apporte trois garanties au-dessus de TCP :

• Confidentialité — les intermédiaires ne peuvent pas lire le trafic.
• Intégrité — toute altération en transit est détectée.
• Authentification — le client peut vérifier qu'il parle bien au serveur qui possède le domaine.

C'est cette troisième garantie que l'on sous-estime. Le chiffrement sans authentification ne vaut rien : un attaquant capable d'intercepter le trafic pourrait simplement présenter sa propre clé.

Le handshake TLS 1.3, étape par étape

TLS 1.3 a considérablement simplifié le handshake par rapport à TLS 1.2. Voici le déroulement entre un navigateur et un serveur :

1. ClientHello — le client envoie les versions TLS prises en charge, les suites de chiffrement, une valeur aléatoire et une part de clé pour un groupe Diffie-Hellman (par exemple X25519).
2. ServerHello — le serveur choisit une suite de chiffrement et envoie sa propre part de clé. Les deux côtés peuvent maintenant dériver le même secret partagé.
3. Extensions chiffrées et certificat — le serveur envoie sa chaîne de certificats, déjà chiffrée avec les clés dérivées.
4. Finished — les deux côtés envoient un MAC sur la transcription du handshake pour prouver que rien n'a été altéré.
5. Données applicatives — les requêtes et réponses HTTP circulent sur la session établie.

En TLS 1.3, le handshake complet coûte un aller-retour, et la reprise de session peut atteindre zéro aller-retour. TLS 1.2 nécessitait deux allers-retours avant que la moindre donnée applicative puisse circuler.

Pourquoi le certificat est envoyé après la dérivation des clés

En TLS 1.3, le certificat est chiffré. Cela signifie qu'un observateur passif ne peut même pas voir quel domaine le client visite à partir du certificat seul, ce qui réduit les fuites d'information. Cela signifie aussi que les outils de débogage qui s'attendent à un certificat en clair dans les premiers paquets seront perdus.

Chiffrement symétrique vs asymétrique

Une idée fausse courante est que HTTPS chiffre tout avec la clé publique du serveur. Ce n'est pas le cas. La cryptographie asymétrique est lente et limitée en taille ; elle sert uniquement à établir un secret partagé.

L'échange de clés Diffie-Hellman possède une propriété précieuse appelée confidentialité persistante (forward secrecy) : même si la clé privée du serveur fuite plus tard, les sessions passées enregistrées ne peuvent pas être déchiffrées, car les clés de session n'ont jamais été dérivées de cette clé à long terme.

Ce que contient un certificat

Un certificat X.509 lie une clé publique à un nom de domaine. Il contient :

• Le sujet (domaine) et les noms alternatifs du sujet (SAN), qui sont ce que les navigateurs vérifient réellement.
• La clé publique et son algorithme.
• La période de validité.
• L'émetteur et une signature de cet émetteur.

Les navigateurs font confiance à un ensemble fixe d'autorités de certification racines. Votre serveur envoie un certificat intermédiaire, et le navigateur construit une chaîne depuis votre certificat feuille jusqu'à une racine de confiance. Si l'intermédiaire est manquant, les navigateurs de bureau peuvent encore fonctionner car ils mettent en cache les intermédiaires, tandis que les clients mobiles et les outils en ligne de commande échouent. C'est l'erreur TLS de production la plus courante.

Étapes pratiques de débogage

Quand HTTPS se comporte mal, travaillez de l'extérieur vers l'intérieur.

1. Vérifiez la chaîne avec openssl s_client -connect example.com:443 -servername example.com -showcerts. Confirmez que le serveur envoie la chaîne complète, pas seulement la feuille.
2. Vérifiez l'expiration — les certificats expirés produisent des échecs définitifs sans contournement.
3. Vérifiez le nom d'hôte — la liste SAN doit contenir le nom d'hôte exact demandé par le client, y compris tout préfixe www.
4. Vérifiez la version du protocole — si un client legacy ne supporte que TLS 1.0 et que votre serveur exige TLS 1.2+, le handshake échoue avant HTTP.
5. Vérifiez les redirections — une redirection de HTTPS vers HTTP et retour crée une boucle ; corrigez-la dans la configuration du serveur, pas dans le code applicatif.

# Inspecter la chaîne de certificats et le protocole négocié
openssl s_client -connect example.com:443 \
  -servername example.com -showcerts < /dev/null 2>&1 | \
  openssl x509 -noout -subject -issuer -dates

# Tester une version TLS spécifique
openssl s_client -connect example.com:443 -tls1_2 < /dev/null

Dans Nginx, la directive ssl_certificate doit pointer vers un fichier contenant le certificat feuille suivi de l'intermédiaire, dans cet ordre. Les concaténer dans le mauvais ordre produit des erreurs de chaîne faciles à manquer.

HSTS et le coût d'une erreur

HTTP Strict Transport Security indique aux navigateurs d'utiliser HTTPS pour un domaine pendant une période donnée. C'est puissant et sans pitié : une fois qu'un navigateur a vu un long max-age, il refusera le HTTP simple même si vous désactivez HTTPS sur le serveur plus tard.

Commencez par un max-age court, vérifiez que tout fonctionne, puis augmentez-le. Ajoutez includeSubDomains seulement après que chaque sous-domaine serve du HTTPS valide. Le préchargement est effectivement permanent — ne le demandez que lorsque vous êtes certain.

Mauvaises configurations courantes

• Contenu mixte — une page HTTPS chargeant des scripts ou des images en HTTP. Les navigateurs bloquent le contenu mixte actif et avertissent pour le contenu passif.
• Suites de chiffrement faibles — laisser activés les chiffrements en mode CBC et les anciennes versions de protocole pour une compatibilité dont vous n'avez plus besoin.
• Gestion OCSP ou CRL manquante — la vérification de révocation est peu fiable en pratique ; les certificats à courte durée de vie sont la réponse plus robuste.
• Lacunes dans l'automatisation des certificats — le renouvellement fonctionne, mais l'étape de rechargement qui fait prendre en compte le nouveau certificat par le serveur est manquante.

Traitez le renouvellement de certificat comme un pipeline de déploiement, pas comme un rappel dans le calendrier. Si le renouvellement nécessite un humain, il finira par échouer au pire moment.

FAQ

HTTPS chiffre-t-il le nom de domaine que je visite ?

Le domaine apparaît dans l'extension TLS SNI et est généralement visible sur le réseau. Le chemin et la chaîne de requête sont chiffrés, mais un observateur réseau peut typiquement voir à quel hôte vous vous êtes connecté.

Pourquoi mon site fonctionne-t-il dans un navigateur mais échoue dans curl ou une application mobile ?

Presque toujours un certificat intermédiaire manquant. Les navigateurs mettent souvent en cache les intermédiaires des visites précédentes, tandis que curl et de nombreuses piles HTTP mobiles exigent que le serveur envoie la chaîne complète.

TLS 1.3 est-il toujours meilleur que TLS 1.2 ?

Pour les clients modernes, oui — moins d'allers-retours, un ensemble de suites de chiffrement plus restreint et la confidentialité persistante par défaut. Ne gardez TLS 1.2 activé que si vous servez encore des clients qui ne peuvent pas négocier 1.3.

Lorsque vous devez inspecter les logs des serveurs qui terminent TLS, un passage rapide par l'analyseur de logs Nginx vous aide à repérer les échecs de handshake, les boucles de redirection et les comportements clients inhabituels avant qu'ils ne deviennent des pannes.