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 NeoX . É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.
[^] # Re: facile
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 10.
Si Tor a été persé, c’est sûrement un coup des Iraniens !
[^] # Re: facile
Posté par mrlem (site web personnel) . Évalué à 3.
Je dirais même que c'est un coup de la police !
[^] # Re: facile
Posté par pamputt . Évalué à 3.
Il est peut-être bon de rappeler ce que la NSA pense du réseau Tor : 'Tor Stinks' ce que l'on peut traduire par « Tor pue ».
# Seulement les connexions sortantes ?
Posté par Plume . É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 Tonton Benoit . É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 pamputt . É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 korthaerd . É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 pamputt . É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
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 TImaniac (site web personnel) . Évalué à 3.
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 Anonyme . É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 TImaniac (site web personnel) . Évalué à 1.
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 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 Anonyme . Évalué à 8.
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 TImaniac (site web personnel) . Évalué à -2.
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.
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 Anonyme . Évalué à 8.
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 ?
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 pasBill pasGates . Évalué à 0.
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 Anonyme . Évalué à 6.
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 TImaniac (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 Anonyme . Évalué à 6.
Un code open source ne veut pas dire que tu dois accepter du code de n'importe qui. Ou meme en accepter tout cours.
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 pasBill pasGates . Évalué à 0.
Un code proprio ne veut pas dire que tu vas mettre des backdoors dedans.
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 pasBill pasGates . É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 khivapia . É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 pasBill pasGates . É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 khivapia . Évalué à 2.
Si ce n'est que RedHat donne ses sources, donc la backdoor doit être plus subtile.
[^] # Re: Compléments
Posté par pasBill pasGates . É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 2PetitsVerres . Évalué à 6.
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 pasBill pasGates . Évalué à -1.
Tout a fait, c'est possible, c'est par contre légèrement plus complique que ce que tu écris :
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 khivapia . É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 pasBill pasGates . É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 khivapia . É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 pasBill pasGates . Évalué à -2.
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é.
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 khivapia . É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 Krunch (site web personnel) . Évalué à 10.
Ç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 TImaniac (site web personnel) . Évalué à 2.
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 2PetitsVerres . Évalué à 3.
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 j-c_32 . É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 pasBill pasGates . É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 j-c_32 . É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 pasBill pasGates . Évalué à 2.
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.
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.
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 j-c_32 . Évalué à 3.
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.
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).
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.
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 pasBill pasGates . Évalué à -1.
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.
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.
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 barmic . Évalué à 4.
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 j-c_32 . Évalué à 1.
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.
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 barmic . Évalué à 3.
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.
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 -).
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é.
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 bobbysixkiller . É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 Tanouky . É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 pamputt . Évalué à 5.
L'article du Spiegel donné en lien plus haut ne donne pas beaucoup de renseignement. Il indique juste
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 Krunch (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 Tanouky . Évalué à 1.
Merci. :)
[^] # Re: SSH ?
Posté par arnaudus . É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 Renault (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.
[^] # Re: Mais si tout le monde s'y met, ça devient difficile
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Que ssh soit potentiellement percé doit donner des sueurs froides à pas mal d'admin, ou de personne de l'anssi.
"La première sécurité est la liberté"
[^] # Re: Mais si tout le monde s'y met, ça devient difficile
Posté par Renault (site web personnel) . Évalué à 3.
S'il faut la capacité de calcul de la NSA pour le faire (ce qui me semble le plus probable) pas tellement car il n'y aurait qu'eux comme assaillant potentiel ce qui limite de nombreux risques.
L'article ne dit pas si c'est possible d'améliorer les protocoles existants mais "faibles" pour les rendre actuellement inattaquable.
[^] # Re: Mais si tout le monde s'y met, ça devient difficile
Posté par pasBill pasGates . Évalué à 7.
De ce que je lis, ils 'cassent' principalement à travers :
- des failles software
- des certificats 'volés'
Ce n'est pas des failles de protocole/algorithme crypto ou une puissance de calcul dingue
Partant de la, je ne trouves pas cela si inquiétant que cela. Il n'y a pas grand chose de nouveau.
[^] # Re: Mais si tout le monde s'y met, ça devient difficile
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Est-ce que tu connais l'échelle de casse ? C'est du ciblé, ou du massif comme le reste ?
"La première sécurité est la liberté"
[^] # Re: Mais si tout le monde s'y met, ça devient difficile
Posté par Bruno (Mastodon) . Évalué à 0.
Je ne pense pas que leur objectif est de cibler tout le monde, seulement ceux qui les intéressent, c'est à dire quelques terroristes mais aussi les industries, les politiques etc..
[^] # Re: Mais si tout le monde s'y met, ça devient difficile
Posté par Plume . Évalué à 4.
L'idéal selon eux, c'est de cibler tout le monde.
Imagine que la NSA veut attaquer une certaine machine. Depuis une connexion externe, l'attaque est impossible. Mais comme ils font une surveillance généralisée et automatisée sur la totalité du réseau, ils ont probablement au moins une machine, qui à une accès simplifié à la cible par ex. une machine qui appartient à la fille du sysadmin. Du coup, on obtient un nouvel angle d'attaque probablement moins sécurisé et l'attaque devient faisable.
Par conséquence, pour cibler les personnes intéressantes, cibler tout le monde est extrêmement utile pour eux.
[^] # Re: Mais si tout le monde s'y met, ça devient difficile
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Voir, avoir des selfies nues de la fille en question pour faire pression sur le père…
"La première sécurité est la liberté"
[^] # Re: Mais si tout le monde s'y met, ça devient difficile
Posté par Plume . Évalué à 3.
Je n'y avait même pas pensé. Décidément, je n'ai pas le potentiel pour travailler à la NSA.
[^] # Re: Mais si tout le monde s'y met, ça devient difficile
Posté par 2PetitsVerres . Évalué à 4.
Pics or it didn't happen.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Mais si tout le monde s'y met, ça devient difficile
Posté par Krunch (site web personnel) . Évalué à 2.
Il y a même une vidéo http://www.theguardian.com/world/2014/jul/17/edward-snowden-professionals-encrypt-client-communications-nsa-spy
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Pourquoi pas ?
Posté par Anonyme . Évalué à 7.
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 Renault (site web personnel) . Évalué à 4.
Non, ce sont les illuminatis et ils gèrent aussi les activités de la NSA !
# Taille des clés RSA
Posté par HG203 . É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 HG203 . É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 khivapia . É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 Joris Dedieu (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 gouttegd (site web personnel) . Évalué à 7.
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.)
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 flan (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 diorcety . É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.