Comment HTTPS et TLS fonctionnent vraiment : guide pratique
Pourquoi HTTPS est important (et pourquoi vous devriez le comprendre)
Vous avez probablement déjà vu l'icône de cadenas dans votre navigateur et vous savez que HTTPS chiffre le trafic. Mais lorsqu'une erreur de certificat apparaît, ou qu'un appel API échoue avec une erreur TLS, savez-vous exactement ce qui se passe ? De nombreux développeurs considèrent HTTPS comme une boîte noire—jusqu'à ce que quelque chose casse. Ce guide explique comment HTTPS et TLS fonctionnent réellement, du handshake à la chaîne de certificats, afin que vous puissiez déboguer les problèmes en toute confiance.
Les bases : HTTPS = HTTP + TLS
HTTPS est simplement HTTP superposé à TLS (Transport Layer Security). TLS offre trois garanties :
- Chiffrement : Les données sont brouillées pour que les oreilles indiscrètes ne puissent pas les lire.
- Authentification : Vous parlez au vrai serveur, pas à un imposteur.
- Intégrité : Les données ne peuvent pas être modifiées en transit sans être détectées.
Avant TLS 1.3, le protocole s'appelait SSL (Secure Sockets Layer), mais SSL est obsolète. Aujourd'hui, TLS 1.2 et 1.3 sont les standards.
Le handshake TLS : étape par étape
Le handshake est le moment où la magie opère. C'est une conversation qui établit un canal sécurisé avant que toute donnée HTTP ne soit envoyée. Voici une version simplifiée pour TLS 1.2 (TLS 1.3 est plus rapide mais similaire dans le concept) :
- Client Hello : Le client envoie les versions TLS prises en charge, les suites de chiffrement et une valeur aléatoire (Client Random).
- Server Hello : Le serveur choisit une version TLS et une suite de chiffrement, envoie sa propre valeur aléatoire (Server Random) et présente son certificat.
- Vérification du certificat : Le client vérifie le certificat par rapport aux autorités de certification racines de confiance, à l'expiration et au nom de domaine.
- Échange de clés : À l'aide d'algorithmes comme ECDHE, les deux parties dérivent un secret partagé (pre-master secret) sans jamais l'envoyer sur le réseau.
- Finished : Les deux côtés vérifient l'intégrité du handshake et passent à une communication chiffrée en utilisant des clés symétriques dérivées du secret partagé.
Dans TLS 1.3, le handshake est réduit à un aller-retour (1-RTT) et prend même en charge 0-RTT pour les sessions reprises, améliorant ainsi la latence.
Pourquoi le chiffrement asymétrique n'est utilisé qu'au début
La cryptographie asymétrique (comme RSA ou ECDSA) est lente et coûteuse en calcul. TLS ne l'utilise que pour échanger de manière sécurisée une clé de session symétrique, qui est ensuite utilisée pour le chiffrement en masse (par exemple, AES-GCM ou ChaCha20-Poly1305). Cette approche hybride équilibre sécurité et performance.
Certificats et chaîne de confiance
Un certificat lie une clé publique à un nom de domaine et est signé par une autorité de certification (CA). Les navigateurs et systèmes d'exploitation sont livrés avec un magasin d'autorités de certification racines de confiance. Lorsqu'un serveur présente son certificat, le client construit une chaîne depuis le certificat du serveur jusqu'à une CA intermédiaire et enfin jusqu'à une racine de confiance.
Les erreurs de certificat courantes incluent :
- Certificat expiré : La période de validité du certificat est terminée.
- Incohérence de nom d'hôte : Le Subject Alternative Name (SAN) du certificat ne correspond pas au domaine demandé.
- Émetteur non approuvé : La CA racine ne figure pas dans le magasin de confiance du client (par exemple, certificats auto-signés).
- Chaîne incomplète : Le serveur n'a pas envoyé les certificats intermédiaires, donc le client ne peut pas construire un chemin vers une racine de confiance.
Des outils comme openssl s_client ou des vérificateurs SSL en ligne aident à diagnostiquer ces problèmes.
Débogage des connexions HTTPS
Lorsque HTTPS échoue, vous devez inspecter le handshake. Voici des commandes pratiques :
# Vérifier les détails du certificat et la chaîne
openssl s_client -connect example.com:443 -servername example.com -showcerts
# Vérifier la version TLS et la suite de chiffrement
openssl s_client -connect example.com:443 -tls1_3
# Tester l'expiration du certificat
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
Dans les navigateurs, le panneau Sécurité des outils de développement affiche les détails de connexion, et curl -v https://example.com révèle les étapes du handshake.
Mauvaises configurations TLS courantes
Même avec HTTPS activé, des erreurs de configuration peuvent affaiblir la sécurité ou casser la compatibilité :
| Problème | Impact | Correctif |
|---|---|---|
| Suites de chiffrement faibles activées | Vulnérable aux attaques par rétrogradation | Désactiver RC4, DES et les chiffrements d'exportation ; préférer les chiffrements AEAD |
| En-tête HSTS manquant | Vulnérable au SSL stripping | Ajouter l'en-tête Strict-Transport-Security |
| Chaîne de certificats incomplète | Erreurs sur certains clients | Inclure les certificats intermédiaires dans la configuration du serveur |
| Anciennes versions TLS autorisées (1.0/1.1) | Risques de conformité et de sécurité | Désactiver TLS 1.0 et 1.1 ; imposer TLS 1.2+ |
Comment inspecter TLS en pratique
Si vous déboguez un serveur web, commencez par vérifier la chaîne de certificats et la suite de chiffrement. Pour Nginx, assurez-vous que votre configuration inclut la chaîne complète :
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
Utilisez des outils en ligne comme SSL Labs pour un rapport complet, mais vérifiez toujours avec des outils en ligne de commande pour des contrôles rapides.
FAQ
Quelle est la différence entre TLS et SSL ?
SSL est le prédécesseur de TLS. Les versions SSL 2.0 et 3.0 sont obsolètes en raison de vulnérabilités de sécurité. TLS 1.2 et 1.3 sont les protocoles sécurisés actuels.
Pourquoi mon navigateur affiche-t-il un avertissement de certificat alors que le certificat est valide ?
Les causes courantes incluent une chaîne de certificats incomplète, une incohérence de nom d'hôte ou un certificat émis par une CA non approuvée par votre système. Vérifiez le SAN du certificat et assurez-vous que les intermédiaires sont servis.
Comment puis-je vérifier quelle version TLS mon serveur prend en charge ?
Utilisez openssl s_client -connect yourdomain.com:443 -tls1_3 (ou -tls1_2) et recherchez le protocole dans la sortie. Des outils en ligne comme SSL Labs fournissent également des rapports détaillés.
Lorsque vous avez besoin d'inspecter ou de formater rapidement des données JSON à partir de réponses API pendant le débogage, le JSON Formatter peut vous aider à visualiser et valider la structure.