Logiciel Libre : donnons-nous les moyens de la confiance

Si l’on doit trouver un aspect positif à la récente vulnérabilité HeartBleed découverte dans OpenSSL, ce serait qu’elle a permis de s’intéresser au financement des projets Libres qui font bien souvent tourner Internet. Et de constater que nous sommes peut-être face à un problème structurel…

Cette affaire a en effet mis en évidence l’incroyable écart qui existe entre l’extrême criticité d’OpenSSL, une librairie devenue quasi-indispensable au fonctionnement d’Internet, et les faibles ressources allouées à son développement.

OpenSSL est utilisée par (au moins) les deux tiers des sites web de la planète, sans compter de nombreux systèmes d’exploitation, des terminaux mobiles et même de très nombreux boîtiers de sécurité, dont ceux de Cisco et beaucoup d’autres fabricants. Sans compter, évidemment, les éditeurs qui l’utilisent en cachette au sein de leurs solutions commerciales…

Et l’on ne parle pas ici d’une quelconque technologie cosmétique : qu’il en soit conscient ou non le tout-internet fait confiance à OpenSSL pour assurer la confidentialité des échanges sur le réseau.

Pourtant, l’équipe de direction du projet ne compte que quatre personnes, dont une seule s’y consacre à temps plein. Et l’équipe de développement compte une dizaine de programmeurs bénévoles. En tout et pour tout le projet fonctionne avec un budget inférieur à 1 million de dollars par an issu essentiellement de dons libres.

Pour résumer, l’une des technologies essentielles au fonctionnement d’Internet n’est financée que par des dons et n’existe que parce qu’une poignée de développeurs bénévoles donnent de leur temps.

Avant HeartBleed, OpenSSL avait déjà été victime d’une autre méga-faille sur le système Linux Debian. Il est intéressant de se pencher sur la manière dont elle a été introduite car cela illustre parfaitement le peu de moyens dont disposent certains projets Open Source au regard de leur popularité et de leur criticité. A l’origine de cette vulnérabilité de 2008 l’on trouve un audit par un développeur bienveillant, qui identifie un problème potentiel (l’utilisation d’une plage de mémoire non-initialisée, ce qui peut introduire des bugs difficiles à repérer). Ce dernier propose de supprimer deux lignes de code, et cela semble régler le problème. Il prend toutefois la peine de soumettre sa solution à la mailing-list openssl-dev en précisant qu’il n’est pas un spécialiste du chiffrement et qu’il ignore l’impact que pourrait avoir sa modification sur la qualité des nombres aléatoires générés par le système. Il obtient quelques réponses de la part de développeurs qui veulent bien réagir. L’une d’elle provient directement d’un contributeur à OpenSSL, qui lui dit que « si cela peut aider à débugger ok pour les retirer » . Sans plus attendre les deux lignes de code sont retirées et Linux Debian connaît l’une des pires vulnérabilités de son existence…

Bien entendu l’on sait tous comment nous en sommes arrivés là. A ses débuts le mouvement Open Source n’était guère pris au sérieux. A cette époque une entreprise digne de ce nom ne comptait évidemment que sur des solutions commerciales ayant pignon sur rue et maintenues à grand frais par leurs éditeurs (c’était l’époque de la fameuse maxime « personne n’a jamais été licencié pour avoir acheté de l’IBM » ). En outre la dépendance économique à Internet n’était encore qu’une vue de l’esprit et il n’y avait donc pas vraiment d’enjeu sur le réseau.

Mais progressivement les solutions Open Source sont devenues de suffisamment bonne qualité pour séduire les geeks de l’entreprise, qui non seulement aimaient fondamentalement l’idée d’une solution ouverte mais qui surtout n’avaient plus besoin d’attendre la signature d’un ordre d’achat pour déployer un serveur web interne, un serveur DHCP ou un relais de messagerie. Ils pouvaient installer et configurer le produit immédiatement, réaliser des tests à loisir et même participer à son évolution en échangeant directement avec ses développeurs. En bref, l’Open Source leur permettait de mieux faire leur travail, plus rapidement et en s’amusant.

Le Libre a donc gagné l’entreprise par le bas, via ses techniciens passionnés dont certains étaient même contributeurs aux projets qu’ils déployaient (on n’est jamais mieux servi que par soi-même !). Et puisque le management traitait de toute manière ces questions techniques par le dédain il n’y avait aucune raison de lui en parler.

Seulement voilà : au fil des années l’entreprise est devenue de plus en plus dépendante de ces technologies, puis d’Internet, tout en refusant toujours de s’intéresser à ce qui se passe sous le capot. Après tout, pour bien des dirigeants d’entreprise de l’époque un site d’e-commerce devait être efficace, bien vendre et coûter le moins cher possible. Et c’est précisément ce que permettait déjà le Logiciel Libre (et cela n’a pas aidé qu’à cette époque nombre de solutions commerciales, notamment pour le web, se soient révélées de qualité inférieure à ce que proposait alors le Libre)

Et puis, sans que l’on sache vraiment quand cela a basculé, l’Open Source est devenu le nouvel IBM : puisque tout le monde déploie Apache, nginx et Bind, développe en PHP et conçoit ses sites sous WordPress, c’est que cela doit fonctionner. « Après tout, personne n’a été licencié pour avoir déployé du LAMP » …

C’est à ce moment que nous sommes devenus la victime d’un biais perfide : l’Open Source a certes trouvé ses lettres de noblesse auprès du grand public et des responsables techniques, mais le mouvement est alors perçu comme équivalent en tous points aux solutions commerciales. Lorsque l’on déploie du Libre on se contente donc de remplacer quelque chose qui fonctionne et nous coûte cher par quelque chose qui fonctionne et nous coûte moins cher. Mais on ne réévalue pas nos attentes vis-à-vis du produit : les solutions commerciales sont conçues et maintenues par des entreprises dont c’est l’activité principale et dont les développeurs salariés consacrent le temps nécessaire à leur évolution. Il doit donc forcément en être de même pour la solution de remplacement puisqu’elle fonctionne aussi bien.
Evidemment, ce n’est pas le cas mais le biais est tenace. Et lorsque ce dernier évolue et que l’Open Source se distingue enfin intrinsèquement de la production commerciale, c’est pour une vision tout aussi inexacte : celle qui voudrait que parce que le code source est disponible il est obligatoirement audité et validé par « quelqu’un d’autre ».

Il en va ainsi de ce qui est probablement la grande incompréhension du siècle numérique : le poumon d’Internet et de la confiance en ligne est animé en grande partie par des solutions robustes et accessibles dont la grande majorité des utilisateurs imaginent soit qu’elles répondent aux mêmes exigences de support et de développement que les produits commerciaux, soit qu’une armée de volontaires sur-motivés en épluche le code nuit après nuit afin d’en garantir l’intégrité et la probité.

Aujourd’hui l’affaire HeartBleed vient nous rappeler que ce n’est pas le cas. Et que si l’on veut continuer à utiliser ces solutions dans les meilleures conditions il faudrait chercher à leur offrir les moyens nécessaire à nos prétentions.

Bien sûr ce n’est pas le cas de tous les projets Libres. Certains, et notamment les plus visibles, sont par exemple financés par des entreprises de service (c’était d’ailleurs l’un des modèles initiaux envisagés pour l’Open Source). C’est le cas par exemple de Linux, dont les distributions Red Hat ou Ubuntu sont soutenues par des sociétés commerciales qui vivent de sa mise en oeuvre et sont censées contribuer au développement de manière plus pérenne.

Sans surprise c’est en matière de chiffrement que le problème est le plus flagrant. Car de tels projets exigent une expertise mathématique de très haut niveau (qui n’a évidemment rien à voir avec le développement) et sont en outre très peu visibles : une librairie SSL est partout, certes, mais elle est surtout cachée sous des projets beaucoup plus glamour.
Et le chiffrement est en prime le domaine où une vulnérabilité est la plus simple à introduire accidentellement et où elle peut faire le plus de mal…

OpenSSL n’est d’ailleurs pas seul dans ce cas. Une vulnérabilité importante a été récemment découverte au sein de la librairie GNUTLS, qui offre des services similaires. Mais n’ayant pas – et de loin – la popularité d’OpenSSL l’impact a été limité.

Alors comment améliorer le financement de ces projets critiques afin d’en garantir la pérennité et l’évolution dans les meilleures conditions de sécurité ? La question ne date malheureusement pas d’hier et elle a déjà été longuement débattue sans que n’émerge de solution miracle.

Car au delà de l’aspect financier le Logiciel Libre est avant tout une expérience sociale. Que l’on parle de philosophie, d’utopie ou même de mode de vie, cet aspect social est primordial à la bonne santé de l’Open Source… mais délicat à associer à l’univers commercial !

Associer trop rapidement l’Open Source au modèle logiciel commercial présente deux risques majeurs. D’abord un risque de tentative d’appropriation ou de noyautage des projets Open Source par des entités commerciales ou gouvernementales. Et ensuite le risque de perdre des pans entiers de développeurs bénévoles si le projet est jugé trop dépendant aux financements de tiers et / ou trop rentable (il semble en effet difficile d’accepter de travailler bénévolement à un projet qui génère du chiffre d’affaire et sert les intérêts financiers d’une minorité de contributeurs ou d’une société commerciale).

Mais jusqu’à présent les dons (de la part de particuliers ou d’entreprises) ou les contrats de support n’ont pas toujours donnés entière satisfaction. Il peuvent certes fonctionner relativement bien pour des développeurs individuels ou de petits projets, mais pour une librairie de chiffrement aussi critique et aussi répandue que OpenSSL cela semble insuffisant (et pourtant Qualys fait partie des donateurs institutionnels au projet OpenSSL)

Le financement participatif pourrait offrir une voie supplémentaire. Mais ce type d’approche n’est adapté qu’à une opération ponctuelle : il pourra donc être très utile pour démarrer un produit ou mener une opération spécifique, mais pas pour assurer le développement d’un projet Open Source dans le temps.

Cela peut malgré tout être salvateur : l’outil de chiffrement Truecrypt a ainsi pu financer un audit de son code source grâce à une campagne participative (le rapport d’audit de la première phase est disponible en ligne). Gageons qu’après HeartBleed OpenSSL n’aurait aucune difficulté à financer de la sorte son propre audit indépendant.

L’audit de code source semble d’ailleurs être un bon candidat aux contributions spontanées d’entreprises clientes des projets Open Source. Avec un peu d’optimisme (d’utopie ?) l’on pourrait presque imaginer que les projets les plus populaires se voient offrir chaque année un audit par une entreprise utilisatrice différente (et un tel audit, réalisé par un cabinet tiers, a le mérite de l’indépendance vis-à-vis de l’entreprise qui règle la facture)

Reste sinon la voie du mécénat : plusieurs projets Libres ont pu survivre ainsi grâce à l’embauche de leur créateur par un éditeur, avec l’assurance de continuer à faire évoluer le projet et de le laisser en licence Open Source. L’entreprise mécène bénéficie quant à elle d’un gain en terme d’image et elle peut mutualiser l’expertise du créateur du projet afin d’alimenter sa R&D et créer des synergies avec ses propres solutions. Lorsque le rapprochement est bien préparé cela peut être gagnant-gagnant.

Qualys a ainsi par exemple embauché Ivan Ristic, l’auteur de modsecurity. Et tandis qu’Ivan développe notre SSL Labs et a contribué à lancer le pare-feu applicatif Libre IronBee, modsecurity continue quant à lui son développement sous licence Open Source au sein de la société Trustwave.

Il existe un certain nombre d’exemples de mécénat similaires, mais certainement pas assez pour assurer la pérennité de tous les projets Libres critiques. En outre un tel fonctionnement réclame un certain degré de liberté et d’indépendance au sein de l’entreprise mécène. Selon la culture de celle-ci l’on peut avoir le meilleur (des deux mondes) comme le pire, et c’est donc un risque à considérer pour le projet.

En outre, si l’on se réfère au budget annuel actuel d’OpenSSL (un million de dollars) il n’est finalement pas certain que beaucoup d’entreprises soient prêtes à y consacrer autant, et ce n’est pourtant pas suffisant…

La bonne solution de financement des projets Open Source critiques au fonctionnement de nos réseaux et de nos centres de données demeure donc à inventer. Son cahier des charges n’est pas très compliqué : la solution choisie devra apporter un niveau de support et de garanties équivalent à celui d’une solution commerciale de première classe, tout en maintenant la philosophie Libre qui a permis à ces projets de voir le jour.

Difficile ? Peut-être est-il alors temps de les déclarer d’utilité publique, voire de les classer au « patrimoine numérique de l’humanité » et les faire financer par les Nations Unies ?