Journal tor et la nsa

Posté par  . Licence CC By‑SA.
Étiquettes :
11
29
déc.
2014

Dans cet article du monde on apprend que certains protocoles ont été cassés par la NSA comme https et ssh mais qu'apparement TOR tiendrais toujours. Or Wikipedia dit que TOR lui meme serai financé par le gouvernement fédéral américain. http://fr.m.wikipedia.org/wiki/Tor_(réseau)#Financement

Comment pourraient t'il finnancer un outil qu'ils ne peuvent pas cracker ?

Cet autre article parle d'un document de Snowden qui dirai lui au contraire que TOR aurai été persé http://www.zataz.com/tor-pele-comme-un-oignon-par-la-nsa/#axzz3NJZJOodp

Qu'en pensez vous?

Je ne sais plus quoi penser.

  • # facile

    Posté par  . Évalué à -6.

    que si la NSA a developpé elle meme TOR, elle n'a pas besoin de le cracker pour savoir ce qui se passe dedans, elle a juste à utiliser sa clef.

  • # Seulement les connexions sortantes ?

    Posté par  . Évalué à 4.

    Je suppose qu'il faut faire la différence entre les connexions qui restent dans le réseau Tor et les connexions qui en sortent.

    Les connexions qui restent dans le réseau Tor sont, je pense, encore incassable (et devraient le rester si j'ai bien compris le fonctionnement). Cependant, les connexions qui en sortent sont vulnérables et ça ne m'étonne pas que des organisations avec beaucoup de pouvoir sont capable d'exploiter cela.

    D'ailleurs, le projet I2P est d'ailleurs conçu directement pour ne pas communiquer avec le réseau internet "classique", si j'ai compris, pour s'assurer que le tout fonctionne avec un maximum de sécurité.

    • [^] # Re: Seulement les connexions sortantes ?

      Posté par  . Évalué à 4.

      Y'a quelques années on pouvais accéder au net via I2P (à moins que je ne me trompe de projet), mais seulement via quelques nodes contrôlées directement par le staff du projet.

      En réseau complètement cloisonné d'internet, y'a freenet aussi.

    • [^] # Re: Seulement les connexions sortantes ?

      Posté par  . Évalué à 3.

      On peut sortir sur l'intenet via i2p qui fonctionne du coup un peu sur la même idée que tor. Il est d'ailleurs utilisé par la distribution Tails à cette fin. Cela dit, des failles de sécurités présentes dans i2p ont contraint l'équipe de tails à ne plus proposer i2p par défaut.

  • # Source de l'article du Monde

    Posté par  . Évalué à 2. Dernière modification le 29 décembre 2014 à 21:55.

    Pour ceux qui se demande l'article du monde, parle de cette conférence : Jacob Appelbaum: Reconstructing narratives - transparency in the service of justice.

    Pour TOR je pensait que justement la NSA et d'autres agences gouvernementales des USA l'utilisait.

    Edit : Changement du lien pour la vidéo vers celui du CCC.

  • # Compléments

    Posté par  . Évalué à 8.

    Tor présente certaines vulnérabilités qui ne sont pas cachées ; il suffit de lire le blog du projet tor pour s'en convaincre. La dernière en date parle d'une vulnérabilité au niveau des serveurs Directory authorities
    Pour ma part, j'ai une confiance totale dans le projet tor car bien que financer en partie par le gouvernement américain, le code est libre et donc beaucoup de gens peuvent regarder le code et c'est ce qui est fait. Autre point, tor est développé en partie par Jacob Appelbaum qui a régulièrement des problèmes avec les autorités américaines lorsqu'il passe la frontière (voir le livre d'Assange). Bref, le code est libre et ça semble une garantie suffisante pour vérifier que la NSA n'y a pas un accès caché (jusqu'à preuve du contraire).

    Concernant l'article du Monde, il ne fait que retranscrire l'article de Der Spiegel bien plus précis et complet. Par exemple, lemonde.fr indique que Tails résiste à la NSA alors que le Spiegel n'en parle pas … Même chose pour les connexions https « cassées ». Le Spiegel indique

    The intelligence services are particularly interested in the moment when a user types his or her password. By the end of 2012, the system was supposed to be able to "detect the presence of at least 100 password based encryption applications" in each instance some 20,000 times a month.

    For its part, Britain's GCHQ collects information about encryption using the TLS and SSL protocols—the protocols https connections are encrypted with—in a database called "FLYING PIG." The British spies produce weekly "trends reports" to catalog which services use the most SSL connections and save details about those connections. Sites like Facebook, Twitter, Hotmail, Yahoo and Apple's iCloud service top the charts, and the number of catalogued SSL connections for one week is in the many billions—for the top 40 sites alone.

    ce qui veut dire dans les grandes lignes que la NSA cherche à casser le chiffrement lors de l'envoi des mots de passe. De son côté le GCHQ recense quels sites utilisent le plus https. Bref, c'est pas comme si le https était inefficace. Bon cela dit, les données datent de courant 2012, donc on peut supposer qu'ils se sont améliorés depuis.

    Enfin pour finir, il faut quand même préciser que parmi les outils qui posent le plus de problèmes à la NSA, on trouve les logiciels libres suivants : PGP, les protocoles ZRTP, OTR ou encore feu TrueCrypt. Bref, c'est une belle preuve de la fiabilité de la sécurité offerte par le logiciel libre.

    • [^] # Re: Compléments

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

      Pour ma part, j'ai une confiance totale dans le projet tor car bien que financer en partie par le gouvernement américain, le code est libre et donc beaucoup de gens peuvent regarder le code et c'est ce qui est fait. Autre point, tor est développé en partie par Jacob Appelbaum qui a régulièrement des problèmes avec les autorités américaines lorsqu'il passe la frontière (voir le livre d'Assange). Bref, le code est libre et ça semble une garantie suffisante pour vérifier que la NSA n'y a pas un accès caché (jusqu'à preuve du contraire).

      Je pensais que la faille Shellshock présente depuis 20 ans dans un logiciel libre très populaire avait au moins permis d'arrêter ce raisonnement naïf sur la "garantie suffisante" qu'offre l'accès au code source. Ou alors c'est de l'ironie ?

      • [^] # Re: Compléments

        Posté par  . Évalué à 9.

        L'accès au code source, et des gens qui le lisent, c'est pas une garantie 100% fiable qu'il n'y a pas de backdoor, mais c'est le mieux que l'on puisse faire actuellement.

        Evidemment, si tu penses que Tor contient une backdoor qui permet à la NSA d'espioner tes connexions, tu peux ne pas l'utiliser. Dans ce cas la, il n'y a pas de backdoor, mais ils n'en ont pas besoin pour espioner ce que tu fais.

        Le problème de l'argument "l'accès au code source ne permet pas de prouver qu'il n'y a pas de backdoor", c'est que ca met au meme niveau un logiciel entierement libre et qui a été analysé par un tas de gens qui s'y connaissent, et un logiciel proprietaire bourré de spywares. Alors que la probabilité qu'il y ait une backdoor dans les 2 cas n'est pas du tout la meme.

        • [^] # Re: Compléments

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

          mais c'est le mieux que l'on puisse faire actuellement.

          Ca peut aussi donner l'effet inverse : un faux sentiment de sécurité.
          J'ai cité Shellshock mais on peut aussi prendre pour exemple Heartbleed : le code incriminé a été introduit par erreur sous la forme d'un patch, qui a pourtant été relu à l'époque. Et il a fallut là encore 2 ans pour qu'elle soit découverte, dans une brique logicielle pourtant critique d'un point de vue sécurité !
          Alors oui, des experts peuvent "contrôler" le code de logiciels libres, mais non seulement ils ne sont pas forcement efficace (cf. exemples précédents) mais ces experts peuvent avoir des intentions toutes aussi opposées (genre un expert de la NSA), et l'ouverture du code devient alors à double tranchant.

          c'est que ca met au meme niveau un logiciel entierement libre et qui a été analysé par un tas de gens qui s'y connaissent, et un logiciel proprietaire bourré de spywares.

          C'est du FUD pur et simple. Pour rappel beaucoup de bugs sont trouvés par des techniques (fuzzing, etc.) qui ne demande aucun accès au code source et qui s'applique très bien aux logiciels propriétaires.

          Je ne dis pas qu'il faut mieux faire du proprio, mais d'un point de vue sécurité, oui c'est pour moi au même niveau : on croit utiliser quelque chose en confiance alors qu'il faudrait être au moins aussi prudent qu'avec un logiciel propriétaire.

          • [^] # Re: Compléments

            Posté par  . Évalué à 8.

            C'est du FUD pur et simple. Pour rappel beaucoup de bugs sont trouvés par des techniques (fuzzing, etc.) qui ne demande aucun accès au code source et qui s'applique très bien aux logiciels propriétaires.

            Il est completement trivial d'ajouter une backdoor dans un programme proprietaire qui ne sera jamais trouvée par du fuzzing. Dans un programme open source, il faut faire un patch qui ajoute un bug subtile, en ésperant qu'il ne soit pas remarqué, ni corrigé lorsque le code change. C'est beaucoup moins trivial.

            C'est absolument pas comparable. Dans un cas on a un evenement heureusement assez rare, un bug critique qui n'a pas été reperé pendant plusieurs années. Dans l'autre, le dev du logiciel proprietaire peut rajouter une backdoor en 5 minutes dans n'importe quelle release sans que personne ne puisse le savoir.

            • [^] # Re: Compléments

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

              Il est completement trivial d'ajouter une backdoor dans un programme proprietaire qui ne sera jamais trouvée par du fuzzing. Dans un programme open source, il faut faire un patch qui ajoute un bug subtile, en ésperant qu'il ne soit pas remarqué, ni corrigé lorsque le code change. C'est beaucoup moins trivial.

              Je parlais de bug, pas de backdoor volontaire. Heartbleed et Shellshock sont des bugs, et ce ne sont que 2 exemples qui ont fait parler d'eux par leur criticité et la popularité des softs associés, à mon avis ils sont loin d'être rares.

              Dans un programme open source, il faut faire un patch qui ajoute un bug subtile, en ésperant qu'il ne soit pas remarqué, ni corrigé lorsque le code change. C'est beaucoup moins trivial.

              C'est pas trivial mais c'est sans doute pas plus dur que de chercher à corrompre une boîte de dev propriétaire pour qu'il intègre un backdoor (ils acceptent rarement les pull request :-)). Parcqu'un éditeur qui propose une brique aussi populaire que OpenSSH il a une image de marque à défendre, alors prendre le risque de s'aliener tous ses clients en cas de découverte, faut que le risque en vaille sacrément la chandelle. C'est possible que ca arrive mais c'est du même niveau de probabilité que de trouver un heartbleed ou un shellshock, qu'il soit volontaire ou non. Et qui dit bug critique, dit installation potentielle d'un backdoor par derrière, tout aussi invisible que dans ton logiciel proprio.

              Bref, pour moi il n'y a pas de meilleur ou pire en matière de sécurité, aucune des 2 approches (libre/proprio) n'apporte de garantie à l'utilisateur.

              • [^] # Re: Compléments

                Posté par  . Évalué à 8.

                C'est pas trivial mais c'est sans doute pas plus dur que de chercher à corrompre une boîte de dev propriétaire pour qu'il intègre un backdoor (ils acceptent rarement les pull request :-)). Parcqu'un éditeur qui propose une brique aussi populaire que OpenSSH il a une image de marque à défendre, alors prendre le risque de s'aliener tous ses clients en cas de découverte, faut que le risque en vaille sacrément la chandelle.

                Tu veux dire que par exemple une societé comme Sony ne prendrait jamais le risque de mettre un rootkit sur les CDs qu'elle vend ?

                Ou qu'un editeur de logiciel refuserait forcement d'ajouter une backdoor si la NSA le demandait ?

                Bref, pour moi il n'y a pas de meilleur ou pire en matière de sécurité, aucune des 2 approches (libre/proprio) n'apporte de garantie à l'utilisateur.

                Serieusement, il faut etre de mauvaise fois pour affirmer que c'est pareil. Je crois que ca ne sert à rien de continuer cette discussion.

                • [^] # Re: Compléments

                  Posté par  . Évalué à 0.

                  Ou qu'un editeur de logiciel refuserait forcement d'ajouter une backdoor si la NSA le demandait ?

                  Ca c'est une bonne question.

                  Combien de développeurs Linux bossent pour Redhat, Google, IBM, … déjà ?

                  Merci de nous confirmer toi-même ce que TImaniac dit.

                  • [^] # Re: Compléments

                    Posté par  . Évalué à 6.

                    Merci de nous confirmer toi-même ce que TImaniac dit.

                    Non, ce que TImaniac dit c'est qu'il n'y a aucune difference entre un logiciel open source ou proprietaire.

                    Et moi je dis que qu'il est beaucoup plus compliqué de cacher une backdoor dans du code open source que dans un logiciel proprietaire.

                    • [^] # Re: Compléments

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

                      Ce que tu dis es vrai, tu montres un avantage de l'open-source en matière de sécurité vis-à-vis des backdoors, mais tu occultes les inconvénients : participation ouverte (à tous, pas toujours de bonne intention), code ouvert facile à lire (mais celui qui trouve un bug est potentiellement un enemi), faux sentiment de sécurité vis-à-vis d'un code forcement expertisé (alors que dans les faits des failles béantes restent pendant des années).

                      Donc oui, même si les 2 modèles sont très différents, d'un point de vue sécurité il n'y a aucune différence : aucun n'apporte de garantie et il faut donc appliquer la même prudence aux 2.

                      • [^] # Re: Compléments

                        Posté par  . Évalué à 6.

                        participation ouverte (à tous, pas toujours de bonne intention)

                        Un code open source ne veut pas dire que tu dois accepter du code de n'importe qui. Ou meme en accepter tout cours.

                        Donc oui, même si les 2 modèles sont très différents, d'un point de vue sécurité il n'y a aucune différence : aucun n'apporte de garantie et il faut donc appliquer la même prudence aux 2.

                        Mais bien sur que si qu'il y a une difference. On ne peut jamais avoir une garantie à 100%, ca ne veut pas dire qu'il n'y a pas de difference.

                        Porter un casque en moto n'apporte pas de garantie qu'en cas d'accident, tout vas bien se passer. Je suppose que tu en conclus que d'un point de vue sécurité il n'y a aucune différence entre porter un casque ou ne pas en porter ?

                        • [^] # Re: Compléments

                          Posté par  . Évalué à 0.

                          Un code open source ne veut pas dire que tu dois accepter du code de n'importe qui. Ou meme en accepter tout cours.

                          Un code proprio ne veut pas dire que tu vas mettre des backdoors dedans.

                          Mais bien sur que si qu'il y a une difference. On ne peut jamais avoir une garantie à 100%, ca ne veut pas dire qu'il n'y a pas de difference.

                          C'est quoi la différence alors ? Faire un code open source sans accepter de changement ? Ca laisse toujours la porte ouverte à l'auteur d'y insèrer ses backdoors, comme un auteur proprio.

                          Et en pratique, dans la vraie vie, combien de projets ayant une valeur sont dans ce cas ? Linux ? Apache ? OpenOffice ? KDE ? Gnome ? … Ah oui, aucun.

                    • [^] # Re: Compléments

                      Posté par  . Évalué à -4.

                      "beaucoup plus complique" ?

                      Vraiment ?

                      Si moi demain, je veux insérer une backdoor dans Linux, je peux. J'envoies qqe patches qui sont bien, je gagnes la confiance, et au bout d'un moment j'insères ma backdoor discrètement. Au pire, les gens la verront, croiront que c'est un bug innocent, je réessaierai un peu plus tard et je finirai par y arriver.

                      Si je veux aller insèrer une backdoor dans iOS ou Windows par contre, ah ben merde, j'ai pas accès… Seule la société elle-même peut le faire.

                      Ces 2 phrases sont vraies pour n'importe qui. Moi, toi, TImaniac, ta grand-mère, …

                      Eh oui, il n'est pas si évident que ce soit plus simple d'un coté que de l'autre.

                      • [^] # Re: Compléments

                        Posté par  . Évalué à 3.

                        Si je veux aller insèrer une backdoor dans iOS ou Windows par contre, ah ben merde, j'ai pas accès… Seule la société elle-même peut le faire.

                        À l'inverse, la NSA pourrait tirer profit de ses connexions bien connues avec Microsoft pour faire insérer une backdoor avec beaucoup plus de facilité dans le code propriétaire que dans un code libre. La faille insérée ayant une visibilité bien moindre qu'avec un code source public, ça sera beaucoup plus difficile de l'attribuer à la NSA.

                        • [^] # Re: Compléments

                          Posté par  . Évalué à -3.

                          Probablement. Richard de la NSA fera ça car Michael de la NSA est déjà occupé à faire de même avec Redhat.

                          • [^] # Re: Compléments

                            Posté par  . Évalué à 2.

                            Si ce n'est que RedHat donne ses sources, donc la backdoor doit être plus subtile.

                            • [^] # Re: Compléments

                              Posté par  . Évalué à 0.

                              Pas forcèment plus qu'en interne à la boite, car oh grande nouvelle, plusieurs personnes lisent le même code en interne aussi, et tout le monde n'est pas employé par la NSA.

                      • [^] # Re: Compléments

                        Posté par  . Évalué à 6.

                        Si moi demain, je veux insérer une backdoor dans Linux, je peux. J'envoies qqe patches qui sont bien, je gagnes la confiance, et au bout d'un moment j'insères ma backdoor discrètement. Au pire, les gens la verront, croiront que c'est un bug innocent, je réessaierai un peu plus tard et je finirai par y arriver.

                        Si je veux aller insèrer une backdoor dans iOS ou Windows par contre, ah ben merde, j'ai pas accès… Seule la société elle-même peut le faire.

                        Ah ? Et pourtant avec exactement le même modèle qu'au dessus, je peux le faire.
                        - Un temps de préparation équivalent à "j'envoie quelque patchs qui font gagner la confiance", c'est "j'envoie un CV cohérent qui montre mon expérience, je me fais engager, je reste un moment à faire du code utile"
                        - Un temps "j'insère ma backdoor", c'est "j'insère ma back door".
                        - au pire, les gens de la boite la verront, croiront que c'est un bug innocent, je réessaierais un peu plus tard et je finirai par y arriver.

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

                        • [^] # Re: Compléments

                          Posté par  . Évalué à -1.

                          Tout a fait, c'est possible, c'est par contre légèrement plus complique que ce que tu écris :

                          • Faut qu'il y ait un poste disponible la ou tu veux mettre la backdoor. Te faire engager dans le team marketing ou vente ça va pas aider
                          • Faut que tu passes l'interview quand même
                          • Faudra que tu insères la backdoor dans la partie de code qui t'es assignée point de vue boulot, sinon ça va amener des questions…
                          • T'as typiquement un background check dans nombre de boites, et ça force le fait que la personne qui est engagée soit un développeur, tu peux pas envoyer n'importe quel agent de terrain. En remote c'est évidemment plus facile car pas d'interactions face à face et 8h par jour.

                          Bref, la barre est quand même plus élevée qu'apparaître de nulle part et envoyer des patchs à un projet.

                          • [^] # Re: Compléments

                            Posté par  . Évalué à 2.

                            Faut que tu passes l'interview quand même
                            et ça force le fait que la personne qui est engagée soit un développeur,
                            Tout ça c'est facile, vu que la NSA recrute pas mal d'informaticiens et des plutôt pas mauvais. Aux USA, être passé par les services d'espionnage est un gros plus sur le CV.

                            • [^] # Re: Compléments

                              Posté par  . Évalué à 0.

                              Façile ? Non justement. La force de la NSA ce sont ces informaticiens, leur spécialité est tout ce qui est technique. Des gars derrière leur écran, dans les bureaux de la NSA.

                              Se faire passer pour quelqu'un d'autre en public, mentir de manière efficace pendant des semaines et des mois, … devant des gens, c'est pas forcément leur spécialité.

              • [^] # Re: Compléments

                Posté par  . Évalué à 7.

                Je parlais de bug, pas de backdoor volontaire. Heartbleed et Shellshock sont des bugs
                Euh, le principe numéro 1 du gars qui voudrait mettre une backdoor dans un programme à sources ouvertes serait qu'elle passe pour un bug… La NSA aurait voulu pourrir OpenSSL qu'elle ne s'y serait pas prise autrement !

            • [^] # Re: Compléments

              Posté par  . Évalué à -2.

              C'est absolument pas comparable. Dans un cas on a un evenement heureusement assez rare, un bug critique qui n'a pas été reperé pendant plusieurs années. Dans l'autre, le dev du logiciel proprietaire peut rajouter une backdoor en 5 minutes dans n'importe quelle release sans que personne ne puisse le savoir.

              Tu me fais bien marrer. Qu'est ce qui te dit que ce bug Shellshock n'était pas une backdoor ? Tu n'en sais absolument rien. Tu t'amuses à assumer que n'importe quelle vulnérabilité trouvée dans un soft libre est juste ça : une vulnérabilité innocente, alors que tu mets le doute sur le proprio, on va dire que c'est sacrément gonflé.

              Dans l'autre, le dev du logiciel proprietaire peut rajouter une backdoor en 5 minutes dans n'importe quelle release sans que personne ne puisse le savoir.

              Ca doit bien être pour ça que plein de backdoor ont été trouvées dans divers produits (firmwares de routeurs notamment) ? Ah ben non, visiblement elles se trouvent, même dans du code binaire.

              • [^] # Re: Compléments

                Posté par  . Évalué à 8.

                Ce qu'il dit, c'est qu'une backdoor volontaire dans un logiciel propriétaire est beaucoup plus facile à cacher puisque dans le code source, elle n'a pas besoin de prendre l'apparence d'un bug subtil, ça peut être quelque chose de presque aussi simple que 'if (premiers octets de la trame = 0xa4564654086c4a57ze654) then 'donner l'accès root'.
                Et la proba de tomber sur la bonne chaîne par fuzzing est la même que de retrouver une clef AES en essayant au hasard, c'est-à-dire nulle en pratique.

                • [^] # Re: Compléments

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

                  'if (premiers octets de la trame = 0xa4564654086c4a57 z e654) then 'donner l'accès root'.

                  Ça va être compliqué à implémenter ça quand même.

                  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                • [^] # Re: Compléments

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

                  Ce qu'il dit, c'est qu'une backdoor volontaire dans un logiciel propriétaire est beaucoup plus facile à cacher puisque dans le code source, elle n'a pas besoin de prendre l'apparence d'un bug subtil

                  Oui c'est plus dur à cacher dans un programme open-source mais c'est aussi plus facile de tenter : l'aspect développement communautaire fait qu'on peut facilement rentrer dans le cycle de développement et proposer un patch "anodin". D'ailleurs la NSA utilise déjà le même genre de ruse en s'immiscent dans d'autres forme de travail "ouvert", comme la rédaction de spec/standard à l'IETF ou autre.

                • [^] # Re: Compléments

                  Posté par  . Évalué à 3.

                  Ce qu'il dit, c'est qu'une backdoor volontaire dans un logiciel propriétaire est beaucoup plus facile à cacher puisque dans le code source, elle n'a pas besoin de prendre l'apparence d'un bug subtil

                  Uniquement si tout les gens susceptibles de voir le code sont au courant, ou alors à condition de l'introduire quelque part dans le processus de build, sans qu'une personne "lambda" (de l'entreprise, sur le projet) autorisée à voir le code ne la voit. Il faut quand même la "cacher" un minimum du code que les gens internes à l'entreprise/projet voient. (je suis d'accord que c'est plus simple, mais pas non plus très simple)

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

                  • [^] # Re: Compléments

                    Posté par  . Évalué à 1.

                    Si la backdoor est placée par quelqu'un d'un niveau hiérarchique suffisamment haut, il suffit d'avoir le droit de remplacer le binaire compilé qui ira dans la boîte vendue (ou dans la mise-à-jour de dernière minute).
                    Donc même ceux qui sont autorisé à voir le code ne verront rien (le code coupable n'étant présent que sur la machine ayant fait la dernière compilation, accessible uniquement à la personne ayant fait celle-ci).

                    Le même problème existe d'ailleurs dans le libre: il faut définir des procédures de compilation déterministe et avoir un système ouvert de vérification que le binaire distribué est identique.

                    • [^] # Re: Compléments

                      Posté par  . Évalué à 1.

                      Ben non, ca ne marche pas.

                      Parce que le jour ou un bug est rapporté, les développeurs chargent le binaire publié, et se rendent très vite compte que le code (et les symboles de débuggage si l'effort est fait de les modifier aussi) ne correspondent pas au code qu'ils ont.

                      Sans parler du fait qu'être placé très haut ne signifie pas que la personne a accès aux machines.

                      Tu peux être sur que les VPs et autres de Windows n'avaient pas accès aux machines de build et aux dépots de code source par exemple, car tout le monde doit faire la demande. Et une demande de leur part d'avoir un accès, surtout en écriture, vu leur job, aurait été vue avec énormement de suspicion par les gens en charge d'autoriser la requète.

                      • [^] # Re: Compléments

                        Posté par  . Évalué à 2.

                        Pas sur de comprendre.
                        Quand il y a un bug sous Windows, tout le code de Windows est analysé, dans toutes les dll ?
                        Et tout les développeurs ont systématiquement tout le code dans toutes les versions distribuées, qu'ils recompilent parallèlement entièrement ?
                        Compilent-ils tous sur exactement la même machine ? Avec un compilateur et une machine qui ont exactement le même état ?

                        Notons que c'est rassurant: c'est donc la même chose pour Linux, cela veut dire que d'après toi, le risque d'avoir des paquets compilés malveillants est réduit par le fait que ça se verrait au débogage.

                        En ce qui concerne l'accès au code source: s'il est si restreint et contrôlé, cela pose les mêmes problèmes d'avoir un petit nombre de personne y ayant accès / contrôle (remplace "de haut niveau administratif" par "de haut niveau de contrôle de l'accès").
                        Dans les entreprises privées, les procédures de ce type (c-à-d considérer les personnes de confiance (= les personnes qui ne veulent pas saboter MS) comme pas de confiance) sont bien sur papier, mais en pratique, je doute qu'elles soient respectées: elles coûtent en contrôle et en maintient (argent, temps, flexibilité face aux dead-lines, …), tandis que personne à l'extérieur ne peut pas vérifier si c'est fait ou pas, avec pratiquement aucun gain.

                        • [^] # Re: Compléments

                          Posté par  . Évalué à 2.

                          Quand il y a un bug sous Windows, tout le code de Windows est analysé, dans toutes les dll ?

                          Quand tu insères du code dans un binaire, ça décale tout le code de diffèrentes manières. Si qq'un rapporte un bug dans ce binaire, ou un binaire relatif, et qu'un développeur charge le schmilblick dans un debugger pour voir ce qu'il se passe, il verra que les lignes de code sont décalées par rapport à l'assembleur indiqué par le debugger, voire même le debugger lui dira directement que le binaire ne correspond pas aux symboles de debuggage si l'attaquant n'a pas fait l'effort/réussi à modifier les symboles de debuggage en même temps.

                          Et oui, ca n'a rien de spécifique à Windows, c'est vrai pour Linux aussi.

                          Et tout les développeurs ont systématiquement tout le code dans toutes les versions distribuées, qu'ils recompilent parallèlement entièrement ?
                          Compilent-ils tous sur exactement la même machine ? Avec un compilateur et une machine qui ont exactement le même état ?

                          Cela n'a rien à voir avec le problème. Le problème est la correspondance entre lignes de code (que les développeurs ont évidemment), et ce que les symboles de debug disent. Si ton debugger à un moment te dit qu'il y a un appel de fonction, et tu vois une ligne de code disant "int a = 4+20;", tu sais qu'il y a qqe chose qui foire.

                          Et tout ça c'est évidemment sans parler du fait que les binaires sont signés d'habitude(du moins pour Windows, Office et autres softs), faudrait que le gars arrive à faire son changement dans l'intervalle entre la génération des binaires et leur signature, sinon il devra poser lui même une requête de signature(ça demande typiquement 2-3 personnes, donc il devra avoir des complices déjà), et inutile de dire que ça va tout de suite alerter tout le monde. Ça va pas être du gâteau.

                          En ce qui concerne l'accès au code source: s'il est si restreint et contrôlé, cela pose les mêmes problèmes d'avoir un petit nombre de personne y ayant accès / contrôle (remplace "de haut niveau administratif" par "de haut niveau de contrôle de l'accès").

                          Non du tout, c'est très différent. Si tu prends le cas de Microsoft, ou Amazon, ou Google, … t'as des centaines et centaines (voire milliers selon les projets hein) de développeurs/testeurs, t'as quelque dizaines de managers de 1-2ème niveau, et au dessus c'est le "haut management".
                          Ces sociétés ont toutes des permissions sur leur code source, géré par groupe, avec un pare-feu humain pour joindre le groupe. Tu regardes typiquement qui est la personne, pour qui il bosse et quel est le titre de son job pour décider quand tu reçois la requête, il y a une automatisation pour expédier les requêtes ou c'est super évident (le gars est dans la hiérarchie du VP du bon groupe, son titre est développeur, …). Ça te dit si il bosse dans le bon département, si il est sensé avoir accès au code, … et il y a toujours le manager de la personne en CC: sur l'email histoire qu'il soit au courant. C'est au final très simple et une requète "bizarre" se voit très vite.

                          • [^] # Re: Compléments

                            Posté par  . Évalué à 3.

                            Quand tu insères du code dans un binaire, ça décale tout le code de diffèrentes manières.

                            Je n'ai toujours pas compris.
                            Si je modifie la dll "machin.dll", et qu'il y a un bug dans la dll "truc.dll", comment "truc.dll" peut-il être décalé ? comment le débugage de truc.dll m'informe du contenu de machin.dll ?
                            Même si truc.dll renvoie des informations sur machin.dll, pourquoi est-ce que ces informations seraient traitées si le bug n'a rien à voir avec cette partie (d'autant plus que traiter ces informations ne servent à rien à la résolution du bug: quand je cherche à fixer un bug, j'identifie d'abord où il a lieu, je ne perds pas mon temps à vérifier que le code est le même ailleurs alors qu'a priori, il l'est)

                            Le code assembleur (et son ordre et sa taille), si je ne m'abuse, dépend aussi de l'état de la machine et du compilateur, qui peut optimiser différemment selon les cas (et l'optimisation change le contenu des instructions à l'intérieur d'une même fonction).
                            Du coup, je ne comprends pas trop cette histoire de lignes.

                            Si ton debugger à un moment te dit qu'il y a un appel de fonction, et tu vois une ligne de code disant "int a = 4+20;", tu sais qu'il y a qqe chose qui foire.

                            Tu me parles de correspondance de ligne dans le code source.
                            Mais:
                            1) le débuggeur, sans symbole de débuggage, n'est pas capable de retrouver la ligne.
                            2) avec symbole de debuggage, il suffit de modifier la source pour compenser le décalage (par exemple en écrivant plusieurs instructions sur une seule ligne: "int a = 4+20;int b = 5+20;…"). Évidemment, si le programmeur va voir la ligne correspondant à "int b = 5+20;", il verra le problème. Mais il ne va pas vérifier un à un tout les éléments (surtout qu'il part du principe qu'il n'y a pas eu de modification de code).

                            faudrait que le gars arrive à faire son changement dans l'intervalle entre la génération des binaires et leur signature

                            On parle d'une modification prévue dans le workflow. Le scenario n'est pas un méchant espion infiltré chez MS, mais une collaboration volontaire entre la direction et la NSA, par exemple.
                            Évidemment, la plupart des employés ne sont pas informé de ce workflow, tout comme les employés ne sont pas informé des fraudes fiscales prévues dans le workflow dans certaines entreprises.

                            Non du tout, c'est très différent. Si tu prends le cas de Microsoft, ou Amazon, ou Google, … t'as des centaines et centaines (voire milliers selon les projets hein) de développeurs/testeurs, t'as quelque dizaines de managers de 1-2ème niveau, et au dessus c'est le "haut management".

                            Mais, c'est également le cas de tout ce qui concerne le département financier: il y a des tas de gens en charge de différent budgets, avec des tas de contrôle tout autour.
                            Mais on sait que ça n'a pas empêché dans certaines grandes compagnies des malversations financières.
                            En pratique, pour une personne interne, surtout si c'est en accord avec la direction, il y a toujours moyen de contourner le système.
                            D'un côté, on sait que, par exemple, la fraude fiscale en entreprise est une réalité, alors qu'elle requiert de contourner un système très très contrôlé par l'entreprise (vu que l'entreprise ne veut surtout pas qu'un employé lui vole son argent). Du coup pourquoi c'est impossible avec le code ? Et si c'est le cas, pourquoi les entreprises n'utilisent pas un système identique pour le département des finances (pour prouver qu'ils ne fraudent pas) ?

                            • [^] # Re: Compléments

                              Posté par  . Évalué à -1.

                              Si je modifie la dll "machin.dll", et qu'il y a un bug dans la dll "truc.dll", comment "truc.dll" peut-il être décalé ? comment le débugage de truc.dll m'informe du contenu de machin.dll ?

                              Faut comprendre que quand tu debug un probleme, en faisant du step-by-step dans un debugger, tu passes frequemment d'un dll a un autre au fil des fonctions.

                              1) le débuggeur, sans symbole de débuggage, n'est pas capable de retrouver la ligne.

                              T'imagines bien que MS génère et garde les symboles de debuggage pour tous les binaires qu'il publie, c'est impossible de properement debugger un problème sans ça.

                              Évidemment, la plupart des employés ne sont pas informé de ce workflow, tout comme les employés ne sont pas informé des fraudes fiscales prévues dans le workflow dans certaines entreprises.

                              La différence est que dans le cas financier, c'est au final la tête qui regroupe les résultats de différents groupes qui n'ont pas accès à tout, ils ne peuvent pas voir si il y a eu magouille car leurs chiffres personnels ne peuvent pas être directement reliés.

                              Avec du code, l'origine du code dans un module est clair : c'est tel groupe de 3-4 développeurs. Lorsque ils debuggent un problème et voient que le binaire ne correspond pas au code, ou voient que le code dans le dépot a changé et ils ne reconnaissent pas le changement, c'est immédiatement visible. A moins d'avoir tous les développeurs et testeurs de ce module dans la poche, ça va être dur de faire passer en douce un changement. Totalement impossible ? Non, mais c'est pas mal plus dur que trouver une faille dans le code que ces développeurs ont écrit par exemple je dirais.

        • [^] # Re: Compléments

          Posté par  . Évalué à 4.

          et des gens qui le lisent

          C'est pas le fait que le code soit ouvert qui rend le code sûr c'est le fait qu'il soit audité. C'est très différent.

          Tu peux avoir pleins d'experts qui auditent du code non libre (alors il peut être non libre avec du code librement accessible ou complètement fermé) et produire un rapport d'audit indiquant quelle est la version binaire du programme ils ont audité (en fournissant la garantie via un signature ou une somme de contrôle).

          Et avoir du code libre qui n'est pas audité (OpenSSL, il y a un an ?).

          Bref ce qui te donne de l'assurance ce n'est pas le code libre, mais un rapport d'audit qui te dis que cette version des sources ou du programme binaire a était audité par tel personne et que lui te dis qu'il n'a pas vu de problème (après c'est la confiance que tu donne en l'auditeur qui compte).

          Je ne dis pas que tor n'est pas audité (j'en sais rien) je dis que c'est pas le fait que moi je puisse accéder au dépôt qui m'indique une quelconque sécurité.

          Je ne doute pas du sérieux de tor, ils ont une page qui fourni ce genre de rapport ?

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

          • [^] # Re: Compléments

            Posté par  . Évalué à 1.

            indiquant quelle est la version binaire du programme ils ont audité

            Est-ce que cela signifie qu'après un audit, une nouvelle version est moins fiable que la version auditée ?
            Vu qu'un audit est "aléatoire" (vu que décidé par quelqu'un d'extérieur), cela reste mieux que rien: un éditeur qui se fait éditer sait qu'il risque gros s'il fait une connerie. Mais en pratique, si je veux introduire une faille qui ressemble à un bug, le meilleur moment est juste après un audit.

            Bref ce qui te donne de l'assurance ce n'est pas le code libre, mais un rapport d'audit

            Notons aussi l'impact (négligeable ou pas) des usages qui ne sont pas des audits mais qui permet également d'avoir une plus grande confiance dans le code.
            Par exemple, rajouter une fonctionnalité implique de comprendre une partie du code, ce qui permet d'éventuellement trouver des failles. Même chose pour les tentatives d'optimisation de code ou quand on veut juste voir comment le logiciel fait pour apprendre comment faire.

            • [^] # Re: Compléments

              Posté par  . Évalué à 3.

              Est-ce que cela signifie qu'après un audit, une nouvelle version est moins fiable que la version auditée ?

              Totalement, il n'y a pas de raison que le code de la version suivante (quelque soit l'incrément) soit un code totalement différent.

              Mais en pratique, si je veux introduire une faille qui ressemble à un bug, le meilleur moment est juste après un audit.

              Le rapport doit contenir un pointeur fiable vers le programme en question. Par exemple en donnant la somme de contrôle ou une signature PGP des sources ou du binaire audité (et non pas juste le numéro de version ou l'identifiant du commit - fiable1 sur git et mercurial et pas fiable sur svn -).

              Notons aussi l'impact (négligeable ou pas) des usages qui ne sont pas des audits mais qui permet également d'avoir une plus grande confiance dans le code.

              C'est AMHA tout à fait négligeable. Ça permet de corriger certaines choses, mais il faut généralement comprendre dans le détail et réfléchir sous l'angle de la sécurité pour voir une faille de sécurité.


              1. enfin je crois que git utilise sha1 et qu'on commence à dire que sha1 n'est plus assez sûr donc bon. Je sais pas pour mercurial. 

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

      • [^] # Re: Compléments

        Posté par  . Évalué à 1.

        A propos de la garantie qu'apporte un logiciel libre, il faut aussi jeter un coup d'oeil aux résultats du "concours de code C sournois"

  • # SSH ?

    Posté par  . Évalué à 7.

    En quoi SSH est-il "cassé" ? Je ne comprends pas trop de quoi ils parlent.

    En tout cas, ils sont de plus en plus dangereux et les défenses s'amenuisent.

    • [^] # Re: SSH ?

      Posté par  . Évalué à 5.

      L'article du Spiegel donné en lien plus haut ne donne pas beaucoup de renseignement. Il indique juste

      The NSA also has a program with which it claims it can sometimes decrypt the Secure Shell protocol (SSH).

      que l'on peut traduire par « La NSA dispose aussi d'un programme avec lequel elle annonce qu'elle peut parfois décrypter le protocole SSH »

      L'info provient de ce document qui ne donne pas beaucoup plus d'infos.

      • [^] # Re: SSH ?

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

        Probablement http://www.openwall.com/articles/SSH-Traffic-Analysis (2010) mais peut-être qu'ils utilisent des techniques plus récentes et/ou non publiées également.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: SSH ?

          Posté par  . Évalué à 1.

          Merci. :)

        • [^] # Re: SSH ?

          Posté par  . Évalué à 2.

          Sans être expert en sécurité, ça ne me semble pas particulièrement stressant. Apparemment, en écoutant ssh, il est possible d'avoir des informations sur le contenu, en particulier la taille du texte qui passe. Du coup, l'attaquant peut devniner que vous tapez "ls" ou "cd /"—pas très inquiétant quand même. On parle aussi de connaitre la longueur des mots de passe, ce qui parait un peu plus embêtant. Ceci dit, ça ne change pas vraiment la complexité de l'attaque en bruteforce. Donc bon, sans informations supplémentaires, est-ce qu'il est réellement possible de dire que SSH est cassé?


          Un peu HS, mais important quand même : on peut partir du principe que toutes les communications sont cassables dans le futur. Il ne faut jamais imaginer que la NSA ou n'importe qui n'aura jamais accès à un contenu chiffré, on peut juste partir du principe qu'aujourd'hui, elle n'y aura pas accès. Ça change quand même pas mal le contexte, et ça remet un peu en cause l'idée même de faire transiter des infos vraiment confidentielles pour longtemps sur le réseau.

  • # Mais si tout le monde s'y met, ça devient difficile

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

    Même si la NSA peut casser des connexions sécurisées via SSH ou HTTPS par exemple, il ne semble pas qu'ils le font avec une facilité déconcertante. Ce qui signifie que si tout le monde les utilise, ils arriveront probablement à déchiffrer quelques personnes ciblées, voire un paquets de gens mais probablement pas tout le monde automatiquement et systématiquement. Ce qui signifie que même si la NSA peut passer outre certaines méthodes, elles ne sont pas forcément obsolète car ça met des barrières et empêche de faire la surveillance généralisée systématique ce qui est le but.

    Bref, ce n'est pas forcément aussi dramatique que cela laisse paraître, même si évidemment ça incite à la méfiance.

  • # Pourquoi pas ?

    Posté par  . Évalué à 7.

    Comment pourraient t'il finnancer un outil qu'ils ne peuvent pas cracker ?

    Et pourquoi pas ? Y a il une loi qui interdit au gouvernement de financer quelquechose qu'ils ne peuvent pas cracker ?

    Le gouvernement, ca n'est pas seulement la NSA. C'est par exemple aussi le "Bureau of Democracy, Human Rights, and Labor" et d'autres organismes:
    http://www.state.gov/j/drl/

    Et ca n'est pas la NSA qui gère leur budget.

    • [^] # Re: Pourquoi pas ?

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

      Et ca n'est pas la NSA qui gère leur budget.

      Non, ce sont les illuminatis et ils gèrent aussi les activités de la NSA !

  • # Taille des clés RSA

    Posté par  . Évalué à 8.

    Le plus probable est que la NSA ait réussi à casser les clefs RSA de 1024 bits en 2010 et que bien entendu n'en a pas fait de publicité.

    Ce n'est que très récemment que les certificats avec des clefs de cette taille sont bannis (voir https://www.ssl247.fr/entreprise/blog/Microsoft-sapprte--supprimer-tous-les-certificats-racines-1024-bits-de-sa-Trust-List - il faut lire 1024 et non 2014 ou http://www.silicon.fr/100-000-sites-utilisent-encore-certificats-ssl-en-rsa-1024-bits-96549.html, https://www.globalsign.fr/centre-information-ssl/cles-privees-et-publiques-1024-bits.html) de même pour Google qui est passé en 2048 courant 2013 (http://www.lemondeinformatique.fr/actualites/lire-google-renforce-la-securite-ssl-avec-des-cles-2048-bits-53712.html). Il est d'ailleurs probable que la NSA ait fait des progrès et que les clefs de 2048 bits ne sont peut-être plus sures.

    D'ailleurs le problème est le même pour l'algorithme de hachage : la plupart des certificats utilisent SHA1 qui est certainement lui aussi cassé (voir : https://nakedsecurity.sophos.com/2012/12/09/sha1-brute-force-trimmed-21-percent/ et http://linuxfr.org/news/nouvelles-attaques-sur-sha-1-debian-pourrait-migrer-vers-sha-2) cela permet de réaliser des collisions donc de substituer des certificats pour faire du MITM.

    • [^] # Re: Taille des clés RSA

      Posté par  . Évalué à 2.

      Il faut mettre le conditionnel pour mon commentaire, cependant The SHA-1 collision project travaille sur les collisions pour SHA-1 et avance bien.

    • [^] # Re: Taille des clés RSA

      Posté par  . Évalué à 4.

      Ce n'est que très récemment que les certificats avec des clefs de cette taille sont bannis
      Et dire que l'ANSSI française recommandait, pour le niveau de sécurité standard (le plus basique qui soit), de ne pas utiliser de clefs RSA de 1536 bits après 2010 !

      Cf http://www.ssi.gouv.fr/site_documents/politiqueproduit/Mecanismes_cryptographiques_v1_10_standard.pdf

      • [^] # Re: Taille des clés RSA

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

        C'est juste du foutage de gueule ces histoires de clés. Quand il a fallu refaire tous les CSR parce que les clés de 1024 imposées auparavant n'étaient plus sûres, j'ai demandé aux autorités que je fréquente de passer directement en 4096. Visiblement ce n'était pas possible.

        Faute d'une réponse a la question de savoir pourquoi et de justification technique envisageable‚ j'en déduis que 2048 est actuellement la taille idéale recommandée par les analystes et autres consultants experts. Cassable par les gentils mais pas par les méchants soit disant …

        Bref comme disait kaa : aie confiance …

        • [^] # Re: Taille des clés RSA

          Posté par  . Évalué à 7.

          Faute d'une réponse a la question de savoir pourquoi et de justification technique envisageable, j'en déduis que 2048 est actuellement la taille idéale recommandée par les analystes et autres consultants experts.

          Je ne peux pas répondre à la place des autorités que tu fréquentes, et loin de moi l’idée de me faire passer pour un expert.

          Mais si les clefs de 2048 bits sont encore conseillées par certains (dont moi), c’est aussi qu’augmenter la taille des clefs n’est pas gratuit. L’opération RSA est coûteuse, et elle l’est d’autant plus que la clef est de grande taille.

          Par exemple, calculer une signature avec une clef de 4096 bits prend près de 9 secondes sur certains microcontrôleurs.

          À mon avis, face à l’augmentation de la puissance de calcul, la rotation régulière des clefs (par exemple au moins une fois par an) est une meilleure réponse que la bête augmentation de leur taille.

          (Ou passer aux courbes elliptiques, éventuellement, mais personnellement je suis sceptique à leur sujet.)

          Cassable par les gentils mais pas par les méchants soit disant …

          RSA 2048 bits, en l’état actuel des choses (et en laissant de côté les extraterrestres de Zarbnulax), ce n’est cassable par personne…

          • [^] # Re: Taille des clés RSA

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

            Passer à du 4096 bits est en effet coûteux : pour s'en rendre compte, il suffit de faire le test avec un serveur web et quelques tailles de clefs jusqu'à 8192 bits. J'avais fait le test (avec des requêtes « vides »), et tu peux diviser par deux les performances (de mémoire, j'avais fait ce test rapide il y a deux ans).
            C'est un test très empirique et critiquable, mais qui permet au moins de se rendre compte qu'utiliser des clefs de taille importante peut avoir un coût non négligeable.

            • [^] # Re: Taille des clés RSA

              Posté par  . Évalué à 3. Dernière modification le 30 décembre 2014 à 18:49.

              Effectivement si tu ouvres et fermes ta connexion à chaque requêtes ça va être significativement plus long. Mais sur pas mal de "services" (SSH, session http longue, xmpp)… c'est négligeable.
              Après je pense que ça peut poser effectivement plus des problèmes d'interopérabilités. En plus de tes exemples je citerais l'exemple des smartcards. Il y en a très peu qui gèrent les clés de 4096 bits.

Suivre le flux des commentaires

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