HTTPS : combiner chiffrement symétrique et asymétrique

Un cap pour ce chapitre

Ce que vous saurez faire

Expliquer le rôle d’une clé de session.
Reconstituer le modèle d’échange demandé en NSI.
Distinguer le modèle pédagogique des protocoles TLS actuels.

Les bases utiles pour commencer

HTTP protégé par un canal sécurisé

HTTP définit des échanges de requêtes et de réponses entre un client et un serveur. HTTPS correspond à HTTP utilisé sur une connexion protégée par TLS. Le navigateur continue de demander des ressources, mais le canal vise notamment la confidentialité et l’intégrité des données, ainsi que l’authentification du serveur dans le cadre prévu.

Voir HTTPS ne garantit pas que le contenu du site soit vrai ni que son propriétaire soit honnête. Le mécanisme protège une communication avec une identité de service vérifiée selon le système de certificats. Il ne remplace ni l’esprit critique, ni la vérification du nom de domaine visité.

Pourquoi combiner deux familles de mécanismes ?

Le chiffrement symétrique convient au traitement efficace de nombreux messages, mais nécessite un secret partagé. Les mécanismes asymétriques apportent des moyens d’établir une relation sécurisée sans secret commun préalable. Les combiner permet de traiter séparément l’établissement du secret et la protection des données échangées ensuite.

Une clé de session est un secret utilisé pour une connexion ou une période déterminée selon le protocole. Elle n’est pas la clé privée durable du serveur. Nommer ces clés différemment aide à éviter une erreur courante : imaginer que le serveur envoie sa clé privée au navigateur pour lui permettre de communiquer.

Le modèle pédagogique d’échange d’une clé

Le modèle demandé dans le programme peut être décrit ainsi : le client obtient et authentifie la clé publique du serveur ; il choisit un secret symétrique K ; il protège K à l’aide de la clé publique du serveur ; le serveur utilise sa clé privée pour retrouver K. Client et serveur peuvent ensuite utiliser ce secret dans un mécanisme symétrique approprié.

Un observateur ne doit pas recevoir K en clair. Il peut voir la clé publique et le message qui transporte K sous forme protégée. Le serveur garde sa clé privée. Cette description met en évidence la complémentarité des rôles, avec une présentation simplifiée des étapes d’authentification et de protection.

Dans ce schéma, K désigne la donnée à transmettre lors de l’étape asymétrique, puis une clé utilisée lors des échanges suivants. Changer son rôle selon l’étape ne change pas son propriétaire autorisé. Étiquetez les flèches « clé publique », « K protégé » et « données protégées avec K » pour éviter de dessiner trois transmissions équivalentes.

Ne pas transformer le modèle en description universelle

Les connexions TLS modernes n’établissent pas toutes leurs clés en chiffrant directement une clé de session avec une clé publique. TLS 1.3 utilise notamment des mécanismes d’accord de clés et ne propose plus l’ancien transport de clé RSA. Il faut donc annoncer clairement que le schéma précédent est un modèle pédagogique de chiffrement hybride, pas une trace exhaustive d’une connexion actuelle.

Au niveau NSI, on attend la compréhension de la clé partagée, des paires publique-privée et de leur articulation. Les détails de négociation TLS ne sont pas à apprendre ici. La spécification de TLS 1.3 explique notamment la suppression du transport de clé RSA. Pour rédiger une réponse, identifiez chaque acteur, indiquez quelle information circule et précisez avec quelle clé elle est protégée.

Exemple suivi : suivre qui connaît chaque information

Avant l’établissement, le serveur possède une paire publique-privée. Le client obtient la clé publique et vérifie son association à l’identité attendue. Après choix de K, le client est seul à connaître ce nouveau secret dans le modèle. Il envoie une représentation protégée avec la clé publique du serveur. Après ouverture avec sa clé privée, le serveur connaît également K ; l’observateur voit le message transmis mais ne reçoit pas le secret en clair.

On peut représenter cette évolution par trois lignes de tableau : clé publique connue du client, du serveur et possiblement de l’observateur ; clé privée connue du serveur ; K connu d’abord du client puis des deux correspondants. Un message applicatif ultérieur utilise le mécanisme symétrique. Le serveur n’a jamais eu besoin de donner sa clé privée au client. Vérifiez chaque dessin en posant la question : de quelle information cet acteur dispose-t-il exactement à cette étape ?

À la fin de l’établissement décrit, les connaissances se résument ainsi dans les hypothèses du modèle :

Information	Client	Serveur	Observateur
Clé publique du serveur	Connaît	Connaît	Peut connaître
Clé privée du serveur	Ne connaît pas	Connaît	Ne connaît pas
Secret de session K	Connaît	Connaît	Ne connaît pas

Exemple suivi : diagnostiquer un schéma presque correct

Un schéma indique « réception d’une clé publique », puis « chiffrement de K », puis seulement « vérification de l’identité ». Le décalage paraît minime mais la vérification arrive trop tard : K a déjà pu être protégé pour une clé substituée par un adversaire. Dans le modèle, il faut utiliser une clé dont l’association à l’identité attendue a été vérifiée avant de lui confier le secret. Le fait que la clé soit publique concerne sa diffusion ; il ne valide pas son origine.

Autre défaut possible : toutes les étapes d’établissement sont correctes, mais une application publie ensuite K dans un journal accessible. Le canal ne peut protéger un secret révélé par l’application elle-même. À l’inverse, un site peut transmettre une fausse information dans un canal correctement protégé. Pour répondre précisément, distinguez l’identité du service, l’intégrité du transport, la confidentialité du contenu et la véracité de l’affirmation reçue. Une même observation ne tranche pas ces quatre questions.

À vous de faire varier les choses

Reconstituez le modèle de chiffrement hybride

Reconstituez ce scénario précis de chiffrement hybride. Après chaque choix, indiquez qui connaît K. Identifiez ensuite l’étape qui empêcherait une substitution de clé et celle qui ferait échouer le protocole si K était envoyé en clair.

Lire le déroulement expliqué

Le client obtient une clé publique attribuée au serveur.
Il faut disposer de la clé avant de la vérifier. Le navigateur a reçu une donnée publique, pas un secret partagé.
Le client vérifie que la clé publique reçue appartient bien au service et au domaine attendus.
Une clé substituée compromettrait le destinataire de K. Cette vérification doit précéder le chiffrement du secret pour la clé reçue.
Le client choisit une clé symétrique de session K.
K doit exister avant sa protection dans ce scénario. À ce moment du scénario, seul le client connaît K.
Le client protège K avec la clé publique vérifiée du serveur.
K ne circule pas en clair. L’observateur voit la représentation protégée ; il ne reçoit pas K en clair.
Le serveur retrouve K avec sa clé privée.
Le serveur possède la clé privée correspondante. Après cette opération, client et serveur connaissent K, mais la clé privée reste sur le serveur.
Les correspondants protègent les données avec un mécanisme symétrique utilisant leur secret partagé.
Les deux acteurs disposent maintenant du secret nécessaire. Un nouveau secret est utilisé pour la session ; la véracité du contenu applicatif reste une autre question.

Indice 2

Le cours annonce explicitement un modèle pédagogique.

Comprendre la correction

Dans le premier cas, la communication peut être protégée alors que l’article demande une vérification documentaire indépendante. Dans le second, il faut résoudre la discordance d’identité avant de transmettre un secret au service. Le modèle hybride explique la complémentarité des clés, tandis que TLS moderne peut utiliser un accord de clés ; les étapes exactes ne se déduisent pas de cette seule analogie.

Les erreurs qui méritent un détour

Présenter le transport RSA d’une clé comme tous les échanges TLS modernes.: Annoncez le modèle et ses limites ; TLS 1.3 utilise d’autres mécanismes d’établissement des clés.
Confondre clé de session et clé privée du serveur.: La première est partagée pour la communication ; la seconde demeure chez son propriétaire.

La fiche à garder

L’essentiel à retenir

HTTPS protège les échanges HTTP à travers TLS.
L’établissement des secrets et la protection des données ont des rôles distincts.
Un modèle pédagogique doit être identifié comme tel.

Cette notion au bac

Retrouvez ces idées dans un sujet complet, avec des indices, une correction expliquée et des ateliers.

Le prochain pas

Comment résoudre un exercice de NSI

Retrouver le catalogue de Terminale

Ce chapitre s’appuie sur le programme officiel de Terminale (PDF, nouvel onglet). Les explications et exercices sont proposés pour l’apprentissage.