{"id":1612,"date":"2014-04-13T13:47:28","date_gmt":"2014-04-13T11:47:28","guid":{"rendered":"http:\/\/stephane.weblog.starend.org\/?p=1612"},"modified":"2014-04-13T13:47:28","modified_gmt":"2014-04-13T11:47:28","slug":"heartbleed","status":"publish","type":"post","link":"http:\/\/stephane.weblog.starend.org\/?p=1612","title":{"rendered":"Heartbleed"},"content":{"rendered":"

La temp\u00eate commence \u00e0 passer pour OpenSSL<\/a> et sa r\u00e9cente faille critique<\/a>. C’est pour rappel un programme g\u00e9n\u00e9raliste pour tout ce qui est chiffrement, y compris les certificats X509<\/em>, les tunnels SSL<\/a> et assimil\u00e9s. On<\/a> peut<\/a> voir<\/a> un peu<\/a> partout<\/a> sur<\/a> internet<\/a> les implications<\/a> de cette<\/a> faille<\/a> nomm\u00e9e<\/a> Heartbleed<\/a>.<\/p>\n

Un site web et un logo sont d\u00e9di\u00e9s \u00e0 cette faille :<\/p>\n

\"heartbleed\"<\/a>
\nhttp:\/\/heartbleed.com\/<\/a><\/p>\n

\u00c9videmment, c’est un gros probl\u00e8me pour une grande partie des serveurs sur Internet, et pas que pour les serveurs web. Tous les services qui s\u00e9curisent leurs communications avec TLS<\/a> sont potentiellement impact\u00e9s, et surtout tous ceux qui utilisent la librairie OpenSSL<\/em>. Cela inclut des serveurs web (https<\/em>) mais aussi la messagerie (smtp<\/em>, imaps<\/em>, pop3s<\/em>), la messagerie instantan\u00e9e (xmpp<\/em>), etc…
\nLe plus rude pour un administrateur d’un serveur concern\u00e9, c’est que rien n’appara\u00eet dans les logs (journaux). Tout au plus peut-on voir les tentatives avec un IDS<\/em> ou une analyse fine du trafic r\u00e9seau.<\/p>\n

Pour r\u00e9sumer l’ambiance, rien de mieux que la citation :<\/p>\n

\u00ab\u00a0Si vous gardez votre sang-froid alors que tout le monde panique autour de vous, peut-\u00eatre avez-vous mal \u00e9valu\u00e9 la situation\u00a0\u00bb<\/strong>
\nSt\u00e9phane Bortzmeyer<\/em> (site<\/a>)<\/p>\n

Aujourd’hui, un serveur concern\u00e9 par la faille et non \u00e0 jour est un serveur vuln\u00e9rable<\/span><\/a>.<\/span><\/p>\n

Et les machines utilisateurs ?
\nElle sont concern\u00e9es aussi<\/a>. OpenSSL<\/em> est inclus dans beaucoup de logiciels pour g\u00e9rer facilement le chiffrement. La faille marche aussi en sens inverse, depuis un serveur malveillant.<\/p>\n

Pour ma pomme, mon principal serveur utilise une version un peu plus ancienne de OpenSSL<\/em>, packag\u00e9e. Cette version re\u00e7oit r\u00e9guli\u00e8rement des correctifs mais n’est pas impact\u00e9e par Heartbleed<\/em>. \u00c7a passe pour cette fois m\u00eame si je suis bon pour devoir mettre \u00e0 jour tout mon serveur prochainement…
\nJ’utilise aussi OpenSSL<\/em> pour le projet nebule<\/a> et le projet sylabe<\/a>. Les fonctions internes de chiffrement et signature ne sont pas concern\u00e9es. L’acc\u00e8s aux serveurs, via https<\/em>, est concern\u00e9 pour certains robots de test de sylabe<\/em>. Ils n’ont pas \u00e9t\u00e9 utilis\u00e9s pendant la semaine de temp\u00eate.<\/p>\n

Quels utilisateurs sont potentiellement concern\u00e9s ?
\nEn fait, tous les utilisateurs qui ont utilis\u00e9s un compte sur un serveur utilisant OpenSSL<\/em> avec la faille.
\nIl suffit pour les admins de regarder les logs des connexions c\u00f4t\u00e9 public et de pr\u00e9venir tous les utilisateurs qui se sont connect\u00e9s pendant la p\u00e9riode de temps critique. Mais une soci\u00e9t\u00e9 commerciale a-t-elle vraiment envie de diffuser \u00e0 ses utilisateurs que ses serveurs ne sont pas forc\u00e9ment aussi s\u00fcrs que \u00e7a !?
\nDoit-on prendre comme d\u00e9but de p\u00e9riode 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\u00e8res ann\u00e9es. On passe des derni\u00e8res connexions \u00e0 tous les utilisateurs. L’impacte n’est pas le m\u00eame.
\nEt puis ce n’est pas aussi simple que \u00e7a. Si le chiffrement des connexions est s\u00e9par\u00e9 des serveurs web, si on a des frontaux d\u00e9di\u00e9s aux tunnels TLS, seuls ceux-ci sont concern\u00e9s. Il n’est dans ce cas pas utile de faire changer les mots de passes des utilisateurs.
\nCertaines grosses soci\u00e9t\u00e9s am\u00e9ricaines ont \u00e9t\u00e9 pr\u00e9venues un peu en avance de la diffusion pour \u00eatre \u00e0 jour au bon moment. Il ne s’agirait pas que des services critiques comme Google<\/em> ou Facebook<\/em> ne soient bloqu\u00e9s, les banques peuvent attendre ;-)<\/p>\n

Il pourrait \u00eatre tentant pour certains admins de changer de solution de chiffrement. Oui, mais laquelle choisir? GnuTLS<\/a>? Celle de Microsoft<\/em>? Une solution propri\u00e9taire payante?
\nJe ne suis pas s\u00fcr du tout qu’\u00e9changer un programme avec les sources publiques par un programme aux sources ferm\u00e9es (programme privateur) soit une bonne solution. Quelque soit la qualit\u00e9 de certains programmes de M$, en logiciels de s\u00e9curit\u00e9, il n’est pas tr\u00e8s bien vu de ne pas disposer des sources. Quelle confiance peut-on apporter \u00e0 un programme qui ne peut \u00eatre librement audit\u00e9 par tout le monde. Je passe sur les r\u00e9centes affaires r\u00e9v\u00e9l\u00e9es par Mr Snowden<\/em>. La s\u00e9curit\u00e9 par l’obscurit\u00e9, c’est comme \u00e7a que cela s’appelle, est tr\u00e8s souvent employ\u00e9e pour cacher les choses mal programm\u00e9es.
\nCeci dit, la diversit\u00e9 \u00e0 aussi du bon. Mixer les technologies et impl\u00e9mentations permet de ne pas se retrouver avec tous ses serveurs \u00e0 poil en m\u00eame temps en cas de coup dur comme Heartbleed<\/em>…
\nGnuTLS<\/em> a eu des probl\u00e8mes<\/a> r\u00e9cemment, SecureTransport<\/em> de Apple<\/em> aussi<\/a>. Les probl\u00e8mes ne sont donc pas sp\u00e9cifiques aux logiciels \u00e0 code ouvert.
\nCe n’est pas la premi\u00e8re fois que l’on a ce genre de probl\u00e8me, et ce ne sera pas la derni\u00e8re.<\/p>\n

Une solution, s\u00e9parer la fonction de chiffrement TLS<\/em> sur des serveurs d\u00e9di\u00e9s. Le bout des tunnels s\u00e9curis\u00e9s s’arr\u00eatent aux portes des serveurs web, sur des machines sp\u00e9cialis\u00e9es. Dans ce cas, seules les connexions en cours, leurs cl\u00e9s de sessions, sont vuln\u00e9rables.
\nLes certificats de ces serveurs frontaux TLS<\/em> sont aussi potentiellement compromis, donc \u00e0 changer, sauf si ceux-ci sont stock\u00e9s sur des cartes d\u00e9di\u00e9es (pas en m\u00e9moire).
\nC’est d’ailleurs une bonne pratique pour tous les serveurs, et pas seulement les frontaux web : s\u00e9parer les services entres eux et les applications sur des serveurs diff\u00e9rents. Les s\u00e9parer sur des machines physiques diff\u00e9rentes et des r\u00e9seaux physiques diff\u00e9rents si leurs criticit\u00e9s sont diff\u00e9rentes. Mais comme toujours, \u00e7a demande du temps, des comp\u00e9tences et du pognon.<\/p>\n

L’autre solution, si tu es concern\u00e9 :<\/p>\n

    \n
  1. mettre \u00e0 jour les serveurs et les postes clients ;<\/li>\n
  2. changer les certificats des serveurs ;<\/li>\n
  3. changer les mots de passes des utilisateurs.<\/li>\n<\/ol>\n

    Une question reste en suspend. Est-ce une 0-days<\/em> ?
    \nVa-t-on d\u00e9couvrir que certains l’utilisaient depuis quelques temps ? La     NSA<\/a> par<\/a> exemple<\/a> ? Rien n’est jamais d\u00e9finitivement \u00e9crit.<\/p>\n","protected":false},"excerpt":{"rendered":"

    La temp\u00eate commence \u00e0 passer pour OpenSSL et sa r\u00e9cente faille critique. C’est pour rappel un programme g\u00e9n\u00e9raliste pour tout ce qui est chiffrement, y compris les certificats X509, les tunnels SSL et assimil\u00e9s. On peut voir un peu partout sur internet les implications de cette faille nomm\u00e9e Heartbleed. Un site web et un logo … Continuer la lecture de Heartbleed<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[2,42,10],"tags":[194,208,287],"_links":{"self":[{"href":"http:\/\/stephane.weblog.starend.org\/index.php?rest_route=\/wp\/v2\/posts\/1612"}],"collection":[{"href":"http:\/\/stephane.weblog.starend.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/stephane.weblog.starend.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/stephane.weblog.starend.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/stephane.weblog.starend.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1612"}],"version-history":[{"count":0,"href":"http:\/\/stephane.weblog.starend.org\/index.php?rest_route=\/wp\/v2\/posts\/1612\/revisions"}],"wp:attachment":[{"href":"http:\/\/stephane.weblog.starend.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1612"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/stephane.weblog.starend.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1612"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/stephane.weblog.starend.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1612"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}