6 minute(s) de lecture
Image illustrant la campagne d'adhésion

HeartBleed, tous à poil sur Internet

SSL/TLS, la base des communications chiffrées, pas si chiffrées que ça en fait

Lorsque vous naviguez sur Internet, vous utilisez parfois sans le savoir des liaisons sécurisées. Ce sont en fait des liaisons chiffrées. C’est le cas lorsque vous vous connectez à votre webmail favori ou au site de votre banque. On comprend tout à fait l’intérêt d’une telle sécurisation. Si elle est absente, alors vos données transitent en clair entre votre ordinateur et le serveur. Il est ainsi très facile de lire directement vos identifiants de messagerie ou vos identifiants bancaires. Une agence gouvernementale, ou tout individu malveillant écoutant le trafic entre vous et ce serveur, peut aussi accéder au contenu de vos messages.

La majorité des serveurs sécurisés utilisent le protocole dit HTTPS. Lorsque vous êtes connecté sur un tel site, un cadenas apparaît dans la barre d’URL. Le logiciel utilisé pour chiffrer vos communications est la plupart du temps le logiciel libre OpenSSL. Dernièrement une faille a été dévoilée par des chercheurs en sécurité informatique dans cette bibliothèque OpenSSL. Son nom est « HeartBleed » (Cœur qui saigne). Cette faille a été introduite il y a deux ans et exposait le contenu de la mémoire du serveur. N’importe qui a donc pu accéder à des données confidentielles des serveurs impactés, et ce depuis cette date. Cette faille ne laisse strictement aucune trace si elle est exploitée, il faut donc considérer que toute machine qui présentait ce défaut a été compromise et que des données utilisateurs ont fuité et que les clefs privées de serveurs ont été récupérées.

Le spectre de la NSA

Il y a un point extrêmement gênant si on recroise avec l’affaire NSA/Prism. La NSA stocke l’intégralité des échanges qu’elle espionne, y compris les communications chiffrées SSL/TLS (consultation de sites web, échange de courriel, communication via Jabber…), en espérant pouvoir les déchiffrer plus tard (faille révélée, attaque directe, augmentation des moyens technologiques…). Elle a donc très bien pu récupérer les clefs privées de machines compromises pour déchiffrer l’intégralité des communications théoriquement sécurisées qui ont pu avoir lieu par le passé et qu’elle avait stockées en vue d’un déchiffrement ultérieur. Le déchiffrement possible correspond à tous les messages chiffrés par la clef privée correspondante, et ne se limite donc pas à la durée de vie du certificat SSL (généralement d’un an) réellement utilisé lors de l’exploitation de la faille HeartBleed. Si le service en cause a toujours utilisé la même clef privée depuis des décennies, ce sont des années de communications sécurisées qui viennent de s’écrouler. Les seuls serveurs qui ont pu éviter ce problème sont évidemment ceux qui n’étaient pas soumis à la faille en question, et ceux qui avaient mis en place PFS (Perfect Forward Secrecy). Ces derniers sont malheureusement encore bien trop rares, moins de 3% des serveurs.

Le rôle du logiciel libre dans la gestion de HeartBleed

Quelles leçons tirer de tout cela ? Par une analyse trop rapide, on pourrait dire qu’HeartBleed est une catastrophe pour le logiciel libre. Le fait d’avoir un code libre et ouvert a cependant permis de réduire considérablement l’impact de cette faille. Déjà, même si l’impact de cette faille peut potentiellement être énorme, personne n’a jamais dit que le logiciel libre était infaillible ! Maintenant, imaginez-vous un instant qu’une faille de ce genre soit arrivée dans un logiciel privateur

Les 4 libertés, l’accès direct à un correctif

N’ayant pas accès au code-source, une personne qui aurait constaté un comportement anormal (ici, l’accès à une zone mémoire théoriquement inaccessible) n’aurait pas pu comprendre l’origine même du problème (ici une non-vérification d’une borne dans un tableau). Dans le cas de HeartBleed, c’est même l’analyse du code lui-même, en voulant y ajouter de nouvelles fonctionnalités, qui a permis la détection de l’erreur. Ensuite, la correction a pu être immédiatement proposée par et à la communauté, le code-source étant une nouvelle fois disponible. Ça n’aurait pas été possible aussi facilement avec un logiciel privateur, le correctif ne pouvant être fait que par l’entité en charge du code.

Pire, il est fort probable que des failles de ce type existent dans du logiciel privateur… Et que personne n’en soit au courant parce que ça ne sort pas de l’entreprise en question et surtout que l’entreprise ne souhaite pas corriger pour diverses raisons : atteinte à son image, correction jugée non prioritaire (surtout si la présence de la faille ne s’est pas ébruitée chez les utilisateurs), manque de personnel (occupé sur d’autres projets), vulnérabilité volontaire à la demande d’entités gouvernementales…

Le logiciel libre, distribué mais organisé

Le déploiement a aussi été très rapide, avec des correctifs proposés en quelques heures par la plupart des distributions GNU/Linux ou BSD. Les gestionnaires de paquets1 ont grandement facilité le travail, ce qui n’aurait pas été aussi évident et efficace par exemple sous Microsoft Windows qui ne centralise pas l’installation des logiciels proposés et ne peut corriger que son système d’exploitation et les logiciels Microsoft et non les logiciels tiers installés par l’utilisateur.

« Communauté », j’écris ton nom

Des cas récents issus du logiciel privateur démontrent aussi qu’une société aussi rentable soit-elle et quelle que soit la qualité technique de son personnel reste vulnérable. C’est bien la vigilance de la communauté qui permet de trouver les failles. Ainsi, Apple a officiellement remercié les hackers qui produisent les jailbreaks de iOS7, pour leur avoir permis de détecter une faille de sécurité qu’ils avaient laissé dans leur code. Bien entendu, ces remerciements étaient teintés de sarcasme, mais cela démontre bien l’inefficacité du modèle propriétaire à trouver les failles. D’autres failles ont été trouvées sur des systèmes privateurs, notamment par un enfant de 5 ans.

C’est finalement la routine dans le monde informatique de détecter et de corriger des bugs. Le logiciel libre présente pourtant un avantage certain sur ce terrain, l’accès à son code source dans son intégralité, par n’importe qui et pour n’importe quel usage, ce qui signifie qu’on peut tous participer à trouver de telles failles, qu’on peut tous les corriger immédiatement pour son propre usage et qu’on peut tous en faire profiter le reste de la communauté. Avec une analyse plus poussée de l’événement « HeartBleed », la gestion de cette faille est en fait une preuve de l’efficacité du logiciel libre : elle a été corrigée en moins de 24h sur des dizaines de distributions et d’architectures différentes, et de manière très simple dans la plupart des cas ! Cette réactivité dans la correction des problèmes de sécurité est spécifique aux logiciels libres car l’organisation de la communauté et l’accès à son code source permet une collaboration de centaines de développeurs très rapidement.