TLS en pratique : ce qui se passe derrière le cadenas

Ce que ce cours permet enfin d’expliquer complètement

Le cours sur HTTP annonçait trois garanties apportées par HTTPS (confidentialité, intégrité, authentification du serveur), sans détailler comment elles sont obtenues. Avec le hachage, le salage et les deux familles de chiffrement vus dans ce cours, la mécanique complète devient lisible.

Les grandes étapes d’une négociation TLS

text

1. Le navigateur contacte le serveur et propose les algorithmes qu'il supporte
2. Le serveur repond et presente son certificat (sa cle publique, signee)
3. Le navigateur verifie la signature du certificat aupres d'une autorite de confiance
4. Navigateur et serveur derivent ensemble une cle symetrique de session,
 via un echange qui s'appuie sur la cryptographie asymetrique
5. Toute la suite de la conversation est chiffree avec cette cle symetrique,
 avec des controles d'integrite bases sur du hachage a chaque message

Le certificat : une clé publique, plus une signature de confiance

Un certificat contient la clé publique du serveur, mais aussi une signature produite par une autorité de certification (CA) reconnue par le navigateur. Cette signature répond précisément à la question posée au chapitre 5 : comment savoir que la clé publique reçue appartient vraiment au bon serveur, et pas à un attaquant qui s’interpose ?

Info

Sans cette vérification, un attaquant positionné entre le navigateur et le serveur (sur un réseau Wi-Fi public non fiable, par exemple) pourrait présenter sa propre clé publique en se faisant passer pour le vrai site. La chaîne de confiance construite par les autorités de certification est ce qui rend cette usurpation détectable.

L’approche hybride, en pratique

L’étape 4 ci-dessus est exactement l’approche hybride du chapitre précédent : l’asymétrique intervient une seule fois, pour établir une clé partagée en sécurité, sans jamais faire circuler cette clé en clair sur le réseau. Une fois cette clé de session obtenue, tout bascule sur du chiffrement symétrique, largement plus rapide, pour le reste des échanges.

Ce que TLS ne fait toujours pas

Comme le rappelait le dernier chapitre du cours sur HTTP : TLS sécurise ce trajet précis, du navigateur jusqu’au serveur. Il ne dit rien de ce que le serveur fait ensuite du contenu qu’il reçoit : une application vulnérable aux injections SQL ou aux XSS le reste très exactement autant derrière ce mécanisme, aussi robuste soit-il.