Source : http://www.zdnet.fr/actualites/heartbleed-ramener-la-gestion-des-standards-dans-le-giron-americain-la-pire-solution-39799725.htm
Heartbleed : ramener la gestion des standards dans le giron américain, la pire solution ?
Sécurité : La découverte de la faille Heartbleed, dans OpenSSL, repose la question de l'audit du code des infrastructures critiques. Solution proposée par des spécialistes américains : une supervision gouvernementale. Aïe ?
La faille Heartbleed, révélée hier, occupe depuis le monde de la sécurité. Son ampleur, ses causes, les responsabilités et sa criticité sont toujours l'objet de spéculations, mais il semble d'ores et déjà acté que c'est l'une des plus grosses catastrophes pour OpenSSL et, partant, pour les sites et services très nombreux qui l'implémentent.
N'importe qui ayant un tant soit peu d'intérêt pour la sécurité sur Internet ou le respect de la vie privée - et à ce titre de la navigation, des données personnelles, etc - trouvera un intérêt à la compréhension de Heartbleed. D'autant que la faille est active depuis plus de deux ans et, sans correctif, aurait continué de s'étendre.
Les standards trop concentrés ?
Il faudra sans doute longtemps pour l'anéantir complètement. Si cela passe évidemment par une phase de développement technique, une distribution du code et une implémentation à tous les niveaux par chaque éditeur de site, de service ou de logiciel, les traces ne pourront être effacées qu'une fois les leçons tirées.
Et la première : faut-il laisser la sécurité d'OpenSSL, une bibliothèque permettant l'implémentation de standards tels que le TLS et SSL, entre les mains d'une seule équipe de quinze personnes ? En posant cette question sur ZDNet.com, il ne s'agit pas de chercher des coupables, mais de réfléchir au mode de déploiement d'une fonctionnalité si critique, voire vitale.
Tant d'utilisateurs, de particuliers, de gouvernements et d'institutions, d'entreprises, d'associations, sont dépendants de ce code, que la question mérite d'être débattue. Et ce, sans préjuger du soin apporté par l'équipe d'OpenSSL à la vérification du code et aux garde-fous posés.
Hier soir sur Twitter, l'expert en sécurité Dan Kaminsky, dans une discussion avec son confrèreThomas Ptacek, s'est dit favorable à la supervision indépendante du code des projets importants comme OpenSSL par des entités financées par l'Etat - c'est à dire, l'Etat américain, ce qui posera une nouvelle fois la question de la gouvernance des standards... et également celle des implémentations, puisque Larry Seltzer se dit favorable à une extension.
Son argument est simple : "bien commun, responsabilité commune". Provocateur, jugeront certains courants libertariens et anti-étatiques américains. Provocateur, jugera une autre partie du monde, mais pour d'autres raisons.
La supervision des institutions américaines, fausse bonne idée ?
L'extension des pouvoirs du NIST (Institut national des standards et technologies) ou d'un autre aurait pour effet, certes, de garantir une révision du code qui ne reste pas entre les mains de quelques-uns - même si, une fois encore, on ne peut pas d'emblée faire ce reproche à OpenSSL.
Cela dit, quelle légitimité pour une organisation américaine, dépendant du gouvernement des Etats-Unis, à l'heure où l'Icann ne sait plus comment sortir de l'embarras de la tutelle américaineet où l'IETF se débat avec les accusations de noyautage par la NSA ?
"Le système pourrait fonctionner grâce à la responsabilité accordée à une organisation externe, peut-être même une entreprise privée, de faire des audits sur les logiciels jugés critiques par une autorité gouvernementale (cela pourrait être le NIST)", précise Larry Seltzer, de ZDNet.com
Admettons. Et de fait, "il n'y aura jamais assez d'argent pour ce genre de choses". Mais le blogueur plaide pour que l'industrie privée ait la possibilité de participer au financement, avec une procédure d'audit publique et transparente.
Matthew Green, professeur en cryptographie, plaide même pour que "les cinq plus grosses entreprises du numérique consacrent un développeur pendant deux ans." Autant de pistes intéressantes qui posent la question des infrastructures critiques : quelles sont-elles, et comment en assurer l'audit ?
On en ajouterait une autre : comment ne pas, une fois de plus, laisser les procédures de création et de validation des standards et des implémentations aux mains du gouvernement et de l'industrie des Etats-Unis ?
