Signatures numériques, certificats et TLS

La leçon précédente a laissé une question ouverte : le chiffrement asymétrique permet d’envoyer un secret à quelqu’un dont vous avez la clé publique — mais comment savez-vous que cette clé publique lui appartient réellement, et non à un attaquant intercalé entre vous deux ? Les signatures numériques et les certificats répondent à cela, et ensemble ils rendent possible TLS, le protocole derrière chaque adresse https://.

Les signatures numériques : preuve d’origine, pas de secret

Une signature numérique fait fonctionner le chiffrement asymétrique à l’envers. Au lieu de chiffrer un message avec la clé publique de quelqu’un pour que lui seul puisse le lire, l’expéditeur signe un message avec sa propre clé privée, et n’importe qui peut le vérifier à l’aide de la clé publique de l’expéditeur. Si la vérification réussit, deux choses sont vraies : le message provient bien de celui qui détient cette clé privée, et il n’a pas été modifié par la suite — la même propriété de résistance aux collisions issue de la discussion sur le hachage de la leçon précédente est ce qui rend une altération détectable. Une signature prouve l’authenticité et l’intégrité ; elle ne garde pas, en soi, le message secret.

Les certificats : une signature garantissant une clé publique

Un certificat numérique résout le problème « à qui appartient réellement cette clé publique ». Comme l’explique le centre d’apprentissage de Cloudflare, un certificat SSL/TLS est « un fichier de données hébergé sur le serveur d’origine d’un site web » contenant le nom de domaine, la clé publique, une date d’expiration, et — élément essentiel — « la signature numérique de l’autorité de certification ». Une autorité de certification (CA) est un tiers de confiance qui vérifie qu’un site web contrôle bien le domaine pour lequel il demande un certificat, puis signe ce certificat avec sa propre clé privée. Votre navigateur est livré avec une liste intégrée de CA en qui il a confiance, donc quand il reçoit un certificat signé par l’une d’elles, il peut faire confiance à la clé publique qu’il contient sans jamais avoir rencontré l’exploitant du site web. Un certificat auto-signé — qu’un site signe lui-même plutôt que de l’obtenir d’une CA — n’a aucune garantie externe de ce type, ce qui explique pourquoi les navigateurs le considèrent par défaut comme non fiable.

TLS : mettre les deux au travail

La RFC 8446, la spécification de TLS 1.3, décrit une négociation en phases : l’échange de clés, où les deux côtés établissent un secret partagé ; puis l’authentification, où, selon les mots de la RFC, « le côté serveur du canal est toujours authentifié ; le côté client est authentifié de façon facultative » — normalement, seul le site web prouve son identité, pas le visiteur. Le serveur prouve qui il est à l’aide de son certificat et d’une signature que lui seul pouvait produire avec sa clé privée. Une fois que les deux côtés font confiance à la connexion, ils dérivent des clés symétriques rapides (l’AES de la leçon précédente, typiquement) pour les données réelles. La RFC 8446 énonce clairement ce que cela vous apporte : confidentialité et intégrité pour les données échangées, et authentification du serveur. Elle énonce tout aussi clairement une limite : « TLS ne cache pas la longueur des données qu’il transmet », et des métadonnées comme le serveur auquel vous vous êtes connecté et à quel moment restent visibles pour quiconque est positionné pour observer la connexion.

Ce que signifie, et ne signifie pas, l’icône de cadenas

Un site d’hameçonnage construit sur un domaine imitateur peut avoir un certificat parfaitement valide : TLS authentifie le domaine, pas l’intention de celui qui l’a enregistré. C’est pourquoi la leçon précédente sur le déroulement des attaques traite une fausse page de connexion, cadenas compris, comme une menace bien réelle, et non comme une contradiction.