Le bogue Heartbleed (et il s’agit certainement d’un bogue - et non d’un virus) a déclenché un débat sur la sécurité et la fiabilité des logiciels open source au cours des derniers mois..

Découverte par des chercheurs de Google et de Codenomicon, cette vulnérabilité a été découverte dans la bibliothèque de logiciels de chiffrement OpenSSL open source, qui fournit une protection SSL (Secure Sockets Layer) et TSL (Transport Layer Security) pour tous types d'informations, des e-mails à la navigation Web en passant par les transactions bancaires en ligne..

L’erreur de programmation qui a conduit à Heartbleed - qui a été introduite par inadvertance par le programmeur allemand Dr. Robin Seggelmann, contributeur fréquent du code OpenSSL - permet aux attaquants de télécharger 64 000 morceaux de données stockées dans la mémoire principale supposée sécurisée des serveurs.

Ce fut une erreur honnête, mais avec des conséquences d'une portée considérable. Selon Errata Security, environ 320 000 des 600 000 serveurs vulnérables détectés sont toujours vulnérables à Heartbleed..

Après Heartbleed, chaque clé privée sur des serveurs exécutant OpenSSL est désormais suspecte et pourrait être potentiellement utilisée par des attaquants pour emprunter l'identité de sites Web sécurisés tant que ces serveurs ne sont pas corrigés..

Est-il temps de passer d'OpenSSL à une solution commerciale (ou une autre alternative) en matière de sécurité Web? Nous avons rencontré des experts du secteur à Infosec 2014 pour en savoir plus..

Maintenir l'open source - il a encore beaucoup à offrir…

James Sherlow, SE Manager chez SEUR chez Palo Alto Networks, pense que laisser tomber OpenSSL à la suite de Heartbleed serait une sorte de réaction irréfléchie:

"OpenSSL est toujours très pertinent et possède une évolutivité. Il possède une communauté de développeurs hautement qualifiés, ce qui est extrêmement précieux et toujours valable. Chaque logiciel, à un moment donné, sera associé à une sorte de vulnérabilité, mais pas signifie que nous l'éteignons, cela signifie que nous apprenons de nos leçons. "

… Mais Heartbleed était un réveil

"Je pense que la communauté open source doit commencer à mettre en place des mécanismes dans différents domaines qui pourraient en vérifier les vérifications. C'est mieux que de pointer du doigt et de blâmer qui ne mène personne. Cela réduirait le risque, réduirait le risque d'attaque et Il est difficile d'atteindre zéro erreur, mais visons-le. C'est la barre. "

Vous ne pouviez pas simplement le supprimer de toute façon…

La question de savoir si nous devrions nous débarrasser d'OpenSSL n'est pas si noir et blanc, selon JD Sherry, vice-président de la division Technology & Solutions de Trend Micro. Il estime qu'au lieu de refuser les services de contributeurs open source dévoués et talentueux, des récompenses devraient être offertes à ceux qui recherchent des erreurs dans leur travail:

"L'open source constituera toujours une partie innée de notre travail, principalement parce que son ingénierie est formidable. Beaucoup de gens consacrent leur passion à ces projets et génèrent un excellent travail."

… Alors introduisons plus de primes de bugs

"Des entreprises telles que Google, Microsoft et Facebook se sont réunies pour dépenser 100 000 dollars chacune pour aller au coeur de Heartbleed, ce qui ne suffit pas pour arrêter un scénario potentiellement similaire. le problème de bug, et ils peuvent être extrêmement importants.

"Le coût de leur mise en œuvre et de leur paiement peut valoir le résultat d'un défaut majeur dans votre logiciel qui avait été omis lors du processus de contrôle de la qualité. Qu'ils soient à source ouverte ou non, ils seront essentiels pour assurer nous n'avons pas énormément de cas Heartbleed ou autres OpenSSL. "

OpenSSL était cassé depuis le début…

Tout le monde n’a pas été aussi indulgent envers OpenSSL. FreeBSD et le développeur de la sécurité Poul-Henning Kamp ont appelé à sa tête dans un article de blog intitulé Open SSL doit mourir, car cela ne s'améliorera jamais:

"Et cela me ramène à OpenSSL - ce qui est nul. Le code est un fouillis, la documentation est trompeuse et les valeurs par défaut sont trompeuses. De plus, 300 000 lignes de code souffrent de presque toutes les difficultés d'ingénierie logicielle que vous pouvez imaginer."