La faille HeartBleed a beaucoup fait parler d’OpenSSL et des logiciels libres. Pour certains, et c’est ce qui a motivé ce petit article, c’est la démonstration de l’insécurité du logiciel libre. Évidemment au profit du logiciel propriétaire. La réalité est quelque peu plus complexe.

La confiance

Tout est histoire de confiance. Quelque-soit la licence du logiciel qu’on utilise, il y a une relation de confiance sur le bon fonctionnement du logiciel. C’est implicite pour la plupart des utilisateurs, mais la question mérite qu’on s’y penche un peu. Surtout quand le logiciel qu’on utilise a pour rôle de garantir la confidentialité et l’intégrité de nos échanges.

Lorsqu’on utilise un logiciel, la plupart d’entre nous suppose que le logiciel fait seulement ce qu’il est supposé faire, et qu’il le fait bien. C’est ce que j’appelle la confiance implicite de l’utilisateur. Mais si je me pose la question de savoir si j’ai raison de lui faire confiance, les choses se compliquent très vites. Comment vérifier que le logiciel fait bien les choses ? (Ou qu’il n’en fait pas plus, ce qui revient au même pour la question de la confiance ?) Comment être sûr qu’OpenSSL n’est pas infesté de bugs d’implémentation par la NSA ?

C’est là qu’on commence à parler d’audits de sécurité. C’est là qu’on entend qu’il faudrait qu’OpenSSL subisse un audit de sécurité, mais que ça coute cher, et que personne n’a envie de payer pour ça. Pour autant, si OpenSSL était soumis à un audit de sécurité, ça ne fait que déplacer la problématique de la confiance. Si j’ai peur qu’OpenSSL ne permette l’écoute par la NSA, qui me dit que la société qui effectue l’audit ne laisse pas de coté une porte ou deux, au profit de la NSA ? Finalement, faire subir un audit à OpenSSL, ne fait que déplacer la confiance dans le logiciel, vers la société mandatée pour l’audit.

Et que le logiciel soit un logiciel libre ou un logiciel propriétaire ne change rien à ce déplacement de la confiance. Au final, je n’ai d’autre choix que de faire confiance, soit à l’éditeur du logiciel, soit à la société qui me garantit que le logiciel est correctement écrit.

La différence du logiciel libre

On voit que finalement, on est obligé, logiciel libre ou propriétaire, à devoir faire confiance au logiciel, ou à la société qui effectue l’audit.

D’ailleurs, comment la faille HeartBleed a-t-elle été découverte ? Il y a deux raisons principales à ça. La première est le contexte géopolitique actuel, qui après les révélations d’Edward Snowden, met en avant l’importance de solutions de chiffrements réellement solides et efficaces. La confidentialité ne tient qu’à un fil, et les logiciels apportant cette confidentialité attirent toute l’attention.

La seconde raison, directement liée, est la découverte depuis le début de l’année, de deux failles majeures dans des logiciels (libres eux aussi) effectuant ce chiffrement SSL/TLS. Le premier par Apple, le fameux bug « goto fail », et le second, du même acabit, dans le logiciel GNUTLS. Beaucoup de monde concentre donc son attention sur ces logiciels à y rechercher des erreurs. L’étude de ces logiciels est grandement facilité par le fait que leur code source est librement disponible. Sans aller jusqu’à un audit, toute personne sachant programmer un logiciel peut y jeter un œil. Juste sur une petite partie du code, sur un mécanisme qu’il connait, par exemple, sans être un spécialiste.

Dans le cas où le logiciel ne montre pas son code source, il faut analyser le fonctionnement du logiciel dans la mémoire de l’ordinateur, ce qui est beaucoup plus complexe, et demande des compétences élevées. Un étudiant, ou un développeur n’y jettera pas un œil curieux. Et cet étudiant, ce développeur, ne mettra pas le doigt sur un bug qui lui semble évident, et qui est passé au travers des yeux des autres.

En quoi la confiance est affectée par cet accès au code ?

Tout simplement que le logiciel peut être analysé par des entités qui n’ont rien en commun, et qu’on n’est pas obligé de faire aveuglément confiance dans une société d’audits. Et que si une entreprise choisit de ne pas faire confiance, elle a la possibilité de regarder par elle même le contenu du code source. Et c’est là que tout change, on n’est pas obligé de faire confiance dans une société ou une organisation, on peut vérifier par soi-même (malheureusement, on doit quand même faire confiance au matériel, mais c’est un autre débat).

Hélas, cette force de pouvoir vérifier par soi-même le fonctionnement du logiciel a endormi beaucoup de monde. Finalement, le code est disponible, je peux le vérifier si je veux, donc ça me va, j’estime (à tord) que je peux lui faire confiance. Il doit bien y en avoir d’autres qui ont vérifié ! Et on se retrouve à avoir beaucoup de sociétés utilisant le logiciel, à se dire que les autres ont du vérifier qu’il fonctionnait bien. Pour une entreprise de e-commerce, c’est tentant d’utiliser le logiciel comme une brique indispensable et de laisser aux autres la vérification. Finalement le logiciel n’a rien couté, et on lui fait confiance aveuglément. C’est dans cette situation que se trouve OpenSSL. Peu d’entreprises qui utilisent le logiciel participent au logiciel, que ce soit par don, ou par participation au projet.

Et les licences propriétaires ?

La problématique de la confiance est beaucoup plus simple. Utiliser le logiciel propriétaire, c’est choisir de faire confiance dans son éditeur. Sans possibilité de vérification. C’est un choix qui appartient à celui qui le fait, mais qui peut être problématique dans des contextes de sécurité nationale. Utiliser un logiciel propriétaire, c’est être obligé de faire confiance. On perd la possibilité du contrôle.

De plus, c’est la disponibilité du code source des logiciels libres qui a permis de détecter, et de corriger, les problèmes rencontrés depuis le début de l’année. Les erreurs de programmation des logiciels propriétaire ne sont pas visibles en dehors de l’entreprise. Pour ces 3 bugs trouvés dans les logiciels de chiffrement libres, combien ont été oubliés dans les logiciel propriétaires ? Comment s’en assurer ?