Les certificats X.509
Pour comprendre les certificats il faut comprendre comment fonctionnent les mécanismes de chiffrages a clé asymétriques. J'en parles un peu ici mais Wikipédia est notre ami.
Le problème du chiffrement asymétrique
Me mécanisme a clé asymétrique est parfait. On peut échanger des messages de façon sûre sans échanger de secret partagés. Ce mécanisme est utilisé en TLS (autrefois appelé SSL mais on devrait toujours dire TLS).
Un problème peut se poser, c'est celui de la distribution des clés publiques. SI un "méchant" attaque le serveur dépôt de ce clés, change la clé publique d'Alice par une autre. Il pourrait faire croire à Bob qu'un message viens d'Alice alors qu'il vient de lui.
Voyons ce qu'il se passe pour une connexion ssh authentifié par clé asymétrique:
La première action est, pour le client, de donner sa clé au gestionnaire du serveur. Celui-ci la mets dans la liste des clés autorisées (fichier .ssh/authorized_keys).
Maintenant, si le client cherche à se connecter au serveur.
- Il se connecte en donnant sa clé.
- Le serveur vérifie si il a cette clé et l'utilise pour lui poser une question "le challenge" chiffré avec la clé publique reçue.
- Le client lit le challenge (déchiffre avec sa clé privée) et donne sa réponse
- Le serveur vérifie que cette réponse ait été gérérée avec la clé privée correspondant a la clé publique reçue.
- Si OK le client est bien celui qui à présenté sa clé publique (il possède la clé privée)
- Le serveur génère une clé temporaire symétrique et l'envoie au client chiffré avec la clé publique de ce dernier.
- On dispose maintenant d'un secret partagé qui nous servira aux échanges tant que la session restera ouverte
Tout cela fonctionne très bien mais :
- Comment transmettre de façon sécurisé la clé publique d'Alice pour que l'admin du serveur l'installe. (comment Alice peut elle savoir a qui elle l'envoie?)
- Comment l'admin est il certain que la clé provienne bien d'Alice?
Ce problème est transposable a beaucoup d'autres. Un serveur https par exemple chiffre les échanges avec un tel mécanisme.
Il utilise sa clé publique pour s'authentifier auprès du client mais comment le client peut-il savoir si cette clé publique est bien celle du serveur?
C'est là qu'intervient le mécanisme de certification.
Le tiers de confiance
Entre Alice et le serveur il va y avoir un troisième intervenant, le tiers de confiance.
Pour simplifier Alice désire se connecter à sa banque. Elle utilise l'URL de sa banque https://labanqueaalice.com.
La banque ne lui envoie pas seulement sa clé publique mais :
- Sa clé publique
- Ses métadonnées (avec en particulier)
- Son "Common Name" ou CN qui, dans le cas d'un serveur est son nom DNS (ici labanqueaalice.com)
- Sa période de validité (from--to)
- Le nom du propriétaire, son pays, son adresse...
- Le nom de l'organisme de confiance
- La signature de sa clé + metadonnées réalisée avec la clé privée de l'organisme de confiance.
Dans la pratique un navigateur, si on lui demande de se connecter à https://labanqueaalice.com:
- Il demande au serveur qui réponds sur cette URL son certificat
- Il regarde, dans ce certificat qui est le tiers de confiance
- Il vérifie que ce tiers soit bien dans sa liste de tiers à lui
- Si il a ce tiers de confiance dans sa liste il a aussi sa clé publique
- Il vérifie la signature du certificat en utilisant la clé publique du tiers qu'il a déja.
- Il vérifie que le CN soit bien celui qu'il a demandé labanqueaalice.com
- Il vérifie les dates de validités
- Il vérifie plein d'autres choses comme la version des algorithmes utilisés pour être sur qu'il n'y ai pas de vulnérabilités.
- Il se connecte.
Ensuite le serveur doit authentifier le client mais c'est une autre affaire. Il peut demander un simple user/password ou utiliser le même mécanisme avec un certificat X.509 mais côté client. (C'est le client qui fait certifier sa clé publique et ses métadonnées au certificateur).