Archive

Archive for April, 2011

Le futur de la sécurité Web, ce n’est pas le https

April 4th, 2011 2 comments

Suite aux problèmes récents de divers fournisseurs officiels de certificats, notamment Comodo, on peut croiser ici et diverses propositions de changement (assez radicaux) quant à la gestion des certificats. Certains parlent d’un Web of Trust (pour faire simple et court, c’est l’utilisateur qui choisi au cas par cas à qui il fait confiance), d’autres encore pensent à sortir du modèle actuel des fournisseurs officiels, en utilisant notamment le DNS pour fournir l’information sur le certificat attendu, ce qui permettrait au navigateur de savoir si le certificat reçu est celui attendu.

Cependant, toutes ces propositions ne sont là que pour corriger le modèle actuel des fournisseurs de certificats, aucune proposition (du moins parmi celle que j’ai lues) ne remet en question le modèle du HTTPs, à savoir de la protection de transport. Pour moi, le vrai problème ne se situe plus à la protection du transport, mais à la protection du contenu. Qu’est ce que je veux dire par là ? Prenons un cas simple, une page d’authentification. Il va de soit que l’identifiant et surtout le mot de passe doit être transmis de manière sécurisé.

Aujourd’hui nous utilisons de plus en plus de sites internets, issus de différents éditeurs, et surtout de plus en plus de portails. Comme je l’avais imaginé il y a déjà plus de 2 ans, de mon avis l’avenir réside dans le fait de sécuriser le contenu, et non plus le contenant. Prenons l’exemple d’un utilisateur qui va sur un site que l’on appellera BLOG, cette personne veut publier un commentaire, mais ne dispose pas d’un compte sur la plateforme BLOG. Peu importe, nous sommes au XXI ème siècle, il est possible de s’identifier via Facebook ! Oui mais… suivant comment est implémentée cette authentification, rien ne garanti que le mot de passe circule de manière chiffrée sur la plateforme BLOG. Cependant, l’authentification est un cas à part, il existe déjà des mécanismes pour éviter ce genre de problème, notamment la fédération d’identité, qui permet à un fournisseur de service (tel qu’un blog wordpress comme celui que vous lisez actuellement) d’être indépendant du fournisseur d’identité (là où on tape son identifiant et son mot de passe).

Le principe est relativement simple, plutôt que de chiffrer le tuyau d’une communication sensible, on chiffre le contenu de la communication, qui peut donc transiter de manière sûre via des canaux non sûrs. Bien entendu, cela ne change en rien la problématique de délivrance des certificats. Mais je pense que plutôt que d’essayer de corriger le problème en bout de chaîne, essayons de corriger la source. Par exemple, la plupart de nos chers voisins belges disposent d’une carte d’identité électronique, qui contient un certificat. Ce dernier, au travers d’un lecteur de carte (avec des drivers qui fonctionnent aussi bien sous Windows que sous Linux, en passant par Mac OS X), peuvent utiliser leur certificat, notamment pour déposer des dossiers légaux de manière purement électronique. En aucun cas je ne suis en train de dire que tous les certificats serveurs doivent être délivrés par l’État ou assimilé (encore que, quand on voit cet article on peut se demander de la pertinence d’une telle solution). Mais l’utilisation massive par les utilisateurs d’un certificat permettrait – je le pense – une meilleure compréhension, et surtout cela imposerait aux éditeurs de logiciels de prendre du temps pour réfléchir à l’ergonomie associée. Car, et je terminerais la dessus, le problème de sécurité des certificats actuels, est surtout lié aux éditeurs des navigateurs.

En effet, bien que l’on puisse reprocher l’aspect monétaire, le modèle actuel pêche surtout par l’absence de renouvellement régulier des certificats racines, certains sont en 1024 bits, d’autres utilisent du MD4 (non, il n’y a pas de typo, je parle bien de MD4 et non MD5, qui de toute manière est tout aussi faible dans le cas de certificats). De plus, bien qu’il existe des mécanismes de vérification des certificats (tel que l’utilisation de CRL, et surtout de l’OCSP) ces mécanismes ne sont pas activés par défaut sur les navigateurs et/ou systèmes d’exploitations. Pour conclure, plutôt que d’essayer de trouver un nouveau modèle, il faudrait utiliser les technologies qui nous sont d’ores et déjà proposées.

Categories: Security Tags: