Comment HTTPS et TLS fonctionnent vraiment : sous le capot
Vous tapez une URL, appuyez sur Entrée et voyez le cadenas. Mais que se passe-t-il réellement entre votre navigateur et le serveur pour rendre cette connexion sécurisée ? Beaucoup de développeurs considèrent HTTPS comme une boîte noire—jusqu'à ce que quelque chose casse, comme une erreur de certificat ou un problème de performance. Cet article lève le voile sur HTTPS et TLS, en expliquant le handshake, le chiffrement et la validation des certificats de manière pratique.
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 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 vrai serveur, pas à un imposteur.
TLS a évolué à partir de SSL (Secure Sockets Layer). Les versions modernes (TLS 1.2 et 1.3) sont celles à utiliser ; SSL est obsolète.
Le handshake TLS : étape par étape
Avant que toute donnée HTTP ne circule, le client et le serveur effectuent un handshake pour se mettre d'accord sur les clés de chiffrement. Voici ce qui se passe lors d'un handshake TLS 1.3 typique (simplifié) :
- 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.
- Server Hello : Le serveur choisit une suite de chiffrement, envoie sa propre valeur aléatoire et sa part de clé, et présente son certificat.
- Dérivation de clé : Les deux parties calculent le même secret partagé en utilisant l'échange de clés Diffie-Hellman. À partir de cela, elles dérivent des clés de session pour le chiffrement symétrique.
- Finished : Les deux parties envoient un MAC (Message Authentication Code) pour vérifier l'intégrité du handshake. Les données applicatives chiffrées peuvent maintenant circuler.
TLS 1.3 a réduit le handshake à un seul aller-retour (1-RTT) et prend même en charge 0-RTT pour les sessions reprises, améliorant la latence.
Échange de clés : Diffie-Hellman
La magie du TLS moderne est que le client et le serveur peuvent se mettre d'accord sur un secret partagé sans jamais le transmettre. Diffie-Hellman (plus précisément ECDHE pour courbe elliptique) le permet. Même si un attaquant enregistre tout le handshake, il ne peut pas dériver la clé de session—cette propriété est appelée forward secrecy (confidentialité persistante).
Chiffrement symétrique : AES ou ChaCha20
Une fois le secret partagé établi, TLS passe au chiffrement symétrique (comme AES-GCM ou ChaCha20-Poly1305) car c'est beaucoup plus rapide que la cryptographie asymétrique. Les clés de session sont utilisées pour chiffrer toutes les données applicatives.
Validation des certificats : faire confiance mais vérifier
Le certificat du serveur est au cœur de l'authentification. Il contient la clé publique du serveur et est signé par une autorité de certification (CA). Voici comment le navigateur le valide :
- Chaîne de confiance : Le certificat doit remonter jusqu'à une CA racine de confiance préinstallée dans le navigateur ou le système d'exploitation.
- Correspondance du nom d'hôte : Le certificat doit être valide pour le domaine que vous visitez (via les Subject Alternative Names).
- Période de validité : Le certificat ne doit pas être expiré ou pas encore valide.
- Révocation : Le navigateur peut vérifier OCSP ou CRL pour s'assurer que le certificat n'a pas été révoqué.
Si l'une de ces vérifications échoue, vous recevez un avertissement—comme « Votre connexion n'est pas privée ».
Mauvaises configurations TLS courantes
Même avec HTTPS activé, des erreurs peuvent affaiblir la sécurité :
- Protocoles obsolètes : Le support de TLS 1.0/1.1 ou SSLv3 vous expose à des attaques connues.
- Suites de chiffrement faibles : Autoriser RC4 ou des chiffrements en mode CBC sans atténuations.
- HSTS manquant : Sans HTTP Strict Transport Security, les utilisateurs peuvent être rétrogradés vers HTTP.
- Mauvaise gestion des certificats : Certificats expirés ou configuration de chaîne incorrecte.
Utilisez des outils comme le test SSL de SSL Labs pour vérifier votre configuration.
Exemple pratique : activer HTTPS avec Nginx
Voici une configuration Nginx minimale pour un serveur HTTPS sécurisé :
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_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
ssl_prefer_server_ciphers off;
add_header Strict-Transport-Security "max-age=63072000" always;
location / {
root /var/www/html;
index index.html;
}
}
Cette configuration utilise les certificats Let's Encrypt, n'active que TLS 1.2 et 1.3, et définit HSTS.
FAQ
Quelle est la différence entre TLS et SSL ?
TLS est le successeur de SSL. Les versions SSL (2.0, 3.0) sont obsolètes en raison de failles de sécurité. Quand les gens disent « certificat SSL », ils désignent généralement un certificat TLS.
HTTPS ralentit-il mon site web ?
Le TLS moderne (1.3) ajoute une latence minimale—souvent juste quelques millisecondes. Avec la reprise de session et HTTP/2, HTTPS peut être aussi rapide ou plus rapide que HTTP.
Comment obtenir un certificat TLS gratuit ?
Let's Encrypt fournit des certificats gratuits et automatisés. Des outils comme Certbot peuvent les obtenir et les renouveler pour vous.
Conclusion
HTTPS et TLS ne sont pas magiques—ce sont des protocoles bien conçus qui combinent la cryptographie à clé publique pour l'authentification avec le chiffrement symétrique pour la vitesse. Comprendre le handshake et la validation des certificats vous aide à déboguer les problèmes et à configurer vos serveurs en toute sécurité. Utilisez toujours TLS 1.2 ou 1.3, gardez les certificats à jour et activez HSTS.
Pour analyser les journaux de serveur afin de repérer les erreurs TLS ou les problèmes de performance, essayez notre Analyseur de journaux Nginx.