cours1 min de lecture

HTTPS — l'échange de clé symétrique

Comment HTTPS combine chiffrement asymétrique et symétrique — l'asymétrique pour échanger une clé, le symétrique pour la suite de la communication. Le handshake en version simplifiée, sans entrer dans SSL/TLS.

programme

Introduction

Vous avez vu le chiffrement symétrique (rapide, mais clé partagée à échanger) et le chiffrement asymétrique (échange sans contact préalable, mais lent). En pratique, le Web sécurise ses communications en combinant les deux : c'est exactement ce que demande . L'image qui aide à fixer le mécanisme est celle de la valise diplomatique : on commence par échanger une clé sous la protection d'un dispositif coûteux (l'asymétrique), puis cette clé sert à ouvrir et fermer une simple valise pour tout le reste de la correspondance (le symétrique). Le protocole qui orchestre cette combinaison s'appelle HTTPS — HTTP over TLS. Quand vous voyez le cadenas dans la barre du navigateur, c'est HTTPS qui est à l'œuvre. Ce cours décrit le mécanisme central — l'échange de clé — sans entrer dans les détails de la négociation TLS, que le programme officiel exclut explicitement (« la négociation SSL n'est pas abordée »).

Pourquoi combiner les deux ?

Récapitulons ce que vous savez :

Chiffrement	Avantage	Inconvénient
Symétrique	Très rapide, peu coûteux	Nécessite une clé partagée au préalable
Asymétrique	Pas de partage préalable	Lent, inadapté aux longs messages

L'idée d'HTTPS est de prendre le meilleur des deux :

L'asymétrique sert uniquement au démarrage, pour transmettre une clé symétrique fraîche.
Le symétrique prend ensuite le relais pour toute la conversation.

L'asymétrique n'intervient donc que sur quelques centaines d'octets — la clé de session. Le coût en performance est négligeable. Ensuite, AES (ou équivalent) chiffre les pages, les images, les requêtes — c'est rapide.

Le handshake HTTPS — version simplifiée

Quand votre navigateur ouvre une connexion vers https://nsi.rocks, il se passe (en gros, en ignorant les détails TLS) ceci :

Le client ouvre la connexion vers le serveur sur le port 443.
Le serveur envoie son certificat, qui contient sa clé publique $K_{pub-serveur}$ . Le certificat est signé par une autorité reconnue, ce qui permet au navigateur de vérifier qu'il parle bien au bon serveur.
Le client génère une clé symétrique aléatoire $k$ (par exemple 256 bits pour AES-256).
Le client chiffre $k$ avec la clé publique du serveur : $C_k = E_{K_{pub-serveur}}(k)$ et envoie $C_k$ au serveur.
Le serveur déchiffre $C_k$ avec sa clé privée : $k = D_{K_{priv-serveur}}(C_k)$ Client et serveur partagent maintenant $k$ , sans qu'elle ait jamais transité en clair.
À partir d'ici, toute la communication est chiffrée symétriquement avec $k$ , via AES par exemple.

Handshake HTTPS simplifié

Aucune partie sensible ne circule en clair. La clé publique est publique par construction ; le chiffré

C_k

ne révèle pas

k

sans la clé privée du serveur ; les messages suivants sont chiffrés avec

k

. Un espion sur la ligne ne voit que des octets aléatoires.

Pendant le handshake HTTPS, qu'est-ce qui circule chiffré par la clé publique du serveur ?

Pourquoi c'est sûr

Trois propriétés s'enchaînent :

L'attaquant ne connaît pas $K_{priv-serveur}$ . Seul le serveur la possède. Il ne peut donc pas déchiffrer $C_k$ , donc il n'apprend pas $k$ .
Sans $k$ , il ne peut pas lire les messages chiffrés par AES qui suivent.
Le certificat signé par une autorité reconnue atteste qu'on parle bien au bon serveur, pas à un imposteur qui aurait intercepté la connexion.

Si l'une de ces propriétés tombe — par exemple si $K_{priv-serveur}$ fuite — toutes les communications passées et futures avec ce serveur sont compromises. C'est pourquoi les serveurs sérieux régénèrent leurs clés périodiquement (et utilisent en réalité des mécanismes plus sophistiqués, comme la forward secrecy, qui dépasse le programme).

Ce qu'il faut savoir au-delà du schéma

Le programme officiel précise : « La négociation de la méthode de chiffrement du protocole SSL n'est pas abordée. » Cela signifie que vous n'avez pas à connaître :

les versions de TLS (1.2, 1.3) et leurs différences ;
les cipher suites précises négociées ;
les phases internes ServerHello/ClientKeyExchange/Finished.

Vous devez savoir :

qu'HTTPS combine asymétrique et symétrique ;
que l'asymétrique sert à transmettre la clé symétrique ;
que la suite de la communication est symétrique ;
qu'un certificat sert à authentifier le serveur.

Une fois le handshake terminé, la page HTML que le serveur envoie au navigateur est chiffrée…

Récapitulatif visuel

Étape	Côté	Action	Clé utilisée
1	Client	Ouvre la connexion	—
2	Serveur	Envoie son certificat (avec $K_{pub}$ )	—
3	Client	Génère $k$ aléatoire	—
4	Client	Envoie $E_{K_{pub}}(k)$	$K_{pub-serveur}$
5	Serveur	Déchiffre et obtient $k$	$K_{priv-serveur}$
6	Les deux	Communication chiffrée	$k$ (symétrique)

Pour aller plus loin

Le mécanisme décrit ici est l'idée centrale. En pratique, TLS 1.3 a remplacé l'envoi direct de $k$ chiffré par RSA par un échange Diffie-Hellman qui assure la forward secrecy : même si la clé privée du serveur fuite plus tard, les communications passées restent indéchiffrables. Le principe « asymétrique pour fonder un secret commun court, symétrique pour le gros du trafic » reste strictement le même.