Journal journal bookmark : vers un fork d'OpenSSL ?

Posté par  . Licence CC By‑SA.
Étiquettes :
55
15
avr.
2014

Bonjour Nal,

je t'écris pour te faire part d'un possible fork d'OpenSSL par les développeurs d'OpenBSD qui ont démarré depuis quelques jours un nettoyage complet.

Entre autres :

  • suppression des fonctionnalités heartbeat qui ont conduit au bug de la semaine dernière;
  • suppression de beaucoup de code cryptographique en trop;
  • suppression de wrappers autour de fonctions standard, en particulier pour malloc qui entravait des techniques de mitigation d'exploit

et autres nettoyages divers (cf premier lien), ce qui vu de loin paraît assez impressionnant en juste quelque jours.

Il ne reste plus qu'à attendre pour voir ce qu'il adviendra, mais en tous cas ce qui est sûr c'est que le code d'OpenSSL va être passé à la loupe, et peut-être que finalement le bug de la semaine dernière aura de bonnes conséquences à long terme.

NdM: correction du nom de la fonctionnalité TLS

  • # openopenssl

    Posté par  . Évalué à 10.

    Ils ont dit: SSH, ça va pas, on va faire openssh
    smtpd, non, ça va pas, on va faire opensmtpd
    et si openssl va pas, ils vont appeler ça openopenSSL?

    • [^] # Re: openopenssl

      Posté par  . Évalué à 10.

      On peut espérer que ce sera plutôt openTLS :)

      • [^] # Re: openopenssl

        Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 15 avril 2014 à 15:33.

        LibreSSL, pour faire le pendant à OpenOffice / LibreOffice.

      • [^] # Re: openopenssl

        Posté par  . Évalué à 4.

        Y a aussi de gros problèmes avec GnuTLS ?

        • [^] # Re: openopenssl

          Posté par  . Évalué à 8.

          Pour faire simple, TLS regroupe les versions modernes de SSL. GnuTLS et OpenSSL travaillent sur les même protocoles, mais tant qu'à sortir un nouveau projet autant utiliser le nom TLS plutôt que SSL.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Heartbleed

    Posté par  . Évalué à 10.

    La fonctionnalité s'appelle Heartbeat, heartbleed, c'est le nom de la faille.

    Sinon, s'ils doivent maintenir une libssl en parallèle, leur charge de travail ne va pas diminuer. Mais peut-être que depuis qu'ils ont laisser tomber leur Apache, ils sont en manque de fork à maintenir.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Heartbleed

      Posté par  . Évalué à 2. Dernière modification le 15 avril 2014 à 15:23.

      La fonctionnalité s'appelle Heartbeat, heartbleed, c'est le nom de la faille.

      Très juste ! :)

      Edit : d'ailleurs, si un gentil modérateur peut corriger…

      • [^] # Re: Heartbleed

        Posté par  . Évalué à 3.

        C'est fait.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # GitHub

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    On constate aussi pas mal d'activité sur GitHub, avec pas mal d'issues.

    • [^] # Please Put OpenSSL Out of Its Misery

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Et sur le même sujet, lire Please Put OpenSSL Out of Its Misery de PHK (en anglais).

      • [^] # Re: Please Put OpenSSL Out of Its Misery

        Posté par  . Évalué à 4.

        Je trouve que le titre de son message est mal choisi car il ne flingue pas que OpenSSL: il y a les CAs aussi dans le lot..
        Ce qui est amusant, c'est que ça fait pas mal de temps que je lis que nos mécanismes de sécurité sont ridicules, mais on ne se réveille qu'avec Heartbleed mais bon je ne suis pas optimiste: l'attention semble se focaliser sur l'implémentation alors que n'importe quel CA peut te trahir..

        • [^] # Re: Please Put OpenSSL Out of Its Misery

          Posté par  (site web personnel) . Évalué à -2.

          Les CA sont un autre problème, non technique, tu peux virer tous les CA en qui tu n'as pas confiance.
          Et les malins qui disent qu'il faut virer ces salauds de CA ne disent toujours pas par quoi les remplacer de manière utilisable par les non geeks (qui ne sont pas fan de signing parties par exemple)

          • [^] # Re: Please Put OpenSSL Out of Its Misery

            Posté par  (site web personnel) . Évalué à 10.

            Tu n'as toujours pas compris le problème donc… Tu peux virer toutes les CA du monde de ton navigateur, ça n'empêchera aucune d'elle de faire un faux certificat pour ton domaine, qui sera accepté par tout le reste du monde.

            • [^] # Re: Please Put OpenSSL Out of Its Misery

              Posté par  (site web personnel) . Évalué à -5. Dernière modification le 15 avril 2014 à 20:44.

              J'ai compris le problème, merci.
              Je pense à mon navigateur, pas aux navigateurs des autres qui veulent faire confiance à des mauvais CA (c'est leur problème). Tout le reste du monde dans ta phrase est surtout le reste du monde qui veut faire confiance à n'importe qui. un CA, c'est bien une chaine de confiance, toute la chaine, rien de nouveau.

              Après, on peut éviter de jeter le bébé avec l'eau du bain et limiter ce genre de problème par des changements mineurs (des CA limité par TLD etc…), et quitte à me répéter pour le moment beaucoup de critiques, et pas de contre-proposition (viable c'et à dire vraiment utilisable par des non linuxiens geeks adorateurs de GPG, évidement. Il y en a qui pensent à DNSSEC si j'ai bien compris, mais c'est loin d'être acquis et c'est complexe), tu te gardes bien toi-même de dire qu'il y a mieux : les CA, c'est comme la démocratie, c'est ce qu'il y a de pire à l'exception de tout le reste (mais avec les CA, on peut espérer quand qu'un jour on trouvera mieux)

              • [^] # Re: Please Put OpenSSL Out of Its Misery

                Posté par  . Évalué à 10.

                Je ne comprends pas comment tu peux à deux posts d’intervalle ① réclamer quelque chose d’utilisable par les « non geeks » et ② dire aux mêmes non-geeks que c’est leur problème s’ils font aveuglément confiance aux CA de leur navigateur. Qui à part un geek peut savoir ce qu’est une « CA », et a fortiori trier les bonnes CA des mauvaises CA ?

                • [^] # Re: Please Put OpenSSL Out of Its Misery

                  Posté par  . Évalué à 3.

                  La chaîne de confiance se propage au-delà des CA : l'internaute fait confiance à l'éditeur de son navigateur qui fait confiance à un ensemble de CA.

                  BeOS le faisait il y a 20 ans !

                • [^] # Re: Please Put OpenSSL Out of Its Misery

                  Posté par  (site web personnel) . Évalué à 3.

                  Je ne comprends pas comment tu peux à deux posts d’intervalle ① réclamer quelque chose d’utilisable par les « non geeks » et ② dire aux mêmes non-geeks que c’est leur problème

                  Parce que Zenitram est fortement individualiste, et qu’il aime bien pour lui-même ce qui est utilisable par les non-geeks. ;-)

                  ce commentaire est sous licence cc by 4 et précédentes

                  • [^] # Re: Please Put OpenSSL Out of Its Misery

                    Posté par  . Évalué à 7.

                    Parce que Zenitram est fortement individualiste

                    On dit « il est dans sa tour d'ivoire »

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Please Put OpenSSL Out of Its Misery

                Posté par  . Évalué à 2.

                J'ai une contre-proposition : GPG bien sûr :)) Mais effectivement, tout comme remplacer MS Office par LibreOffice, ça demande un peu de travail en l'état.

                Avec GPG, tu peux retrouver le fonctionnement comme avec les CA, et ça ajoute des possibilités, comme la validation d'un certificat par plusieurs CA, donc tu devrais être assez satisfait de ce côté.

                Niveau utilisation, effectivement ça pêche un peu, mais pas forcément plus que S-MIME. Idéalement, il faut une solution qui permettent de multiple usages : login sur la machine, login sur des sites web, chiffrement et signature des emails… Pour le moment ça existe du côté de S-MIME, et c'est déployé dans certaines organisations. Pour GPG, il y a encore du chemin à faire de ce côté…
                Enfin le fait que ça soit peu répandu joue très largement en défaveur de GPG. Dans un environnement où tout le monde utilise des certificats GPG, il est nettement plus facile d'utiliser GPG. Cette critique est aussi vraie pour S-MIME entre autre.

                Donc sur le papier, GPG me semble pas si déconnant, dans la vraie vie, c'est compliqué, mais c'est aussi à nous admin sys et développeur de faire en sorte que ça se passe bien, pour le démocratiser. Si déjà les gens sentaient le besoin de signer et chiffrer, ça serait déjà un pas de géant.

              • [^] # Re: Please Put OpenSSL Out of Its Misery

                Posté par  . Évalué à 6.

                Il y en a qui pensent à DNSSEC si j'ai bien compris, mais c'est loin d'être acquis et c'est complexe)

                Oui, c’est le cas notamment de DANE, DNS-based authentication of named entities. C’est ce qu’il y a de plus prometteur d’après moi et ce n’est pas, en soi, très compliqué. Côté utilisateur en particulier, c’est même encore plus simple que le système actuel des CA, puisque l’utilisateur n’a besoin de faire confiance que dans le DNS (ce qu’il fait déjà pour la résolution du nom de toute façon) et non pas dans des CA tierces dont il ignore tout.¹

                Le gros problème de DANE, c’est que ce n’est fiable qu’au-dessus de DNSSEC, qui lui est en effet complexe, pas encore très déployé côté serveur (sur tous les sites que je fréquente habituellement, je n’en connais qu’un seul dont le domaine soit signé), et encore très mal supporté côté client…

                ¹ À noter toutefois que DANE peut aussi, à la discrétion de l’administrateur, s’utiliser en complément du système des CA et non pas uniquement en remplacement de celui-ci.

                • [^] # Re: Please Put OpenSSL Out of Its Misery

                  Posté par  (site web personnel) . Évalué à 3.

                  Oui, c’est le cas notamment de DANE

                  Je pensais à lui (mais ne me rappelais plus le nom)

                  au-dessus de DNSSEC, qui lui est en effet complexe,

                  D'où la complexité :(.
                  DNSSEC a l'air d'être l'enfer pour pas mal d'admin, espérons que l'avenir apportera plus de facilité pour les "admins du dimanche" afin de virer les CA. Mais pour le moment, point de choix…

                  • [^] # Re: Please Put OpenSSL Out of Its Misery

                    Posté par  . Évalué à 4.

                    espérons que l'avenir apportera plus de facilité pour les "admins du dimanche"

                    Parfois c’est déjà le cas. Je suis un « admin du dimanche », mais mon domaine est signé. Comment ai-je fait ? J’ai cliqué sur le bouton « Enable DNSSEC » dans l’interface de configuration de mon hébergeur…

                    Alors certes, DNSSEC est complexe, mais je pense que son faible déploiement s’explique aussi par un certain laxisme.

                    • [^] # Re: Please Put OpenSSL Out of Its Misery

                      Posté par  (site web personnel) . Évalué à 5.

                      Je suis un « admin du dimanche »,

                      Pas dans ce cas : ici, tu es simple utilisateur d'une interface faite par d'autres, sur leur infrastructure.
                      Si je pouvais faire pareil avec mon propre Bind (mon hebergeur me propose bien de gérer le DNS, mais il ne fait pas tout ce que je veux faire avec mon DNS) avec un paramètre de config, sans me prendre la tête, je le ferai de suite.

                      • [^] # Re: Please Put OpenSSL Out of Its Misery

                        Posté par  . Évalué à 5.

                        Et là, je te conseille le soft OpenDNSSEC qui se charge tout seul de faire la signature de ta zone et la rotation des clés (et en prime, il peut relancer le serveur DNS pour recharger la nouvelle zone signée).

                        Il y a un chouette article de Stéphane Bortzmeyer sur son utilisation avec NSD si tu n'utilises pas BIND.

                    • [^] # Re: Please Put OpenSSL Out of Its Misery

                      Posté par  . Évalué à 1.

                      Parfois c’est déjà le cas. Je suis un « admin du dimanche », mais mon domaine est signé. Comment ai-je fait ? J’ai cliqué sur le bouton « Enable DNSSEC » dans l’interface de configuration de mon hébergeur…

                      Tiens, ça m’intéresse. Quel hébergeur permet de faire ça ?

                      Je suis chez Gandi, qui n'a pas l'air de permettre le DNSSEC sans configurer un serveur bind chez soi.

                      • [^] # Re: Please Put OpenSSL Out of Its Misery

                        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 16 avril 2014 à 00:21.

                        L'option est disponible dans l'outil de gestion chez OVH (que je n'ai pas encore testé…).

                        http://guides.ovh.net/dnssec

                        C'est un peu plus complexe qu'un simple bouton "j'active DNSSEC" mais ça à le mérite d'exister.

                        • [^] # Re: Please Put OpenSSL Out of Its Misery

                          Posté par  . Évalué à 2.

                          http://guides.ovh.net/dnssec

                          Ça, c’est le guide pour ceux qui gèrent eux-même leur zone DNS avec leur propre serveur (cas de Zenitram apparemment), et qui voudraient ajouter le support de DNSSEC.

                          Mais pour ceux dont la zone DNS est servie par les serveurs d’OVH (c’est mon cas, parce que je ne me sens pas assez confiant pour gérer le DNS moi-même, encore moins DNSSEC — comme je disais, « admin du dimanche »…), j’insiste, la seule chose à faire est de cliquer sur « Enable DNSSEC ».

                          • [^] # Re: Please Put OpenSSL Out of Its Misery

                            Posté par  . Évalué à 5.

                            Devoir passer par l'interface graphique pour changer les clefs, ce n'est vraiment pas pratique. Sachant qu'on conseille de changer les clef DNSSEC tous les 15 jours pour éviter les attaques par rejeu.

                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Please Put OpenSSL Out of Its Misery

                  Posté par  . Évalué à 4.

                  puisque l’utilisateur n’a besoin de faire confiance que dans le DNS (ce qu’il fait déjà pour la résolution du nom de toute façon)

                  Ben justement, les certificats permettent justement de ne pas faire confiance dans le DNS. Dans la théorie, du moins. Si ton DNS te dit d'aller sur une machine du gouvernement Bordure pour https://facebook.com/ tu arrives sur cette adresse sur la mauvaise machine, mais le certificat n'est pas signé par une autorité dans laquelle tu as confiance puisque le gouvernement Bordure n'a pas de CA reconnue par les navigateur chez lui. (il est con ce gouvernement, vu le nombre d'autres qui en ont…)

                  Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                  • [^] # Re: Please Put OpenSSL Out of Its Misery

                    Posté par  . Évalué à 7.

                    Sauf que la clef DANE doit être signé via DNSSEC et ce gouvernement n'aura pas la clef du .com pour faire signer facebook.com (par contre, il pourra signer le .bordure mais au moins, ça restreint la surface d'attaque par rapport au fait d'avoir une CA dans les navigateurs).

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Please Put OpenSSL Out of Its Misery

            Posté par  (site web personnel) . Évalué à 10.

            pas fan de signing parties par exemple)

            Ce qui est dommage c'est que nous faisons des signing parties tout au long de l'année, à la banque, au boulot, dans les administrations etc. Y'aurait moyen de construire un sacré reseau de confiance avec ça, si nous échangions autre chose que des gribouillis sur une feuille de papier.

        • [^] # Re: Please Put OpenSSL Out of Its Misery

          Posté par  (site web personnel) . Évalué à 4.

          CA ?

          La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

        • [^] # Re: Please Put OpenSSL Out of Its Misery

          Posté par  (site web personnel) . Évalué à 7.

          Ce qui est amusant, c'est que ça fait pas mal de temps que je lis que nos mécanismes de sécurité sont ridicules, mais on ne se réveille qu'avec Heartbleed

          Comme toujours, et ce dans tous les domaines, c'est à la suite d'une catastrophe que les parties prenantes se décident à agir sur un problème, connu de longue date. Mais vu que ça marchottait plus ou moins depuis longtemps, l'urgence ne s'imposait pas à ceux en charge du projet, et ce en dépit des quelques personnes ayant tiré la sonnette d'alarme depuis parfois plusieurs années.

          C'est, je pense, inhérent à l'être humain, et c'est pourquoi ce schéma s'est produit dans le passé, ce passe aujourd'hui avec heartbleed et se reproduira…

  • # heartbeat

    Posté par  . Évalué à 4.

    Pourquoi supprimer cette fonctionnalité ? Elle a pas été corrigé, justement ?

    • [^] # Re: heartbeat

      Posté par  . Évalué à 8.

      Si elle n'a pas d'utilité autant limiter la surface d'attaque, je présume.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: heartbeat

        Posté par  (site web personnel) . Évalué à -10.

        Si elle n'a pas d'utilité autant limiter la surface d'attaque, je présume.

        Si elle n'a pas d'utilité, pourquoi alors une personne l'a développée?
        pas assez* d'utilité peut-être, mais c'est un peu facile de parler de "pas d'utilité".

        • [^] # Re: heartbeat

          Posté par  . Évalué à 10.

          D'où le fait que ce soit une condition et pas une affirmation (tu as vu le « Si » en début de phrase ?).

          J'aurais en effet pus être plus exhaustif :

          Si :

          • elle n'a plus d'utilité aujourd'hui
          • elle est optionnelle dans le protocole
          • elle n'a pas assez d'utilité
          • elle n'est utile que dans certains cas bien particulier suffisamment rare pour rendre son ajout uniquement à la compilation peu gênant
          • elle n'a vraiment pas d'utilité et la fonctionnalité même est un bug
          • …

          Mais je vois pas l'utilité de chercher ce genre de petite bête vu que ni toi ni moi n'y comprenons rien.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: heartbeat

            Posté par  . Évalué à 2.

            Mais je vois pas assez l'utilité de chercher ce genre de petite bête vu que ni toi ni moi n'y comprenons rien.

            Fixed.

      • [^] # Re: heartbeat

        Posté par  . Évalué à 2.

        Comment on sait qu'elle n'est pas utile ?

        • [^] # Re: heartbeat

          Posté par  . Évalué à 4.

          On étudie le protocole ?
          On fait des études statistiques de l'utilisation de cette fonction ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: heartbeat

      Posté par  (site web personnel) . Évalué à 5.

      Simplement parce que ce sont des devs de gnome licenciés récemment pour raison économique qui ont pris en main ce fork !

  • # Code inutile

    Posté par  . Évalué à 4.

    Du code qui peut paraître inutile au premier coup d'oeil, cela peut avoir des conséquences désastreuses de l'enlever. Par exemple des timing attacks. http://users.ece.cmu.edu/~dbrumley/courses/18732-f11/slides/1031_openssl-timing.pdf

    J'espère que ces gens savent ce qu'ils font.

    • [^] # Re: Code inutile

      Posté par  . Évalué à 10.

      J'espère que ces gens savent ce qu'ils font.

      On a tendance à croire que oui quand il s'agit des hackers d'OpenBSD.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Code inutile

        Posté par  (site web personnel) . Évalué à -3.

        Je tendance à ne croire personne quand les choses sont faites sous le coup de l'émotion, voire je me méfie même de leur version.

        • [^] # Re: Code inutile

          Posté par  . Évalué à 10.

          C'est probablement plutôt la goutte d'eau qui les a poussé à s'y mettre. Je crois que leur critique est antérieur a cette faille. Par exemple ils ont déjà fait des coupes dans OpenSSL et ont réécrit certaines parties comme le traitement de ASN.1 par exemple.

          Donc affirmer que c'est fait sur le coup de l'émotion c'est à mon avis présomptueux.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Code inutile

            Posté par  (site web personnel) . Évalué à 8.

            C'est quand même dommage de devoir réécrire tout OpenSSL quand on peut utiliser GnuTLS non ?

            • [^] # Re: Code inutile

              Posté par  . Évalué à 9.

              Deja il y a GNU dans le nom donc ca va pas etre possible chez xBSD et je ne parle meme pas des trolls sur la licence (LGPL). Rien que le nom semble donner de l'urticaire a certains bsdiste :)

            • [^] # Re: Code inutile

              Posté par  . Évalué à 6.

              J'en ai pas la moindre idée. Je ne sais pas s'il vaut mieux avoir de multiples implémentation pour réduire l'impact d'une faille sur l'une d'elle ou s'il vaut mieux bosser sur une seule implémentation que l'on essaie de blinder au maximum. Après il est certain que GnuTLS a une licence qui le rend incompatible avec pas mal de projets. Si OpenBSD crée un fork d'OpenSSL (je crois que ce n'est pas encore acté), tous les utilisateurs d'OpenSSL peuvent passer à ce fork, contrairement à GnuTLS.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Code inutile

              Posté par  . Évalué à 1.

              GnuTLS ?

              Celui la : http://www.zdnet.com/goto-apple-gnutls-falls-foul-of-ssl-certificate-verification-issues-7000026957/ ?

              Pas sur que ce soit mieux qu'OpenSSL…

              • [^] # Re: Code inutile

                Posté par  . Évalué à 2.

                Alors que c'est vrai que chez de Microsoft, il n'y a aucun problème…

                C'est pas vraiment mieux chez Apple.

                Il y a un moment où faut éviter de se la jouer parce qu'il y en a pas un qui se démarque. Au lieu d'essayer de rouler des mécaniques et de se croire plus malin que les autres, ça peut être bien de se montrer plus humble, non ?

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Code inutile

                  Posté par  (site web personnel) . Évalué à 1.

                  Il y a un moment où faut éviter de se la jouer parce qu'il y en a pas un qui se démarque.

                  Il se la joue de quoi? une personne parle de B pour remplacer A, il dit juste que B n'est pas mieux que A.
                  Il ne dit rien sur C et D, seul toi en parle.

                  Au lieu d'essayer de rouler des mécaniques

                  Ca tombe bien, il ne l'a pas fait!
                  Ca fait procès d'intention la…

                  • [^] # Re: Code inutile

                    Posté par  . Évalué à 6.

                    Tu as raison, je suis parti un peu vite.

                    Mais dans l'idée, les seules bibliothèques qui n'ont pas de CVE sont celles qui ne sont pas utilisée, je ne crois pas que que ce soit la découverte d'une faille ou d'une autre qui permet de comparer les biblio entre elle.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Code inutile

                      Posté par  (site web personnel) . Évalué à 1.

                      Tu as raison

                      Je note, je note ;-)

                      es seules bibliothèques qui n'ont pas de CVE sont celles qui ne sont pas utilisée,

                      Oui, mais la du coup tu attaques au passage le fork d'OpenSSL "parce qu'il y a un CVE dessus" ;-)

                      Bref, au final on constate que toutes les libs utilisées ont des CVE, et ce n'est pas parce que les mecs d'OpenBSD se pointent en forkant à chaud à cause d'un CVE qu'ils vont être meilleurs (après, si leur fork est autant utilisé qu leur distro, ça va être facile de dire qu'il sont meilleurs vu que personne n'aura eu envie de fouiller). C'est eux que tu devrais attauqer sur le côté humble ;-).

                      • [^] # Re: Code inutile

                        Posté par  . Évalué à 10.

                        après, si leur fork est autant utilisé qu leur distro, ça va être facile de dire qu'il sont meilleurs vu que personne n'aura eu envie de fouiller

                        Alors que s'il est aussi utilisé que leur serveur SSH, on va arrêter de les prendre de haut.

                        Personnellement je n'ai pas dis grand chose, mais il semble que les développeurs d'OpenBSD ont plusieurs griefs contre openssl depuis quelques temps (l'histoire d'ASN a plus de 10 ans). J'attends de voir avant de juger.

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Code inutile

                  Posté par  . Évalué à 9. Dernière modification le 16 avril 2014 à 01:05.

                  Je faisais pas de comparaison avec MS, simplement entre OpenSSL et GnuTLS…

                  Mais vu que tu parles de ces 2 (2 parce que les liens sous "Alors" et "probleme" pointent sur la meme vulnerabilite & patch) vulnerabilites, tu remarqueras que les 2 que tu cites sont des vulnerabilites dans le protocole lui-meme, pas dans l'implementation que MS a faite. A peu pres tout le monde etait vulnerable :

                  http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555

                  The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl in the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier, multiple Cisco products, and other products, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions

                  http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389

                  The SSL protocol, as used in certain configurations in Microsoft Windows and Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Opera, and other products, encrypts data by using CBC mode with chained initialization vectors, which allows man-in-the-middle attackers to obtain plaintext HTTP headers via a blockwise chosen-boundary attack

                  Ce dernier n'est d'ailleurs pas une faille de SSL lui-meme, mais une faiblesse dans l'utilisation qui en est faite car les gens se sont rendu compte que CBC est pourri.

                  C'est une sacre difference compare aux failles recentes d'Apple, GnuTLS et OpenSSL ou les vulnerabilites etaient dues a des erreurs dans l'implementation par les devs et le QA qui n'a pas trouve le probleme.

              • [^] # Re: Code inutile

                Posté par  (site web personnel) . Évalué à 8. Dernière modification le 16 avril 2014 à 18:18.

                GnuTLS ?
                Pas sur que ce soit mieux qu'OpenSSL…

                Ben si. Des bugs il y en a dans tous les logiciels, même les mieux écrits et les plus scrutés (par exemple OpenSSH).
                Le problème spécifique d'OpenSSL c'est que d'après les spécialiste qui ont regardé son code source c'est une horreur sans nom, une abomination absolue (cf les divers articles à ce sujet).
                Donc même si GnuTLS a déjà eu des bugs (et, encore une fois, quel logiciel n'en a pas ?), ce serait quand même un immense progrès que de jeter OpenSSL et de le remplacer par GnuTLS. D'autant plus que la LGPL est assez permissive.

                • [^] # Re: Code inutile

                  Posté par  . Évalué à 10.

                  Ah ca oui, le code est une horreur, je confirme a 100%, tout comme la doc.

                  Maintenant, GnuTLS est utilise par tres peu de gros softs, le jour ou il remplace OpenSSL et qu'il est sous les feux de la rampe, qu'est ce qui nous dit qu'il fera mieux qu'une lib qui est en premiere ligne depuis longtemps et qui donc a ete auscultee depuis longtemps ?

                  • [^] # Re: Code inutile

                    Posté par  . Évalué à 5.

                    ça a GNU dan le nom, c'est automatiquement meilleur.

                    Depending on the time of day, the French go either way.

                  • [^] # Re: Code inutile

                    Posté par  (site web personnel) . Évalué à 2.

                    GnuTLS est utilise par tres peu de gros softs

                    D'après l'article Wikipedia il y a au moins GNOME, Exim, Mutt, wireshark et CUPS. Loin d'être négligeable donc.
                    Et si je regarde les dépendances inverses du paquet libgnutls26 sur ma Xubuntu j'ai ça :

                    patrick@laptop:~$ apt-cache rdepends libgnutls26
libgnutls26
Reverse Depends:
  libvirt0
  libvirt-bin
  libgnutls26:i386
  libgnutls26:i386
  xen-utils-4.3
  mutt-patched
  libavformat-extra-53
  chromium-browser
  qemu-system-x86
  qemu-system-sparc
  qemu-system-ppc
  qemu-system-misc
  qemu-system-mips
  qemu-system-arm
  mutt
  libvirt0
  libvirt-bin
  libgnutlsxx27
  libgnutls26-dbg
  libgnutls-openssl27
  libgnutls-dev
  libgadu3
  libcurl3-gnutls
  libcups2
  libavformat53
  gnutls-bin
  glib-networking
  empathy
  cups-daemon
  libgnutls26:i386
  libgnutls26:i386
  libgcrypt11:i386
  xxxterm
  xfce4-mailwatch-plugin
  xen-utils-4.3
  wzdftpd
  wmbiff
  wine1.4-amd64
  weechat-plugins
  weechat-curses
  weechat-core
  webfs
  vpnc
  vlc-nox
  sogo
  shishi-kdc
  scrollz
  rsyslog-gnutls
  qutim
  python-gnutls
  proxytunnel
  prelude-manager
  postal
  plasma-widget-mail
  pianobar
  pacemaker-remote
  pacemaker-mgmt-client
  pacemaker-mgmt
  openconnect
  nzbget
  nullmailer
  ngircd
  newsbeuter
  mutt-patched
  msmtp-gnome
  msmtp
  mpop-gnome
  mpop
  minbif
  mandos-client
  libyaz4
  libxmlsec1-gnutls
  libwireshark3
  libvmime0
  libucommon5
  libsope1
  libshishi0
  libpiano0
  libpam-pin
  libopenvasnasl2-dev
  libopenvasnasl2
  libopenvas2
  libopenconnect2
  libnussl1
  libnet6-1.3-0
  libmicrohttpd10
  libmailutils4
  libloudmouth1-0
  libinfinity-0.5-0
  libinfgtk3-0.5-0
  libiksemel3
  libgwenhywfar60
  libgnustep-base1.24
  libgloox8
  libggz2
  libgensec0
  libevd-0.1-0
  libetpan15
  libepc-1.0-3
  libeet1
  libecore-con1
  libavformat-extra-53
  libapache2-mod-gnutls
  kildclient
  kbtin
  jd
  ircd-ratbox
  inspircd
  infinoted
  gurlchecker
  gtk-gnutella
  gstreamer1.0-plugins-bad
  gsasl
  gnu-smalltalk
  gnomint
  gkrellm
  git-annex
  freetds-bin
  filezilla
  emacs24-lucid
  elinks-lite
  elinks
  ekg2-remote
  ekg2-jabber
  echoping
  dwb
  csync2
  connman
  claws-mail
  chromium-chromedriver
  chromium-browser
  centerim-utf8
  centerim-fribidi
  centerim
  bitlbee-libpurple
  bitlbee
  aria2
  anubis
  aiccu
  abiword
  vino
  telepathy-salut
  telepathy-gabble
  tdsodbc
  qemu-system-x86
  qemu-system-sparc
  qemu-system-ppc
  qemu-system-misc
  qemu-system-mips
  qemu-system-arm
  pacemaker
  ntfs-3g
  mutt
  lynx-cur
  libvncserver0
  libvirt0
  libvirt-bin
  libsybdb5
  librtmp0
  librelp0
  libprelude2
  libneon27-gnutls
  liblrmd1
  libldap-2.4-2
  libimobiledevice4
  libgvnc-1.0-0
  libgnutlsxx27
  libgnutls26-dbg
  libgnutls-openssl27
  libgnutls-dev
  libgnomevfs2-0
  libgcrypt11
  libgadu3
  libcurl3-gnutls
  libcups2
  libct4
  libcrmcommon3
  libcib3
  libavformat53
  lftp
  gnutls-bin
  glib-networking
  exim4-daemon-light
  exim4-daemon-heavy
  empathy
  emacs24-nox
  emacs24
  cups-daemon

                    • [^] # Re: Code inutile

                      Posté par  . Évalué à 10.

                      D'après l'article Wikipedia il y a au moins GNOME, Exim, Mutt, wireshark et CUPS. Loin d'être négligeable donc.

                      Euuuuhhh…. tu rigoles ? C'est RIEN

                      Comptes le nombre de gens qui utilisent ces softs. Multiplie le chiffre par 10.

                      Ensuites tu prends le resultat, et tu compares au nombre de gens qui directement ou indirectement utilisent OpenSSL a travers Apache.

                      Ah oui, Apache a plus d'utilisateurs (je parles des gens qui s'y connectent donc) que ces softs reunis fois 10.

                      Ensuite tu rajoutes tout ce qui utilisateurs de OpenVPN, MySQL, PostgreSQL, etc… et tu te rends comptes que GnuTLS est inexistant dans ce monde.

                      Maintenant tu es un chercheur en securite, tu compares les 2, dans lequel des 2 est-ce que trouver une faille aiderait ta renommee le plus ou te ferait le plus d'argent (en imaginant que tu es du cote obscur) ?

                      C'est comme sur le desktop, il faudrait etre stupide pour aller essayer de trouver des failles dans KDE plutot que dans le shell Windows a moins d'avoir un interet particulier pour KDE

                      • [^] # Re: Code inutile

                        Posté par  (site web personnel) . Évalué à 0.

                        Exim est le MTA par défaut de Debian. Je pense qu'il y a un certain nombre de serveurs Debian sur cette planète tu ne crois pas ?
                        CUPS est le système d'impression utilisé par tous les Unix et par Mac OSX. Il me semble que là aussi ça fait un sacré paquet de monde…

                        • [^] # Re: Code inutile

                          Posté par  . Évalué à 10.

                          Exim est le MTA par défaut de Debian. Je pense qu'il y a un certain nombre de serveurs Debian sur cette planète tu ne crois pas ?

                          Oui, ca ne veut pas dire qu'Exim est mis sur toutes ces installs ou est accessible.

                          CUPS est le système d'impression utilisé par tous les Unix et par Mac OSX. Il me semble que là aussi ça fait un sacré paquet de monde…

                          CUPS n'est utilise par quasiment personne en mode reseau (ou SSL serait utilise). Les seules personnes qui donnent a CUPS une base d'utilisateurs decente sont les Maceux, et peu d'entre eux ont une imprimante reseau car les Macs en entreprise c'est tres tres petit, surtout en cote serveur.

                          Faut quand meme revenir sur terre. Apache c'est la grosse majorite des serveurs web, MySQL c'est la grosse majorite des bases de donnees sur le web a mon avis, et il y a tout le reste encore.

                          • [^] # Re: Code inutile

                            Posté par  . Évalué à 3.

                            Apache c'est la grosse majorite des serveurs web

                            Tu peut déjà t'en servir avec GnuTLS à une époque (je ne sais pas si c'est toujours le cas), c'était la seule façon de faire du SNI.

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Code inutile

                      Posté par  . Évalué à 4.

                      GnuTLS est utilisé par OpenLDAP également.

                  • [^] # Re: Code inutile

                    Posté par  . Évalué à 7.

                    Sans chercher à remplacer, peut être que multiplier les implémentations serait tout de même bénéfique pour tout le monde, non ? Si les failles des implémentations ne se recoupent pas et que tu as 5 implémentations qui sont chacune utilisée dans environ 20 % des serveurs, une grosse faille à la con comme celle qui vient d'avoir ne touchera que 20 % des serveurs, c'est déjà un plus, non ?

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Code inutile

                      Posté par  . Évalué à 9.

                      C'est possible, dur a dire.

                      Tu multiplies la surface d'attaque, et donc les chances de trouver une faille, par 2, et tu divises (en imaginant que les utilisateurs sont proportionellement repartis) les victimes potentielles par 2.

                      Au final tu risques de te retrouver avec 5 failles touchant chacune 1/5eme de la population plutot qu'une faille touchant 100%

                      Mais evidemment, tout ca c'est des probabilites, a mon avis ca ne sera jamais possible car en software il y a une tendance a la selection d'un ou deux principaux joueurs.

                      • [^] # Re: Code inutile

                        Posté par  . Évalué à 4.

                        Tu multiplies la surface d'attaque, et donc les chances de trouver une faille, par 2, et tu divises (en imaginant que les utilisateurs sont proportionellement repartis) les victimes potentielles par 2.

                        C'est une façon un peu biaisé de regarder les choses pour chaque utilisateur tu ne modifie pas sa surface d'attaque, tu le place dans un groupe moins ciblé.

                        Au final tu risques de te retrouver avec 5 failles touchant chacune 1/5eme de la population plutot qu'une faille touchant 100%

                        On sait qu'actuellement on a des failles qui touchent 90% des utilisateurs. Il n'y a pas de mal à se tourner vers d'autres implémentations un peu moins utilisées.

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: Code inutile

                          Posté par  . Évalué à 7.

                          Ben ca depend du point de vue.

                          Chaque utilisateur ne sera pas exclusivement OpenSSL ou GnuTLS (ou autre). Selon le soft il sera l'un ou l'autre, selon le service qu'il utilise en ligne, ce sera l'un ou l'autre sur le serveur.

                          L'utilisateur se retrouvera lui-meme en partie avec une lib, en partie avec une autre.

                          Donc oui, tu multiplies la surface d'attaque, car tu peux attaquer l'utilisateur a travers 2 libs maintenant, et en meme temps tu reduis l'impact d'une attaque car seuls les softs/services utilisant la lib vulnerable sont touches.

                          • [^] # Re: Code inutile

                            Posté par  . Évalué à 3.

                            Hum tu as raison.

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Code inutile

        Posté par  . Évalué à 6.

        On a tendance à croire que oui quand il s'agit des hackers d'OpenBSD.

        Moi je ne sais pas si j'ai envie de faire confiance à des gens qui developpent encore en utilisant CVS :)

  • # En tout cas, ça avance

    Posté par  . Évalué à 1.

    250 commits en une semaine.
    Ils ne chôment pas chez OpenBSD.

    Source : http://undeadly.org/cgi?action=article&sid=20140418063443&mode=expanded&count=0

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.