La tempête commence à passer pour OpenSSL et sa récente faille critique. C’est pour rappel un programme généraliste pour tout ce qui est chiffrement, y compris les certificats X509, les tunnels SSL et assimilés. On peut voir un peu partout sur internet les implications de cette faille nommée Heartbleed.
Un site web et un logo sont dédiés à cette faille :
Évidemment, c’est un gros problème pour une grande partie des serveurs sur Internet, et pas que pour les serveurs web. Tous les services qui sécurisent leurs communications avec TLS sont potentiellement impactés, et surtout tous ceux qui utilisent la librairie OpenSSL. Cela inclut des serveurs web (https) mais aussi la messagerie (smtp, imaps, pop3s), la messagerie instantanée (xmpp), etc…
Le plus rude pour un administrateur d’un serveur concerné, c’est que rien n’apparaît dans les logs (journaux). Tout au plus peut-on voir les tentatives avec un IDS ou une analyse fine du trafic réseau.
Pour résumer l’ambiance, rien de mieux que la citation :
« Si vous gardez votre sang-froid alors que tout le monde panique autour de vous, peut-être avez-vous mal évalué la situation »
Stéphane Bortzmeyer (site)
Aujourd’hui, un serveur concerné par la faille et non à jour est un serveur vulnérable.
Et les machines utilisateurs ?
Elle sont concernées aussi. OpenSSL est inclus dans beaucoup de logiciels pour gérer facilement le chiffrement. La faille marche aussi en sens inverse, depuis un serveur malveillant.
Pour ma pomme, mon principal serveur utilise une version un peu plus ancienne de OpenSSL, packagée. Cette version reçoit régulièrement des correctifs mais n’est pas impactée par Heartbleed. Ça passe pour cette fois même si je suis bon pour devoir mettre à jour tout mon serveur prochainement…
J’utilise aussi OpenSSL pour le projet nebule et le projet sylabe. Les fonctions internes de chiffrement et signature ne sont pas concernées. L’accès aux serveurs, via https, est concerné pour certains robots de test de sylabe. Ils n’ont pas été utilisés pendant la semaine de tempête.
Quels utilisateurs sont potentiellement concernés ?
En fait, tous les utilisateurs qui ont utilisés un compte sur un serveur utilisant OpenSSL avec la faille.
Il suffit pour les admins de regarder les logs des connexions côté public et de prévenir tous les utilisateurs qui se sont connectés pendant la période de temps critique. Mais une société commerciale a-t-elle vraiment envie de diffuser à ses utilisateurs que ses serveurs ne sont pas forcément aussi sûrs que ça !?
Doit-on prendre comme début de période de temps la date de diffusion publique de la faille ? Ou doit-on prendre la date d’ajout de la faille (volontaire ou pas), 2012 ? On passe de la semaine aux deux dernières années. On passe des dernières connexions à tous les utilisateurs. L’impacte n’est pas le même.
Et puis ce n’est pas aussi simple que ça. Si le chiffrement des connexions est séparé des serveurs web, si on a des frontaux dédiés aux tunnels TLS, seuls ceux-ci sont concernés. Il n’est dans ce cas pas utile de faire changer les mots de passes des utilisateurs.
Certaines grosses sociétés américaines ont été prévenues un peu en avance de la diffusion pour être à jour au bon moment. Il ne s’agirait pas que des services critiques comme Google ou Facebook ne soient bloqués, les banques peuvent attendre ;-)
Il pourrait être tentant pour certains admins de changer de solution de chiffrement. Oui, mais laquelle choisir? GnuTLS? Celle de Microsoft? Une solution propriétaire payante?
Je ne suis pas sûr du tout qu’échanger un programme avec les sources publiques par un programme aux sources fermées (programme privateur) soit une bonne solution. Quelque soit la qualité de certains programmes de M$, en logiciels de sécurité, il n’est pas très bien vu de ne pas disposer des sources. Quelle confiance peut-on apporter à un programme qui ne peut être librement audité par tout le monde. Je passe sur les récentes affaires révélées par Mr Snowden. La sécurité par l’obscurité, c’est comme ça que cela s’appelle, est très souvent employée pour cacher les choses mal programmées.
Ceci dit, la diversité à aussi du bon. Mixer les technologies et implémentations permet de ne pas se retrouver avec tous ses serveurs à poil en même temps en cas de coup dur comme Heartbleed…
GnuTLS a eu des problèmes récemment, SecureTransport de Apple aussi. Les problèmes ne sont donc pas spécifiques aux logiciels à code ouvert.
Ce n’est pas la première fois que l’on a ce genre de problème, et ce ne sera pas la dernière.
Une solution, séparer la fonction de chiffrement TLS sur des serveurs dédiés. Le bout des tunnels sécurisés s’arrêtent aux portes des serveurs web, sur des machines spécialisées. Dans ce cas, seules les connexions en cours, leurs clés de sessions, sont vulnérables.
Les certificats de ces serveurs frontaux TLS sont aussi potentiellement compromis, donc à changer, sauf si ceux-ci sont stockés sur des cartes dédiées (pas en mémoire).
C’est d’ailleurs une bonne pratique pour tous les serveurs, et pas seulement les frontaux web : séparer les services entres eux et les applications sur des serveurs différents. Les séparer sur des machines physiques différentes et des réseaux physiques différents si leurs criticités sont différentes. Mais comme toujours, ça demande du temps, des compétences et du pognon.
L’autre solution, si tu es concerné :
- mettre à jour les serveurs et les postes clients ;
- changer les certificats des serveurs ;
- changer les mots de passes des utilisateurs.
Une question reste en suspend. Est-ce une 0-days ?
Va-t-on découvrir que certains l’utilisaient depuis quelques temps ? La NSA par exemple ? Rien n’est jamais définitivement écrit.