«Sur une échelle de 1 à 10, j’évalue Heartbleed à 11!» Imagé, le commentaire du cryptologue américain Bruce Schneier, gourou de la cybersécurité, n’est reste pas moins extrêmement inquiétant.

Découverte le 7 avril, la faille laisse toujours les spécialistes perplexes quant à son origine. On n’a d’ailleurs aucune idée des dommages réels que va causer Heartbleed dans la mesure où il est impossible de savoir quelles sont les données qui ont été exposées, surtout à posteriori, et qui les a récupérées.

Concrètement, Heartbleed est un problème d’allocation de mémoire dans l’implémentation d’un protocole appelé Heartbeat, ajouté à OpenSSL en février 2012 -la faille permet de récupérer 64 000 octets de mémoire dans lesquels peuvent figurer des login et mots de passe, mais aussi la clef privée du serveur.

Si, selon DenyAll, plus de 80% des 100 000 plus grands sites de la planète étaient concernés par la faille le 8 avril, à peine 5% l’étaient encore le lendemain grâce à la version 1.0.1g de OpenSSL. Identifié, le problème n’est pas pour autant complètement résolu. La faille touche tant le monde du développement et des applications Web, pour lequel des solutions existent (patches ou recompilation) que des éléments physiques.

Première action: inventorier tous les systèmes pouvant embarquer OpenSSL. C’est-à-dire tous les équipements utilisant des communications chiffrées, car dès que le protocole HTTPS est employé, il y a des probabilités importantes que la vulnérabilité soit présente. Entre-temps, constructeurs et éditeurs ont fait leur boulot: les mises à jour ont suivi.

Commencez par patcher au plus vite les éléments les plus critiques, conseillent les spécialistes. Et dites-vous que la remise à niveau de OpenSSL n’est pas tout, loin de là. Le bug impacte beaucoup d’éléments. Il faudra donc du temps. Un travail qui s’étalera sur plusieurs mois et le respect d’un ordre très strict d’actions, faute de quoi les premiers efforts seront potentiellement vains…

Corollaire: la question du renouvellement des certificats. Les avis sont partagés. Pour certains, c’est un passage obligé; pour d’autres, non partant que certaines infrastructures de sécurité permettent de protéger les clefs privées de chiffrement…

Quelles leçons en tirer? D’abord, les faiblesses du développement Open Source, en raison d’un évident manque de ressources. Ce qui veut dire, aussi, qu’une large part du chiffrement dans le monde dépend de quelques développeurs à temps partiel… Ensuite, même si ce n’est pas nouveau, la propension de certains éditeurs à consolider leur image sur la faiblesse même -c’est le cas du finlandais Codenomicon, éditeur spécialisé dans l’analyse de code qui, très vite, à développé un site web spécifique et même un logo. Rien ne se perd!