Comment HTTPS et TLS fonctionnent vraiment : le handshake expliqué

Vous avez tapé https:// devant une URL, vu le cadenas et continué. Mais quand un certificat expire à 2 h du matin, qu'un avertissement de contenu mixte casse votre page de paiement, ou qu'un client demande pourquoi son appel API échoue avec une erreur TLS, « le cadenas signifie que c'est sécurisé » cesse d'être une réponse utile. Cet article explique ce qui se passe réellement sur le fil lors d'une connexion HTTPS et comment la configurer sans deviner.

Ce que HTTPS ajoute à HTTP

HTTPS est du HTTP simple transporté dans une session TLS (Transport Layer Security). TLS offre trois garanties concrètes :

• Confidentialité — le trafic est chiffré, les intermédiaires ne peuvent pas le lire.
• Intégrité — toute altération en transit est détectée et la connexion échoue.
• Authentification — le serveur prouve qu'il contrôle la clé privée du certificat présenté.

Notez ce qui n'est pas dans cette liste : HTTPS ne dit rien sur la fiabilité du serveur, sur la présence de vulnérabilités applicatives, ni sur la sécurité des données au repos. Il protège le tuyau, pas les extrémités.

Le handshake TLS, étape par étape

Le handshake est la négociation qui a lieu avant que le moindre octet HTTP ne circule. En TLS 1.3, il ne faut qu'un aller-retour ; TLS 1.2 en nécessite deux. Voici le déroulement TLS 1.3 en termes simples :

1. ClientHello — le client envoie les versions TLS supportées, une liste de suites de chiffrement, un nonce aléatoire et une part de clé pour un échange de clés Diffie-Hellman (généralement X25519).
2. ServerHello — le serveur choisit une version et une suite de chiffrement, renvoie sa propre part de clé et envoie sa chaîne de certificats ainsi qu'une signature sur la transcription du handshake.
3. Dérivation des clés — les deux parties calculent le secret partagé à partir de l'échange Diffie-Hellman. Les clés éphémères garantissent que la clé de session est unique et que la confidentialité persistante (forward secrecy) est assurée : compromettre plus tard la clé à long terme du serveur ne permet pas de déchiffrer le trafic enregistré.
4. Finished — les deux parties envoient un MAC sur la transcription. Si quelque chose a été altéré, le handshake est interrompu.
5. Données applicatives — les requêtes et réponses HTTP sont chiffrées avec des clés symétriques dérivées du secret partagé.

Le certificat est le siège de l'authentification. Le serveur signe le handshake avec sa clé privée ; le client vérifie cette signature à l'aide de la clé publique du certificat, puis vérifie le certificat lui-même auprès d'une autorité de certification racine de confiance, en contrôlant le nom d'hôte, les dates de validité et le statut de révocation.

Symétrique vs asymétrique : pourquoi les deux sont utilisés

La cryptographie asymétrique (RSA ou ECDSA) est lente mais résout la distribution des clés. Les chiffrements symétriques (AES-GCM, ChaCha20-Poly1305) sont rapides mais nécessitent une clé partagée. TLS n'utilise la cryptographie asymétrique que pendant le handshake pour établir une clé de session symétrique, puis chiffre les données en vrac avec cette clé. C'est pourquoi une connexion TLS 1.3 moderne est rapide : un aller-retour, puis du bon vieil AES ou ChaCha20 pour tout le reste.

Les suites de chiffrement et ce qui compte vraiment

Une suite de chiffrement est un ensemble nommé d'algorithmes. En TLS 1.3, la liste est courte et toutes les options sont considérées comme sûres ; en TLS 1.2, il faut choisir avec soin. Une comparaison rapide :

À retenir en pratique : activez uniquement TLS 1.2 et 1.3, désactivez TLS 1.0/1.1 et privilégiez les certificats ECDSA pour un coût de handshake réduit. Laissez votre serveur ou reverse proxy choisir l'ordre des suites ; la plupart des valeurs par défaut sont saines dans les logiciels de l'ère 2024.

Comment inspecter une connexion réelle

Pas besoin de faire confiance à la documentation — vérifiez vos propres points de terminaison. openssl s_client affiche la version négociée, le chiffrement et la chaîne de certificats :

openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

Regardez les lignes Protocol et Cipher, puis vérifiez la sortie de la chaîne de certificats pour l'expiration et les entrées SAN. Si la chaîne est incomplète, certains clients échoueront alors que les navigateurs réussiront, ce qui est une source classique de bugs « ça marche dans Chrome mais pas dans curl ».

Mauvaises configurations HTTPS courantes

• Certificat intermédiaire manquant — le serveur n'envoie que son certificat feuille. Les navigateurs peuvent récupérer l'intermédiaire, mais les clients API souvent non.
• Contenu mixte — une page HTTPS charge un script ou une image en HTTP ; les navigateurs le bloquent ou le dégradent. Auditez avec la console de votre navigateur.
• Pas de HSTS — sans Strict-Transport-Security, une première requête en HTTP peut être interceptée avant que la redirection n'ait lieu.
• Versions de protocole faibles ou obsolètes — laisser TLS 1.0 activé pour un client hérité affaiblit discrètement chaque connexion.
• Expiration de certificat — automatisez le renouvellement ; un rappel manuel dans le calendrier n'est pas une stratégie.

Une configuration serveur raisonnable

Pour Nginx, un bloc moderne minimal ressemble à ceci :

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Le fichier fullchain.pem est ce qui évite le problème du certificat intermédiaire manquant. Gardez la redirection depuis le port 80 dans un bloc serveur séparé pour que HTTP fonctionne encore pour les défis ACME.

Ce que HTTPS ne protège pas

Une fois la requête arrivée à votre serveur, TLS a terminé son travail. Les failles d'injection, les contrôles d'accès défaillants, les secrets divulgués dans les logs et les CORS mal configurés vivent tous au-dessus de la couche transport. Considérez TLS comme la base, pas comme le programme de sécurité. Si vous diagnostiquez un incident, séparez tôt les problèmes de transport (échecs de handshake, certificats expirés) des problèmes applicatifs (500, payloads incorrects) — les correctifs sont complètement différents.

FAQ

HTTPS chiffre-t-il le chemin d'URL et la chaîne de requête ?

Oui. En HTTPS, toute la requête HTTP, y compris le chemin et la chaîne de requête, se trouve à l'intérieur de l'enregistrement TLS chiffré. Cependant, le nom d'hôte (SNI) et l'IP de destination sont visibles pendant le handshake, sauf si Encrypted Client Hello est utilisé.

TLS 1.3 est-il toujours plus rapide que TLS 1.2 ?

Généralement oui, car il économise un aller-retour et prend en charge la reprise 0-RTT. Sur les connexions à forte latence, la différence est notable ; sur un réseau local, elle est mineure. Le gain principal est que TLS 1.3 supprime entièrement les options de chiffrement héritées.

Ai-je encore besoin de HSTS si je redirige HTTP vers HTTPS ?

Oui. Une redirection n'aide qu'une fois que le navigateur a atteint votre serveur. HSTS indique au navigateur d'ignorer complètement HTTP pour les requêtes futures, fermant la fenêtre où une première requête pourrait être interceptée.

Lorsque vous auditez un déploiement et devez vérifier les détails d'un certificat ou décoder rapidement un handshake capturé, gardez un flux de travail en terminal à portée de main — et si vous documentez les résultats pour une équipe, le Markdown editor est un moyen rapide de transformer la sortie brute d'openssl en un rapport lisible.