Discussion :

[Invité]

Le fait qu'il soit impossible de crypter l'adresse du destinataire fait que n'importe quel nœud sait ou ou va le paquet.

Faux.
Parce qu'en terme de traçabilité IP, un relay Tor ne connait que 2 choses : l'IP du relay Tor qui lui a envoyé le message, et l'IP du relay Tor vers qui il doit envoyer le message (après l'avoir traité). Impossible pour un relay Tor de connaître l'adresse destination du message original (sauf si c'est l'exit point bien sûr). C'est par construction du message Tor.

Il y a toujours un contrôle des nœuds, ne serait ce que de la part de celui qui à accès à l’interrupteur ou au câble d'alimentation du nœuds. Les nœuds sont forcément contrôler, la question est bien de savoir par qui.
La société proposant le service Tor contrôle de fait les premiers nœuds historiques. Ils sont de la maison si je puis dire. Rien de dit que les nœuds de cette société aient le même algorithme que ceux des tiers venant s'ajouter au réseau.
La société qui propose le service Tor a de fait un contrôle passif de ce qui entre dans le réseau par l'accès à ce directory. Il suffit de vérifier le contenu des nouveaux arrivant et dresser sa liste de suspects. De mon point de vu ça simplifie grandement par rapport à un service de contrôle plus actif demandant de se brancher sur les server DNS/DHCP géré par des tiers. Beaucoup plus simple que d'avoir à perquisitionner chaque particulier qui se trouve être le propriétaire d'un pc zombie avant de remonter à la source.

Ca frôle la conspiration.
Non, il n'y a pas de contrôle au sens où tu veux l'entendre.
Pas plus qu'il n'y a de "société leader" proposant le service Tor.
Tor est un package open source aux specs publiques. Tu l'installes et roule ma poule.

Oui mais le web est fait pour fonctionner de manière efficiente. En gros le chemin est calculer en fonction de facteur externe comme le trafic, pour passer par le moins d'intermédiaire possible.

Le routage du taffic Web, c'est ni plus ni moins que du routage IP.
Et dans l'Internet, le routage IP c'est fait par BGP. Et c'est de type distant vector.
Donc là, il faudra m'expliquer comment sont calculés ces chemins (et surtout par qui).

Une session dans le web classique peut tout simplement ne pas passer par l'un des nœuds de Mallory. En fait le système par rebond augmente grandement les chances qu'une session passe par l'un des nœuds de Mallory. Si ça se trouve l'algo est bidouiller pour arrêter les rebond dès qu'un paquet arrive sur un nœuds de Mallory, ce qui lui donne un accès quasi sur à la sortie du réseau ... qui se trouve être également un nœuds d'entrée.

Je comprends pas. Qui est cette société Mallory ?

L'identité des relay sont protégés par cryptage et de par leur isolation

Je comprends pas trop ce que tu veux dire par là.
Un relay Tor, c'est simplement un noeud inséré dans l'Internet qui tourne un service particulier (s'annoncer sur Tor et traiter les messages Tor). On peut donc très rapidement localiser l'autorité administrative en charge du noeud comme n'importe quel autre actif dans l'Internet.

Il faut comprendre que le système de rebond aléatoire est parfait forcer le fait de tomber sur un nœud de Mallory selon un principe martingalesque : tant que je suis pas chez Mallory, je rebondi. Le naïf qui pense que le nombre de rebond assure sa protection se trompe. Le principe du rebond est la menace.

Tiens, encore Mallory. Ca devient très mystérieux
Et qui a dit que le nombre de rebonds devenait une protection ?
Je vois que tu n'as toujours pas compris comment ça fonctionne.
Le circuit virtuel est calculé par le client. Le traffic Tor, c'est une forme de source routing par construction, donc les relay ne peuvent pas modifier le "chemin Tor" du message. Au contraire du routage IP classique, dans lequel le routeur peut éventuellement modifier le forwarding des paquets suite à une modification de table de routage.

Je ne suis pas un expert en crypto et je me suis pas donné la peine de regarder en détail comment marche un réseau dans lequel je ne m'aventurerai jamais

Ah, je me disais bien.

Enfin bon j'en sais assez pour savoir qu'avec certains algos du moins, très robuste par ailleurs, crypter x fois un message avec x clefs revient a crypter une fois ce message avec une clef qui serait la "moyenne" des autres clefs

Tor encrypte un message original puis l'encapsule pour former un nouveau paquet.
Ce nouveau paquet est encrypté puis encapsulé. Etc.
Donc non, Tor ne crypte pas x fois un message avec x clés.
Tor encrypte x fois un message (avec x clés) qui a été encapsulé x-1 fois.


Steph

[sevyc64]

Mais que le traffic soit capturé au niveau des entry/exit points, ou à l'intérieur du nuage Tor, ce sera toujours encrypté. C'est le fondement même de Tor. Les seuls paquets non encryptés sont les ouvertures de connexions avec les entry points.

Heu non, avec TOR, tout le traffic entre le point de sortie et le serveur destinataire n'est pas crypté au sens du réseau TOR, il est "en clair".

Mais, effectivement, si ce trafic "en clair" est lui-même un trafic crypté SSL parce le serveur interrogé l'est en https, par exemple .... Mais au niveau de TOR, il ne l'est pas !
Tout au moins de ce que j'en ai compris.

[psykokarl]

Faux.
Parce qu'en terme de traçabilité IP, un relay Tor ne connait que 2 choses : l'IP du relay Tor qui lui a envoyé le message, et l'IP du relay Tor vers qui il doit envoyer le message (après l'avoir traité). Impossible pour un relay Tor de connaître l'adresse destination du message original (sauf si c'est l'exit point bien sûr). C'est par construction du message Tor.

Pour le coups, ma remarque est fondamentalement fausse. La ou je voulais en venir c'est qu'un cryptage par clef secrète est impossible. Je n'ai pas pensée aux pair clef publique/clef privée, ou plutôt j'ai écarté cette possibilité parce que je ne voyais pas comment faire un système fiable sur ce principe.

Ca frôle la conspiration.
Non, il n'y a pas de contrôle au sens où tu veux l'entendre.
Pas plus qu'il n'y a de "société leader" proposant le service Tor.
Tor est un package open source aux specs publiques. Tu l'installes et roule ma poule.

L'argument de la conspiration ou le moyen facile de botter en touche sans se casse la tête ^^.
Je reformule : Tor est fiable si tous les nœuds jouent le jeux conformément aux specs publiques. N'importe qui peut modifier les specs pour modifier le comportement de son relay. Il y a une société leader à partir du moment ou une société maitrise suffisamment de nœuds modifiés pour reprendre la main. Un nœud modifié peut tout simplement enregistrer les messages en attendant de les décrypter ou court-circuiter le trajet si tous les nœuds sont maitrisés. Cela permet les vieilles combine comme le bon vieux phising à papa.
Ce n'est pas sur les specs que je jette le doute, mais sur les intentions de ceux qui maitrisent les nœuds.

Je comprends pas. Qui est cette société Mallory ?

Cela s'applique à tout organisme qui a des moyens financiers suffisant et la volonté de bidouiller un nombre de relay suffisant pour son profit. Le reste n'est qu'une question de combinatoire. Si on suppose qu'il existe un organisme historique qui supposons à mis en place les 1000 premiers relay et que ceux sont bidouillés, il suffit de surveiller les nouveau relay tiers à priori non bidouillé qui se sont installés et ajouter autant de relay maison qui ne poseront pas de problèmes. Puis entre nous, si il est concevable qu'un jour, tous le monde a son site web, peut on en dire autant pour les relay Tor...

Un relay Tor, c'est simplement un noeud inséré dans l'Internet qui tourne un service particulier (s'annoncer sur Tor et traiter les messages Tor). On peut donc très rapidement localiser l'autorité administrative en charge du noeud comme n'importe quel autre actif dans l'Internet.

Mais il est quasiment impossible de savoir quel noeud fait bien son boulot, sauf à vérifier que tous les nœuds du circuit ont bien reçut le paquet, ce qui laisserait d'avantage de trace.

Le circuit virtuel est calculé par le client. Le traffic Tor, c'est une forme de source routing par construction, donc les relay ne peuvent pas modifier le "chemin Tor" du message. Au contraire du routage IP classique, dans lequel le routeur peut éventuellement modifier le forwarding des paquets suite à une modification de table de routage.

Si dans la mesure ou l'adresse du prochain relay est connu, un relay trafiqué pourrait filer le paquet à un système d'archivage maison avant de remettre le réseau. L'avantage est de ne plus avoir a imposer quoi que ce soit a un prestataire tiers (FAI, hébergeur, etc). Discrétion garantie...

Tor encrypte un message original puis l'encapsule pour former un nouveau paquet.
Ce nouveau paquet est encrypté puis encapsulé. Etc.
Donc non, Tor ne crypte pas x fois un message avec x clés.
Tor encrypte x fois un message (avec x clés) qui a été encapsulé x-1 fois.

Le nombre de relay est moindre que le nombre d'utilisateur passant par ces relay. Moins de couple clef publique/clef privée à calculer. Niveau sécurité c'est pas top. Je préfère me méfier de la partie de l'article wikipedia qui dit : "L’idée est donc de distribuer à chaque nœud du circuit une clef secrète chiffrée avec leur clef publique." Selon la manière dont c'est fait, ça peut être correct, comme ça peut être une catastrophe.
En tous cas le fait d'avoir a disposition la clef publique non pas au moment de la communication mais au moment de la mise en service du relay permet à Mallory de calculer la clef privée correspondante en amont de la communication.

[Invité]

Heu non, avec TOR, tout le traffic entre le point de sortie et le serveur destinataire n'est pas crypté au sens du réseau TOR, il est "en clair".

Mais, effectivement, si ce trafic "en clair" est lui-même un trafic crypté SSL parce le serveur interrogé l'est en https, par exemple .... Mais au niveau de TOR, il ne l'est pas !
Tout au moins de ce que j'en ai compris.

Je parlais évidemment de session entre un client Tor et une cible de type HTTPS.

Steph

[spartiate_]

Les liens de l'étude de Chloé

1) http://https://chloe.re/2015/06/20/a...ith-badonions/

2) http://https://chloe.re/2015/06/30/t...s-tor-attacks/

[miky55]

Mais c'est quoi cet article de m****. Que vient faire TOR là dedans ?

Peut être que la news n'est pas clair, mais beaucoup de gens n'ont pas l'air de comprendre ce qu'a voulu révéler cette étude. Ce qui est mis en évidence ce n'est pas qu'il est possible de faire des attaque MITM avec Tor, mais plutôt que certains nœuds de sorties sont des nœuds espions qui interceptent tout le trafic qui y passe en clair à des fins crapuleuses. Le but est de remonter ces nœuds espions à la fondation pour qu'ils soient bannis.

[sevyc64]

Peut être que la news n'est pas clair, mais beaucoup de gens n'ont pas l'air de comprendre ce qu'a voulu révéler cette étude. Ce qui est mis en évidence ce n'est pas qu'il est possible de faire des attaque MITM avec Tor, mais plutôt que certains nœuds de sorties sont des nœuds espions qui interceptent tout le trafic qui y passe en clair à des fins crapuleuses. Le but est de remonter ces nœuds espions à la fondation pour qu'ils soient bannis.

Ca, c'est ce que veut faire croire la news (tout au moins comme rédigé ici sur dvp) et tu tombe dans le panneau. Ce qui est décrit ici est une attaque tout à fait classique sur un réseau quel qu'il soit, qui n'est pas du tout spécifique à TOR, qui n'est même pas du tout spécifique à internet et au web.
Et encore, on ne sait même pas, tel que c'est relaté si c'est vraiment une attaque, ou juste une série de négligence et d'amateurisme de la part des auteurs du test.

[miky55]

Ca, c'est ce que veut faire croire la news (tout au moins comme rédigé ici sur dvp) et tu tombe dans le panneau. Ce qui est décrit ici est une attaque tout à fait classique sur un réseau quel qu'il soit, qui n'est pas du tout spécifique à TOR, qui n'est même pas du tout spécifique à internet et au web.
Et encore, on ne sait même pas, tel que c'est relaté si c'est vraiment une attaque, ou juste une série de négligence et d'amateurisme de la part des auteurs du test.

J'ai pris connaissance de la news (de l’étude de Choé pas du consultant) avant la publication sur ce site et je pense que la news formulé ici est mal rédigée puisque l’étude de Cloé n'essaye pas de démontrer que Tor n'est pas suffisamment sécurisé, mais met en évidence que certains nœuds de sorties sont plus mauvais que d'autres et qu'il est important d'utiliser une connexion ssl si l'on souhaites accéder au clearweb en passant par Tor.

Je suis également au courant que les attaques MITM ne sont pas spécifique à Tor, mais dans 99% des cas les attaques MITM du web se font sur des réseaux locaux soit en crakant des cles wep de particuliers soit en créant de faux hotspot publiques. Il est donc possible que des utilisateurs oublient ou ignorent qu’après le noeud de sortie Tor n'est plus responsables de leurs paquets...

Le protocole de test me parait assez fiable pour garantir avec des chances importantes que le sniff s'est fait au niveau des noeuds de sortie et pas ailleurs, il n'y a pas 50 autres possibilités puisque tout les paquets Tor sont chiffrés entre le client et le noeud de sortie.

Evidemment le test garde ses limites puisqu'il ne prouve pas que les autres noeuds de sorties sont sains, on peut supposer que si des gouvernements ont pu collecter des mdp lors de ce test ils ne sont pas forcement allez les tester dans ce honeypot...

[Invité]

Ca, c'est ce que veut faire croire la news (tout au moins comme rédigé ici sur dvp) et tu tombe dans le panneau. Ce qui est décrit ici est une attaque tout à fait classique sur un réseau quel qu'il soit, qui n'est pas du tout spécifique à TOR, qui n'est même pas du tout spécifique à internet et au web.
Et encore, on ne sait même pas, tel que c'est relaté si c'est vraiment une attaque, ou juste une série de négligence et d'amateurisme de la part des auteurs du test.

Je pense que tu devrais tempérer tes écrits et aller à la source
Je suis allé sur les liens donnés plus haut par spartiate_ (en enlevant le "http") et c'est exactement ce que décrit miky55

Voici ce qu'a fait la petite Chloé :

1) Elle a créé un site http racoleur avec un portail login/MdP.
2) Elle a récupéré la liste des exit nodes Tor.
3) Elle s'est connecté sur le site http avec un client Tor après avoir généré un MdP qui sera unique par exit node.

Puis elle a constaté qu'il y avait eu plusieurs tentatives de connexions, dont certaines réutilisant les MdP uniques.
Ce qui signifie que certains exit nodes sont suspects et qu'ils ont forcément sniffé le trafic pour intercepter les login/MdP.
Et qui rappelle ce que j'ai écrit maintes fois, à savoir que les maillons faibles d'une chaîne de liaisons entre un client Tor et le site destination sont les entry et exit points, spécialement si la cible est un host qui ne supporte pas d'encryption. J'avais déjà insisté sur ce point il y a quelques temps :

http://www.developpez.net/forums/d14...q/#post7826028

et rappelé les bonnes pratiques dans l'utilisation de Tor :

http://www.developpez.net/forums/d14...q/#post7826562


J'espère que l'initiative de la petite Chloé va donner des idées aux codeurs et concepteurs du projet Tor. Ce genre de test d'intégrité devrait être automatisable... Créer de façon plus ou moins aléatoire des honeypots http pour localiser puis blacklister les exit points suspects.

Steph

[sevyc64]

Effectivement je n'ai pas lu la source, je le ferais dès que j'aurais un peu de temps.

Y-a-t-il quelque chose qui prouve que c'est bien les exit-nodes qui ont aspirés les mots de passe, que ce n'est pas le lien entre l'exit-node et le serveur qui est compromis ?
J'en conviens, c'est probable, mais je ne pense pas que notre chloé ait mené les investigations jusque là.

Je me suis fait aspiré mon mot de passe sur un serveur, ya pas si longtemps dans des conditions similaires sauf que je ne passais pas par TOR (heureusement rien de sensible).
L'admin m'a confirmé que ma dernière connexion avant utilisation frauduleuse de mes mdp s'est faite, en mon nom, depuis ma machine, mais à travers de ce qui pourrait ressembler à un proxy vu coté serveur. Et que ce "proxy", ce jour-là, avait justement router plusieurs connexions légitimes, certains mdp récupérés ont ensuite été utilisé illégitimement.
Cet admin en question m'a confirmé (là ça dépasse mes compétences) que sur la traceroute, ce jour là, une des routes d'accès au serveur avait été détourné vers ce proxy.

L'analyse de Chloé exclue-t-elle cette possibilité pour affirmer que c'est bien l'exit-node qui à pris les mdp au passage ?