Constat
le modèle de certification SSL s’appuie sur un système de confiance désuet et peu fiable : à l’inverse de la conception même du Net, décentralisé, il se base sur des « autorités » ayant le pouvoir de certifier l’identité d’un site web (ou d’un quelconque service). Mais ces autorités ne peuvent pas garantir leur fiabilité, leur honnêteté : leur opacité est contre-nature vis-à-vis d’Internet. Pire, ils représentent des points de faiblesse, et des attaques ciblées contre eux peuvent causer d’énormes dommages.
Modèles de confiance
Il existe globalement deux modèles de confiance sur Internet : le premier, pair-à-pair, est utilisé notamment par GPG, et permet de déterminer une confiance non binaire : en faisant confiance à 60% à une personne qui fait confiance à 80% à un individu, ma confiance envers lui n’est que de 48% au maximum. Ce qui me poussera naturellement à me méfier, en gardant en tête qu’il est possible que l’individu ne soit pas celui auquel je m’attend. Il nécessite cependant, comme tout fonctionnement pair-à-pair, une implication des utilisateurs pour se certifier les uns les autres.
Le second est binaire et centralisé. Une autorité se charge de certifier l’identité de quelqu’un (ou d’un site web), souvent en échange d’espèces sonnantes et trébuchantes, et invitera les internautes à lui faire pleinement confiance pour certifier les identités. Ça a l’avantage d’être quasiment transparent pour l’utilisateur, qui utilisera des logiciels intégrant par défaut une liste d’autorités de certification. Mais il y a également de gros inconvénients :
- Comme indiqué plus haut, la confiance est binaire. Il est logique que l’autorité ne délivre un certificat que lorsqu’elle est certaine à 100% de l’identité du demandeur, mais il est impossible d’attribuer une confiance relative à cette autorité. Par exemple, il se peut que l’autorité ne soit pas parfaitement transparente sur ses méthodes de vérification, ou simplement qu’elles ne soient pas parfaitement sûres. Ou même que, par un habile jeu de rachats ou de sous-traitance, l’autorité en laquelle on a placé notre confiance ne soit plus du tout la même, et revende cette même confiance.
- De plus, la certification est unique. On nous impose d’avoir une confiance totale dans tous les certificats d’une autorité, et à l’inverse, un certificat ne peut être certifié que par une seule autorité. C’est un principe qui va à l’encontre de la structure du Net, qui se veut décentralisé et redondant. Dans ce système, les CA sont des points de faiblesse à tous les niveaux : une CA peut être compromise, mettant alors dans une mauvaise situation tous ses certificats, ou tout simplement faire une erreur, mal vérifier un site…
What do ?
Ainsi, je souhaiterais entamer une profonde réflexion dans le but de passer dans un modèle de confiance plus fiable au sein de SSL. Voici comment cela pourrait, selon moi, fonctionner :
- Monsieur X, Le propriétaire du site A génère son certificat et le signe personnellement, avec une confiance absolue (on passera sur les éventuels problèmes psychologiques de confiance en soi).
- L’utilisateur I connaît monsieur X, et sait qu’il est bien l’auteur du site A. Il lui accorde donc une confiance acceptable (disons 70%, il n’est pas forcément technicien ou notaire et n’a pas validé scrupuleusement la procédure).
- L’utilisateur J, lui, est un barbu paranoïaque, et, connaissant un peu monsieur X, il tient à le rencontrer pour lui demander de valider oralement l’empreinte de la clé (comme cela se fait pour GPG). Il signe alors le certificat, en indiquant une confiance très forte (95%).
L’utilisateur K veut alors visiter le site A de façon sécurisée. Il ne connaît pas monsieur X, mais se trouve être un voisin de J, dont il connaît les compétences, et sait qu’il sait ce qu’il fait. Il a donc confiance à 80% dans ce que lui dit J, qui lui-même a confiance à 95% dans le certificat. Son score de confiance dans le certificat est donc, par transfert, de 80% × 95% = 76. Mettons que, par défaut, les certificats avec un score supérieur à 50 sont acceptés, le site apparaît comme sûr.
- L’utilisatrice L, par contre, connaît I (elle lui fait confiance à 50%), mais également K, en qui elle a très peu confiance (30%). Si elle souhaite visiter le site A, elle a une confiance de 35% par le biais de I, et de 23% par le biais de K. Elle dispose donc de deux chaînes, toutes deux insuffisantes pour accorder sa confiance, mais son score personnel résulte de la somme des différentes chaînes : en l’occurrence, les 2 chaînes parviennent à un score correct de 58, qui est donc supérieur à 50, et donc valide.
- Pimentons un peu les choses. L’utilisateur Ganon (nommé ainsi car il est méchant) souhaite usurper l’identité du site A (pour détourner des comptes, par exemple). Il crée proprement sa copie du site (appelée A′) en prenant soin d’y ajouter un nombre suffisant d’erreurs et de fautes d’orthographe pour qu’il ne soit pas crédible (c’est une règle dans ce milieu). Il signe ensuite un certificat prouvant que son faux site est bien le site A. À partir de là, les visiteurs du site A ou même A′ seront avertis que plusieurs certificats contraires existent pour ce nom, et que par conséquent au moins l’un d’eux ment. Les visiteurs seront alors invités à la plus grande prudence. Pour déterminer quel certificat est le vrai, il faudra alors comparer les chaînes de validation de chaque certificat, et comparer les scores finaux. En se basant sur la toile de confiance, le site légitime est naturellement celui qui aura le meilleur score.
- Toujours avec la présence de Ganon, un utilisateur détecte la supercherie (appelons-le Chuck Norris). Il signe le certificat de celui-ci, mais avec une confiance de −80%, pour indiquer que le certificat se fait passer pour ce qu’il n’est pas (évidemment, le site A′ se base sur un nom de domaine légèrement différent de A, et le certificat est adapté en conséquence pour être techniquement valide, mais le principe de la confiance intègre le facteur humain, capable de repérer qu’il s’agit d’un faux). Ce score influera naturellement sur les chaînes de confiance et permettra de repérer plus facilement les fraudes.
Voilà donc le principe de fonctionnement. On aurait pu se baser sur le modèle qu’utilise GPG, mais il semble trop simpliste, et ne gère que 3 niveaux de confiance (aucun, marginal et total). Par ailleurs, il ne semble pas savoir gérer les les signatures concurrentes. Enfin, il faut garder à l’esprit que GPG est un système qui se repose bien plus sur la validation directe plutôt que sur la chaîne de confiance. Évidemment, le fonctionnement ci-dessus n’est certainement pas sans défauts, et mériterait une réflexion commune pour être réellement efficace, mais il a le mérite d’apporter quelque chose. On peut se poser plusieurs questions relatives à son fonctionnement ou son concept :
- si les certificats sont signés par les utilisateurs, qu’est-ce qui empêche les usurpations, les faux certificats ? Simplement le fait que la confiance soit répartie entre tous les utilisateurs. Au-delà de la masse critique, il est extrêmement difficile de réussir à faire passer une information fausse, car trop de gens auront validé la vraie
- Qu’est-ce qui poussera à l’adoption d’un tel système ? Tout d’abord, GPG est déjà « déployé », même si ce n’est que marginalement, ça peut être une bonne base pour déployer ce modèle à large échelle. De plus, la transition peut se faire en douceur (et le doit d’ailleurs, sans quoi il n’aura pas la moindre chance) : sans toucher au cœur d’OpenSSL ou des autres implémentations, il suffirait de signer un certificat avec une identité GPG, peu importe que ce certificat soit commercial ou pas. C’est GPG qui fera le reste pour reconstruire la chaîne de confiance
- Y a-t-il vraiment besoin de revoir ce système ? C’est une question que je ne me serais pas posé, mais on m’a parlé de ça. Si préjudice il y a à cause d’un faux certificat SSL, on peut se retourner contre l’émetteur du certificat, c’est vrai. Tout aussi vrai que sur Internet, si votre machine est compromise et qu’un attaquant injecte un certificat d’autorité de confiance, il pourra faire du MitM en toute tranquilité sans qu’il soit possible de porter plainte contre la moindre CA. Et c’est un exemple parmi tant d’autres : je propose un système mieux conçu, mais qui ne peut, par nature, pas être absolument fiable. En cela, il n’est pas différent du système de CA.
- Comment empêcher des campagnes de dénigrement visant à plomber la réputation d’un site ? Je n’ai pas vraiment de réponse, si ce n’est que tout le mal qui pourrait être fait serait d’afficher un avertissement de sécurité à la connexion des sites. Je préfère nettement ça à la possibilité qu’une CA travaille main dans la main avec une dictature et permette du MitM afin de mieux traquer les opposants politiques… Ce genre de choses ne serait simplement pas possible avec un système acentré, dans lequel on n’imposerait aucune confiance arbitraire à des tiers.
Implémentation
Il existe déjà un projet semblant répondre aux spécifications détaillées ici, Convergence. Il se présente sous la forme d’un addon Firefox en béta (et devrait donc probablement évoluer pour toucher les autres navigateurs à terme), et, à l’époque où je l’avais trouvé, je n’avais pas pu le tester car il était incompatible avec ma version de Firefox. Je viens tout juste de me rendre compte que ça avait changé, et donc je vais de ce pas tester ce projet.
Mais en dehors de ça, si on devait reprendre à zéro (ou presque), il n’y aurait pas besoin de réinventer la roue : OpenSSL fonctionne déjà très bien et sait créer des certificats, autosignés ou pas (ce qui n’a guère d’importance dans notre cas). La modification de fonctionnement se ferait essentiellement côté client : l’utilisateur disposerait d’une identité GPG et d’un trousseau de clés appartenant à ses contacts de confiance. Sur la base de cette liste de contacts, il chercherait à déterminer les différentes chaînes menant au certificat du site recherché (à la façon de BGP), en examinant la confiance « SSL » indépendamment de la confiance GPG (on peut être sûr qu’une clé appartient bien à telle personne, sans pour autant faire confiance à cette personne). C’est donc au cœur de la libssl que je prévoierais de placer ce système, idéalement
Reste à mettre les mains à la pâte, n’est-ce pas ? Je vais passer du temps à examiner le fonctionnement de Convergence, et, s’il s’avère nécessaire de partir sur d’autres bases, je m’attaquerai, avec qui veut participer, à un PoC du système. N’hésitez donc pas à apporter vos idées, votre expérience ou vos compétences.