Dans un article précédent, ce blog proposait une synthèse des problématiques récentes qui ont touché "SSL", c'est-à-dire à la fois les vulnérabilités intrinsèques mais également les problématiques spécifiques qui ont touché de manière plus générale l'écosystème de cette solution de sécurité.
En particulier, la population des autorités de certification laissent de nombreux analystes dubitatifs après les très importantes problématiques de sécurité rencontrées par Comodo ou encore Diginotar.
Rappelons en effet que lors de la présentation du certificat qui assure une partie de la sécurité de la transaction, celui-ci est contrôlé notamment via l'autorité de certification qui constitue une garantie de confiance...Si cette dernière s'avère "mal placée", alors le modèle souffre alors d'une vulnérabilité.
Conscient de tout cela, il est fort probable que les chercheurs s'activent afin de trouver des solutions. En tentant de résumer, on pourrait dire qu'il existe 2 méthodes principales pour traiter cela :
=> bouleverser le système ou le changer complètement. Cela implique de disposer d'un modèle de sécurité remplaçant adéquat et adapté.
Mais cela suppose aussi de pourvoir l'appliquer. On peut ici alors distinguer deux cas d'usages, soit le modèle est "centralisé" et ce sont les acteurs du Net concernés qui devront l'appliquer. Soit il est "décentralisé" et l'utilisateur aura tout le travail à faire...
On ne préjuge pas des modèles futurs ici et il peut exister une solution intermédiaire comme l'est SSL/TLS à mon sens : il faut que chacune des parties s'impliquent : version à jour, vulnérabilités corrigées rapidement etc etc...Des attaques comme "Firesheep" consiste ainsi à profiter d'une application laxiste (quelques pages en HTTPS - donc utilisant SSL/TLS - seulement).
=> Une autre approche consiste à apposer des "rustines" sur le système existant afin d'en corriger les vulnérabilités. Dans le cas qui nous occupe, certaines relèvent purement de questions d'organisations ou d'humains : c'est parfois bien plus compliqué !
C'est pourtant ce que propose "Convergence" : un système dont l'objectif est de garantir une plus grande souplesse, côté utilisateur, dans la gestion de la confiance accordée aux CA et à ceux qui utilisent leurs certificats.
Plus précisément, le constat opéré par son créateur, est que le système nécessiterait une propriété supplémentaire qu'il dénomme "trust agility" que l'on pourrait traduire par "confiance à degré multiples".
L'idée est assez simple : si vous n'avez plus confiance dans un CA (VeriSign ou encore Comodo), la seule solution que vous avez est alors de le supprimer de votre base de confiance....Non seulement, ce n'est pas à la portée du premier quidam venu mais c'est également se priver de tous les sites qui utilisent un certificat "garanti" par ceux-ci ...Ou alors, il faut à nouveau leur faire confiance, ce qui n'a pas de sens.
Aussi, Marlinspike propose-t-il d'introduire un nouvel intermédiaire dans les acteurs de la transaction sécurisée par SSL. Un add-on firefox est d'ailleurs déjà disponible.
Se basant sur un système distribué, l'objectif est que des "notaries" attribuent des "notes" ou des jugements de sécurité aux CA et surtout aux sites webs les utilisant notamment en entretenant un historique et en détectant des modifications suspectes. N'importe qui peut acquérir ce type de qualification même si, dans l'esprit, son créateur attend plus les sociétés de sécurité et autres passionnés, chercheurs, universités...que le quidam moyen.
Celui-ci, en revanche, pourra décider quel sont les "notaries" auxquels il fait confiance...et de là, avoir accès à des CA notés en fonction et une connaissance plus avancée de l'historique "SSL" du site web auquel l'utilisateur accède.
Ainsi, en reprenant un exemple, si vous visitez Google.fr (en HTTPS), le certificat reçu sera soumis à un ou plusieurs "notaries". Si ceux-ci révèlent une modification récente (un changement brusque de CA par exemple), l'utilisateur sera alerté.
Quelques commentaires maintenant...Commençons avec le positif :
=> ce système est ouvert, relativement distribué et laisse une grande place à l'utilisateur qui peut adapter son comportement et mettre en oeuvre ses choix...
=> il met fin à une forme de toute-puissance des CAs que les problématiques de sécurité ont déjà largement entamé en les faisant passer par les fourches caudines de personnes plus intraitables en matière de sécurité...
=> il permet également d'aller plus loin dans le contrôle et l'authentification. Des critères associés à l'historique du site permettent très certainement de distinguer plus de choses et d'être plus efficaces dans la prévention de l'attaque. On peut même imaginer un contrôle plus poussé associant un regard sur les mises à jours et les corrections de vulnérabilités ou encore l'usage de SSL/TLS sur l'intégralité des pages du site.
Le négatif est associé, comme souvent, aux qualités du système :
=> l'aspect décentralisé et ouvert laisse craindre des dérapages : j'imagine déjà des "notaries" malveillants qu'il faudra également détecter, supprimer...ce qui suppose un contrôle supplémentaire. On est alors dans le contrôle du contrôle du contrôleur !
=> Par ailleurs, il est nécessaire d'atteindre une masse critique de notaries...Considérant l'implication des acteurs de la sécurité sur Internet, c'est loin d'être impossible mais pour le moment, on compte seulement 2 notaries...
=> de manière générale, l'ajout d'une couche de sécurité présentant quelques doutes n'est pas forcément une bonne idée pour sécuriser une autre "couche"...
=> le système fait appel à l'utilisateur pour gérer des listes, ajouter un add-on firefox et être attentif à un avertissement de la machine...En ai-je dit assez ???
Convergence est donc un système qui vise à "patcher" la logique de sécurité de SSL/TLS et son écosystème. Comme on l'a vu, certaines de ses caractéristiques paraissent très intéressantes et bienvenues malgré une certaine jeunesse du système.
A contrario, on peut craindre certaines dérives issues de la nature même du système. Se situant dans un objectif de continuité, cet exemple est la preuve que la communauté ne se satisfait plus du système et que celui-ci doit évoluer : nous verrons comment !
Source :
Aucun commentaire:
Enregistrer un commentaire