Quelles sont les alternatives au système d'autorité de certification existant pour SSL?
Bien que le système CA actuel fonctionne très bien pour beaucoup de gens, il met beaucoup de pouvoir entre les mains des CA individuelles et rend un piratage CA potentiellement dévastateur pour les clients et les entreprises. Quelles sont les alternatives aux autorités de certification et quels sont les défis liés au passage à de tels systèmes? J'ai vu des propositions pour une variété de systèmes P2P distribués, mais rien n'est jamais venu d'eux.
Les "alternatives" varient selon que vous voulez quelque chose qui pourrait fonctionner à l'avenir, ou quelque chose qui fonctionne maintenant, avec les navigateurs existants.
À l'heure actuelle , les navigateurs Web s'attendent à ce que les serveurs envoient certificats X.509 , puis ils les valident par rapport à l'ensemble de l'autorité de certification racine intégré dans le navigateur (ou le système d'exploitation). Cela signifie que si vous voulez quelque chose qui fonctionne sans aucune installation de logiciel supplémentaire, tout ce que vous pouvez faire est de modifier l'ensemble de l'autorité de certification racine (vos faites confiance aux ancres). Vous pouvez:
- Supprimez une partie de l'AC ( il a été dit que vous pouvez supprimer la plupart d'entre elles sans vraiment affecter votre expérience de navigation, car toutes les AC de confiance ne sont pas également actives).
- Ajoutez de nouvelles ancres d'approbation. Notez qu'un trust anchor est "un nom et une clé publique auxquels vous faites confiance a priori". Les ancres de confiance sont généralement encodées en certificats (car le format est pratique pour cela), et traditionnellement sont auto-signées (principalement parce que dans un certificat, il y a un champ pour une "signature" qui ne peut pas être laissée vide). Mais vous pouvez faire confiance aux certificats qui ne sont pas auto-signés; vous pouvez même faire confiance aux certificats d'entité finale (c'est-à-dire que vous faites confiance au certificat spécifique d'un serveur SSL donné: cela s'appelle confiance directe). Avec la confiance directe, vous gérez manuellement ce que vous faites confiance avec une granularité très fine. Notez qu'avec la confiance directe, vous perdez les avantages de la révocation (un certificat directement fiable ne peut être douteux que par une intervention manuelle de votre part, tandis que la révocation concerne la propagation automatique des informations de méfiance).
(On peut noter que le modèle de confiance directe est exactement ce que SSH suit, et il fonctionne bien dans le contexte d'utilisation de SSH.)
À l'avenir , il pourrait y avoir d'autres modèles. Il existe plusieurs propositions, certaines étant soutenues par des modules complémentaires logiciels existants. À ma connaissance, aucun n'a encore atteint le niveau "généralement utilisable". Il y a par exemple:
DNSSEC et DANE : DNSSEC consiste à mapper un PKI sur le système DNS, principalement pour authentifier les données retournées par le DNS lui-même, mais cela peut être un levier pour distribuer les clés de serveur SSL (de quoi parle DANE). Il s'agit toujours d'une PKI hiérarchique, avec un ensemble limité d'ancres de confiance; la différence avec l'ensemble existant de l'autorité de certification racine est principalement un changement de joueurs: le nouvel ensemble de contrôleurs d'accès serait plus petit et ne chevaucherait que partiellement l'autorité de certification racine existante. De plus, DNSSEC/DANE lie le processus d'authentification des serveurs Web à l'infrastructure et aux acteurs DNS, et il n'est pas clair si cela est bon ou mauvais.
A Web of Trust comme OpenPGP. Le modèle WoT repose sur la superconnectivité des graphes. Pour simplifier les choses, avec un WoT, tout le monde est une autorité de certification, et chaque acteur est sa propre et unique autorité de certification racine; pour faire face à une "CA" crédule ou carrément malveillante, les utilisateurs de WoT (c'est-à-dire les navigateurs Web) n'acceptent un certificat cible comme valide que s'ils peuvent le vérifier via de nombreux chemins qui passent par une autorité de certification distincte et tous sont d'accord pour poser la clé de serveur cible. La nature décentralisée de WoT est très populaire parmi les personnes qui se méfient des gouvernements et de tout ce qui ressemble à une administration. Cependant, la sécurité de WoT dépend beaucoup de masse critique: elle ne vous apportera pas grand-chose tant que suffisamment de personnes ne collaboreront pas. Voir le projet Monkeysphere pour une implémentation (avec des modules complémentaires de navigateur) (cependant, je ne connais pas grand-chose à la qualité du projet).
Convergence est un descendant du projet Perspectives . Si vous vous y attelez, la convergence repose sur Espoir et paresse . Ce que Convergence suppose, c'est que les attaquants en herbe trouveront trop difficile/cher/ennuyeux de se faire passer pour un serveur donné avec un faux certificat pendant longtemps et aux yeux de nombreuses personnes. A savoir, pratiques attaques Man-in-the-Middle sont soit proches de la victime (par exemple les utilisateurs d'un hotspot WiFi donné), auquel cas elles n'affectent que très peu de personnes, soit proches du serveur, ce qui nécessite quelque chose à grande échelle (comme un empoisonnement DNS lourd) qui sera assez visible, donc ne durera pas longtemps. Dans ce modèle, la convergence est une solution de Nice, relativement peu coûteuse, avec seulement une centralisation minimale (elle nécessite toujours des notaires, et de facto la centralisation peut être attendue, mais pas aussi approfondie que l'ensemble actuel de racine CALIFORNIE).
Un point important est que le système actuel "fonctionne". Les attaques réelles qui ciblent l'ICP sont très rares (très médiatisées, mais toujours rares). Le système réel avec l'AC racine est suffisamment difficile à briser pour que les attaquants trouvent plus facile de le contourner par d'autres moyens (le premier étant d'abuser de la crédulité des utilisateurs humains). En tant que tel, il n'y a guère d'incitation à le remplacer par un autre système qui, au mieux, fera de même. Ainsi, bien que les propositions alternatives aient un certain mérite (principalement en termes financiers et politiques), je considère qu'il est relativement improbable que l'une d'entre elles déloge l'AC racine existante dans un avenir proche, pour "le Web" tel que nous le connaissons.
Pour les architectures fermées qui ne sont pas le Web, et où vous contrôlez à la fois le client et le serveur, vous pouvez utiliser le système que vous voulez, mais l'architecture fermée est précisément la situation où l'ICP hiérarchique fonctionne très bien.
Une alternative est DANE/TLSA , qui est une norme RFC qui autorise les clés auto-signées dans DNS.
L'un des défis est que c'est très nouveau et que la plupart des logiciels clients ne le prennent pas encore en charge. (Chrome étant un nouvel ajout) De plus, DNS est soumis à diverses attaques, en particulier sur les réseaux WiFi et similaires.
Une façon de remédier à l'attaque DNS consiste à utiliser DNSSec et à garantir que le logiciel client n'utilisera DNSSec que pour les domaines qui le proposent. Si cette dernière fonctionnalité n'existe pas, cela ouvrirait les utilisateurs à une vulnérabilité de type bande SSL.
SSL prend également en charge Secure Remote Password (SRP) . C'est là que vous vous authentifiez à l'aide d'un mot de passe au lieu d'un certificat. Dommage que les navigateurs ne le prennent pas en charge.
Il y a aussi Convergence qui est une baisse de remplacement pour le système CA/PKI. En théorie, vous pouvez utiliser un certificat auto-signé et toujours vous défendre contre les attaques MITM. Il fournit également une protection contre les AC malveillants.
Il convient de souligner que le concept de chaîne de confiance n'est pas lui-même plus ou moins vulnérable que le Web de confiance, le secret partagé ou tout autre mécanisme s'il est mis en œuvre à la même échelle que notre infrastructure à clé publique actuelle.
Le principal problème est la prolifération des autorités de certification de confiance ainsi que le manque de différenciation entre les autorités de certification à des fins de confiance. Pour les cas d'utilisation spécifiques à l'application (c'est-à-dire pas le navigateur Web ), vous pouvez contourner cela et créer une PKI privée très solide et très fiable. Étant donné que les implémentations SSL/TLS vous permettent de spécifier vos propres racines de confiance, il n'y a aucune raison pour que vous deviez inclure les listes de CA populaires fournies par Mozilla et Microsoft. En fait, si vous n'utilisez pas de navigateur , alors il y a peu de raisons pour lesquelles vous devez inclure la liste globale des autorités de certification et de nombreuses raisons pour lesquelles vous ne devriez pas . Si vous êtes la seule autorité de certification, votre surface d'attaque est considérablement limitée (comme Microsoft l'a récemment appris).
En ce qui concerne l'ICP du navigateur, une solution plus idéale serait de créer des TLD segmentés par catégorie de confiance (par exemple *.bank pour les institutions financières, etc.) et surtout limiter l'autorité de l'autorité de certification à un seul TLD. De cette façon, le bureau de poste de Hong Kong ne peut plus signer pour Paypal ou Google.
Mais comme la technologie actuelle est effectivement figée par une utilisation populaire, la probabilité que cette infrastructure de sécurité alternative ou toute autre se généralise est effectivement zéro.