Comment TLS sécurise réellement une connexion HTTPS ?

Les gens disent « HTTPS signifie que c'est chiffré » et s'arrêtent là, mais la partie intéressante est de savoir comment deux étrangers sur internet conviennent d'un secret partagé sans jamais se rencontrer, sur un réseau rempli de gens qui pourraient écouter. C'est ce que fait TLS, et les mécanismes méritent d'être compris si vous touchez au networking, au web dev ou à la sécurité.

La poignée de main, étape par étape

Quand votre navigateur se connecte à https://example.com, voici ce qui se passe à peu près (TLS 1.3, que la plupart des sites utilisent maintenant) :

1. ClientHello — le navigateur envoie les suites de chiffrement supportées, un nonce aléatoire et une tentative de partage de clé (utilisant quelque chose comme X25519 ou secp256r1) pour l'échange de clés.
2. ServerHello — le serveur choisit une suite de chiffrement, envoie son propre partage de clé et retourne son certificat plus une signature prouvant qu'il détient la clé privée correspondant à ce certificat.
3. Dérivation de clé — les deux côtés calculent maintenant indépendamment le même secret partagé en utilisant les mathématiques de type Diffie-Hellman sur leurs partages de clé. Aucun ne transmet jamais le secret lui-même ; il est dérivé, pas envoyé.
4. Messages Finished — les deux côtés confirment que la poignée de main n'a pas été altérée en envoyant un MAC sur tout le transcript de la poignée de main.

Après cela, tout est chiffré avec des clés symétriques dérivées du secret partagé, généralement AES-128-GCM ou ChaCha20-Poly1305. TLS 1.3 a réduit cela par rapport au handshake à deux allers-retours de TLS 1.2 à effectivement un aller-retour, ce qui est un vrai gain de latence à l'échelle.

Pourquoi le certificat compte plus que le chiffrement

Le chiffrement sans vérification d'identité n'a aucun sens — n'importe qui peut mettre en place un canal chiffré, y compris un attaquant exécutant une attaque de l'homme du milieu. Le certificat est ce qui lie une clé publique à un nom de domaine, et il est signé par une autorité de certification (AC) comme Let's Encrypt ou DigiCine.

Votre navigateur fait confiance à une liste fixe d'AC racines intégrée dans le magasin de confiance de l'OS ou du navigateur. Le certificat du serveur remonte via des certificats intermédiaires jusqu'à l'une de ces racines. Si la chaîne ne se valide pas ou si le domaine du certificat ne correspond pas à celui que vous avez demandé, vous obtenez la page d'avertissement rouge. Ce modèle de chaîne de confiance est la limite de sécurité réelle — volez la clé de signature d'une AC et vous pouvez émettre des certificats valides pour n'importe quel domaine, c'est pourquoi les compromissions d'AC sont traitées comme des incidents majeurs.

Ce que le crypto symétrique par rapport au asymétrique fait ici

Le crypto asymétrique (RSA ou courbe elliptique) est lent et coûteux, donc TLS ne l'utilise que lors de la poignée de main — pour authentifier le serveur et aider à établir le secret partagé. Une fois que c'est fait, toutes les données réelles (HTML, JSON, peu importe) sont chiffrées avec des chiffres symétriques rapides. Cette approche hybride est le même motif que vous verrez dans SSH, PGP et la plupart des systèmes cryptographiques réels : asymétrique pour l'identité et l'échange de clés, symétrique pour les données volumineuses. La confidentialité persistante est un détail connexe qui mérite d'être connu : parce que le secret partagé provient de partages de clé Diffie-Hellman éphémères générés frais par session, même si quelqu'un enregistre votre trafic et vole plus tard la clé privée du serveur, il ne peut toujours pas déchiffrer les anciennes sessions. Cette propriété n'existait pas dans l'ancien échange de clé basé uniquement sur RSA.

Vérifier vous-même

Vous n'avez pas besoin de faire confiance aveuglément à une icône de cadenas vert. Exécutez :

openssl s_client -connect example.com:443 -tls1_3

Cela vous montre la suite de chiffrement négociée, la chaîne de certificats et si la poignée de main s'est réellement complétée. Pour un aperçu plus rapide de ce qu'un navigateur voit, curl -v https://example.com affiche la version TLS et les détails du certificat avant la réponse HTTP.

Vous pouvez également déchiffrer votre propre trafic dans Wireshark si vous exportez la variable d'environnement SSLKEYLOGFILE avant de lancer Chrome ou Firefox — véritablement utile pour déboguer les problèmes TLS au lieu de deviner.

Où cela se casse vraiment en pratique

La plupart des échecs HTTPS réels ne sont pas des cassures cryptographiques, ce sont des opérationnels : certificats expirés, chaînes intermédiaires mal configurées, clients bloqués sur d'anciennes versions TLS, ou contenu mixte (une page HTTPS chargeant une ressource HTTP). Les attaques réelles au niveau du protocole contre TLS 1.3 moderne sont rares car la spec a fermé la plupart des astuces d'oracle de remplissage et de rétrogradation qui ont tourmenté SSL 3.0 et le TLS précoce. Les points faibles sont maintenant généralement les terminaisons — une AC compromised, une clé privée volée, ou un utilisateur cliquant sur un avertissement de certificat qu'il n'aurait pas dû.

Si vous voulez aller plus loin, les segments de networking et de cryptographie de Korra Studio couvrent les mathématiques Diffie-Hellman sous-jacentes et l'analyse du protocole au niveau des paquets en plus de profondeur.