Oct 292011
 

Dans mon article précédent, j’évoquais l’empressement de la presse francophone à relayer et appuyer le message selon lequel Tor serait compromis.
J’ai tenté d’expliquer pourquoi une telle déclaration n’est pas à faire à la légère, les répercussions qu’auraient une vulnérabilité réelle et intrinsèque au réseau Tor, et pourquoi tant de chercheurs s’intéressent à cette technologie de si près.

J’ai également voulu apporter un regard critique sur les allégations faites, et la réalité technique de ce que Eric Filiol, directeur de recherche à l’ESIEA, prétend avoir découvert comme faille.

Cet article se positionne dans la continuité directe dudit article précédent, et abordera cette fois-ci la seconde « faille » que Filiol dit avoir découvert dans Tor, à savoir rediriger le traffic Tor de cibles potentielles vers des relais compromis, en créant de la congestion dans les autres relais, et rendant les relais « sains » indisponibles.

avertissement

Comme dans mon article précédent, je vous conseille vivement d’avoir lu mon article déblayant des notions fondamentales du fonctionnement de Tor.

Ces notions ne sont pas bien complexes, mais sont nécessaires à comprendre la réalité de ce que Filiol et son équipe avancent.

Mon but est que, après avoir lu mes articles, chacun puisse débattre de la fiabilité du reseau Tor, et de la réelle menace que l’attaque de Filiol constitue. Pour cela, il est indispensable que chacun ait compris la technologie sous-jacente. Ne serait-ce que dans son principe général.

J’en profite d’ailleurs pour vous rappeller qu’il en va de même pour toute technologie de sécurité informatique : votre confiance en celle-ci doit être proportionnelle à votre compréhension de la technologie.

Ne vous fiez pas à une technologie parce qu’un expert vous dit qu’elle est fiable. Fiez vous à une technologie parce que vous comprennez qu’elle est suffisamment solide pour l’utilité que vous en faites.

Les experts se trompent, ne sont pas toujours objectifs, et sont parfois opaques.
S’il en était autrement, ces articles n’auraient pas besoin d’exister.

Tor et les relais compromis

Comme décrit dans mon article explicatif de Tor, Tor est une technologie reposant sur aux minimum 3 relais choisis au hasard dans le réseau Tor. Les messages que vous voulez envoyer à une destination sont chiffrés autant de fois qu’il y a de relais, et chaque relais ne peut déchiffrer que le niveau de chiffrement lui étant destiné.

Source (vous) -> Relais1 -> Relais2 -> Relais3 (en clair) -> Destination (votre correspondant)

À chaque fois qu’un relais reçoit l’information, il la déchiffre avec sa clé, et passe le résultat au relais suivant, qui fera de même, jusqu’à ce que Relais3 déchiffre le dernier niveau de chiffrement, et envoie l’information en clair à la destination.

Ceci est fait pour qu’il soit impossible à aucun des trois relais de connaître à la fois le contenu, la destination et l’origine de l’information (vous).

C’est donc pour cela qu’on dit que Tor permet d’utiliser des relais pour vos communications, sans avoir à faire confiance en ces relais. Même si un de ces relais est en fait un mouchard, s’il est à la position du Relais1 ou du Relais2, il ne peut pas déchiffrer le message entièrement, et n’a donc aucune idée ni du contenu du message, ni de sa destination réelle (que seul Relais3 découvrira quand il déchiffrera le message avec sa clé), s’il est à la place de Relais3, il connaitra le contenu et la destination, mais pas l’origine, il lui sera donc impossible de vous identifier. S’il est à la place du Relais2, il ignorera tout : le message, l’origine, et la destination.

Notez que si vous avez chiffré votre message par SSL ou autre avant de l’envoyer via Tor (en contactant un site via son adresse https:// par exemple), le Relais3 ne possèdera que cette information chiffrée par SSL, et ne connaitra donc pas le message en clair non plus.

Si vous avez compris ceci, vous verrez donc qu’aucun relais ne peut trahir l’anonymat de la communication, mais s’il arrivait qu’une même personne parvienne à corrompre au moins deux des trois relais (le premier et le dernier, en règle générale), elle pourrait connaitre qui a envoyé une information à travers Tor (le premier relais est en contact avec l’origine de l’information : vous), ainsi que le contenu de votre message (s’il n’était pas chiffré), mais surtout la destination de votre message, ces deux informations étant révélées par le 3eme relais.

Si l’attaquant ne possède que deux des trois relais, il lui faudra deviner et reconnaitre que le trafic envoyé du Relais1 au Relais2 (qu’il ne possède pas), et reçu du Relais2 au Relais3 est bien le même (Rappelez-vous, ces données ont été déchiffrées par le Relais2 entre-temps, les paquets d’information ne sont donc plus les mêmes)
En faisant des attaques statistiques, il est possible de reconnaître le trafic assez effectivement, contrairement à ce que je pensais en rédigeant le premier article.

Si l’attaquant possède les trois relais, la communication peut être tracée de vous vers votre correspondant, et de votre correspondant à vous avec une probabilité d’exactement 100%.

En d’autres termes, ces deux scénarios entrainent une défaite totale de l’anonymat.

C’est donc le vecteur d’attaque le plus couramment évoqué pour corrompre l’anonymat d’une communication Tor, mais également le scénario que le logiciel de routage doit éviter à tout prix.
Pour ce faire, l’équipe de Tor doit s’assurer que le choix des relais à travers lesquels faire passer la communication dans le réseau Tor soit bel et bien déterminé au hasard, et qu’il y en ait assez pour que la probabilité d’en choisir 2 ou 3 au hasard parmi des relais mis en ligne pour servir de « pièges » (honeypots ou mouchards) soit extrêmement faible.
Pour renforcer le tout, ils ont également introduit la notion d’Entry Guard, diminuant drastiquement la probabilité de choisir un Relais1 qui ait été compromis par la même personne que le Relais3.

Vous l’aurez compris, tracer une route pour vos communications à travers des relais « sains » est un enjeu principal ici, si pour une raison ou une autre ce choix de relais se trouve compromis, Tor est battu.

Si une notion de ce bref rappel vous échappe ou n’est pas claire, tout ceci est détaille dans mon article explicatif de Tor. N’hésitez pas à aller le lire, au risque de me répéter, si tout ceci n’est pas limpide, lire la suite de l’article ne vous apportera rien.

Comment forcer une route compromise

À ma connaissance, il n’existe que trois procédés pour y arriver.

truquer le choix des relais au niveau du client

C’est l’approche la plus directe et la plus évidente.

Elle consisterait à altérer le fonctionnement du logiciel Tor installé sur votre machine, et de truquer son choix de relais censé être aléatoire, afin qu’il choisisse toujours une route composée de relais compromis par l’attaquant, même s’il sont extrêmement peu sur le réseau.

Ceci peut être accompli de deux manières :

  • infecter votre ordinateur par un virus spécialement conçu pour affecter le comportement de Tor
  • Ceci permettrait à l’attaquant de prédéfinir le tracé de vos communications à travers Tor, mais également d’observer ce que vous envoyez à travers Tor avant que la communication ne soit chiffrée. C’est donc un échec et mat immédiat.

    Gardez un système à jour, et si possible, n’utilisez pas Windows pour des communications « sensibles » 😉

  • vous fournir une version altérée du logiciel Tor
  • Ce procédé-ci consisterait à vous fournir une version du logiciel dont la sélection des relais ne soit pas aléatoire mais fixée à des relais compromis par la personne vous fournissant le logiciel. Cela semble impensable, mais c’est en réalité réalisable.
    Pour s’en prémunir, vérifiez toujours, absolument toujours le checksum du logiciel Tor que vous téléchargez avant de l’installer. Ce checksum est une valeur de vérification de l’intégrité du fichier affichée sur le site, assurant que le fichier n’a pas été altéré ou remplacé pendant que vous le téléchargiez. (attaque Man-In-The-Midle).
    Vérifiez également que le site duquel vous avez récupéré le fichier et vérifié le checksum n’est un une falsification (phishing), à l’aide de certificats.

compromettre tous les relais Tor

Si tous (ou plus de 80 ou 90%) des relais Tor sont compromis par une même personne, peu importe si le client choisit bien des relais au hasard dans le tas, la probabilité de tracer une route composée de deux ou trois relais compromis devient énorme.

Ceci dit, les statistiques publiques du réseau Tor nous révèlent qu’il y a actuellement plus de 2500 relais tor différents en ligne. Il n’est donc pas réalisable, en pratique, d’espérer compromettre 2000 à 2300 de ces relais sans que personne ne s’en aperçoive, ni d’espérer en mettre 10 000 compromis en ligne du jour au lendemain pour contre-balancer la proportion, sans que cela paraisse suspect.

Cette dernière hypothèse est d’autant plus improbable que Tor ne route pas le trafic en fonction du nombre de nœuds en ligne, mais bien de leur capacité. Mettre en ligne 10 000 nœuds tor pour espérer que Tor établisse souvent des routes entières composées de deux à trois nœuds compromis ne suffirait pas, il faudrait mettre en ligne l’équivalent de plusieurs fois la bande passante totale du réseau.

C’est à la fois invraisemblable, et très peu discret.

diminuer le nombre de relais tor présents sur le réseau

Comme mis en évidence dans le point précédent, ce qui fait la force de la sélection aléatoire de relais Tor parmis les nœuds présents sur le réseau, c’est leur nombre.

Leur nombre garantit qu’il sera toujours très difficile d’en compromettre la majorité. La présence de plusieurs nœuds ayant de très grosse bande passante garantit qu’il sera toujours relativement difficile et couteux de parvenir à déséquilibrer la proportion de bande passante passant par des relais « sains » et celle passant par des relais « compromis ».

Cependant, un équilibre est un compromis, et tout compromis, comme tout équilibre, peut être renversé si un effort suffisant ou les conditions le permettent.
Le compromis est jugé efficace si les conditions pour le déséquilibrer sont suffisamment difficiles à mettre en place.

L’approche la plus audacieuse, mais aussi la plus utopique, est donc de chercher un moyen de réduire le nombre de relais en ligne. Soit en les déconnectant du réseau, soit en les surchargeant.

C’est le vecteur d’attaque que Filiol semble avoir choisi.

Le packet spinning

Le « Packet Spinning » est une des méthodes que Filiol présente dans son attaque.

Derrière ce nom barbare se cache en réalité un procédé plutôt ingénieux.

l’établissement d’une route Tor

Lorsqu’une route Tor est décidée, elle est créée par incrément.

Le Client décide qu’il utilisera les nœuds Relais1, Relais2 et Relais3 pour sa route, choisis au hasard dans le réseau Tor.
Une fois cette sélection faite, le Client contacte le Relais1, et effectue un échange de clés publiques (afin de pouvoir envoyer des données chiffrées que seul Relais1 pourra déchiffrer)

Ensuite, le Client envoie à Relais1 un paquet spécifique appellé « Extend Cell », qui sert à « rallonger la route » d’une unité. Ce paquet contient les coordonnées du Relais2, pour que Relais1 sache que pour cette connexion établie, il devra tout acheminer vers Relais2.

Le Client envoie ensuite un second paquet qui rallongera la route d’un intermédiaire, ce paquet passera par Relais1, et sera lu et interprété par Relais2, qui connaîtra désormais les coordonnées du Relais3.

Une fois la route complètement définie, la transmission vers le correspondant peut commencer, et les paquets de cette connexion passeront toujours par ce même itinéraire.

l’attaque

L’attaque dite par Packet Spinning consiste à exploiter le fait qu’il est virtuellement possible de rajouter des HOPs (relais) à l’infini, et de mettre plusieurs fois les mêmes dans une même route.

Ceci a pour résultat de faire circuler un même paquet d’information dans une boucle (presque) infinie, et créer une charge énorme sur les relais désignés.

Pour illustrer, voici à quoi ressemble une route créée par un client Tor « sain » :

Client -> Relais1 -> Relais2 -> Relais3 -> Destination

et voici à quoi ressemblerait la route d’une attaque par Packet Spinning :

Client -> Relais1 -> Relais2 -> Relais3 -> Relais4 -> Relais1 -> Relais3 -> Relais1 -> Relais5 -> Relais3 -> Relais1 -> Relais2 -> Relais3 -> (…)

On voit par exemple que les Relais1 et Relais3 apparaissent plusieurs fois, et feront donc circuler plusieurs fois le même paquet, sans s’en douter, puisque celui-ci change à chaque passage de Relais (vu qu’il y est déchiffré)

Concrètement, si on établit une route circulaire où chaque relais apparaît 100 fois, pour 1mo de données envoyées à travers cette route, chaque relais devra traiter 100mo.

On se rend bien compte qu’il s’agit ici d’un moyen extrêmement efficace de surcharger des pans entiers du réseau Tor avec seulement une infime fraction de la bande passante que les relais possèdent, de par la facilité de la retourner contre-eux.

la parade

C’est ici que ça se corse.

Pour faire court, il n’y en a pas d’efficace.

L’attaque a cependant été rendue plus difficile à mettre en place par les développeurs de Tor.

En effet, les paquets de « rallongement de route » ne sont pas chiffrés. Du moins pas entièrement.
Les premiers relais de la route, aussi appelés Entry Guard, savent qu’ils sont les premiers de la route. Il est donc de leur responsabilité de compter les requêtes de rallongement de route qui passent. S’ils en voient plus de trois passer, dont celle qui leur était adressée, ils coupent la connexion immédiatement, afin d’éviter des routes à rallonge qui pourraient surcharger tout le réseau.

Ce procédé n’est malheureusement pas infaillible.

Il est effectivement possible d’utiliser « Tor dans Tor » : créer une route « normale et saine » Tor, à travers laquelle on fera passer les « Extend Cells ». Ces requêtes ne passeront donc par aucun Relais en clair avant d’arriver au dernier relais de la route à rallonger.
C’est plus fastidieux, mais c’est possible.

Il n’existe actuellement pas de parade absolue au Packet Spinning dans le protocole Tor, principalement parce que c’est un défaut intrinsèque à tout procédé d’anonymat par le chiffrement dans plusieurs relais.

Cependant, ce genre d’attaque ne passerait pas longtemps inaperçue, étant donnée sa nature. Il ne faudrait pas plus de quelques heures pour que les premiers relais se mettent à filtrer les origines de l’attaque, réduisant exponentiellement son efficacité au fur et à mesure.
Cette mesure n’est pas absolument efficace non plus, vu la difficulté pour les relais d’identifier l’origine des requêtes reçues (ce qui est le principal avantage de Tor, il me semble nécessaire de le rappeler)

En clair, il serait bel et bien possible pour une organisation ayant assez de moyens à disposition de sérieusement perturber le transit du réseau Tor pendant plusieurs heures, voir même forcer le réseau à s’écrouler sur lui-même et le rendre inopérant pendant plusieurs heures.

une parade ? mais Filiol n’a pas encore révélé les détails de son attaque !

Et c’est là que le bas blesse.

Si cette attaque est réellement ingénieuse, et un des seuls moyens connus de réellement entamer la disponibilité de Tor pendant un intervalle de temps relativement important, Filiol ne l’a absolument pas inventé, ni même mise au point.

Cette attaque a en réalité premièrement été décrite en septembre 2008 par Vasilis Pappas, Elias Athanasopoulos, Sotiris Ioannidis, et Evangelos P. Markatos, lors du 11ème Information Security Conference (ISC 2008).

Ceux voulant lire les détails de cette attaque astucieuse et très intéressante peuvent trouver l’étude ici.

Les lecteurs informés ou attentifs auront remarqué que j’ai légèrement simplifié le principe de l’attaque par souci de simplicité (notamment la nécessité d’utiliser un Entry Guard compromis)

Eric Filiol ayant la fâcheuse tendance de déclarer qu’il est le premier académique au monde à avoir abordé Tor en tant que « réseau » et d’avoir « mis au point » une attaque l’exploitant en tant que tel, ferait bien de citer ses sources lorsqu’il présentera « son » attaque les 29 et 30 octobre à São Paulo lors de sa conférence « Hackers to Hackers ».

Il est déjà inquiétant de voir qu’il prétend être le seul a aborder Tor en tant que réseau (ignorant plus d’une dizaine d’autres travaux, j’y reviendrai dans la prochaine et dernière partie de mon article), mais il serait assez grave de sa part de prétendre ignorer l’existence des travaux de recherches de ses confrères en 2008 dont il réutilise la terminologie de « Packet Spinning », ou du moins de ne pas préciser très clairement que cette attaque n’est pas de lui, et de revoir ses déclarations. En effet, l’étude dont il recycle les résultats et l’attaque est indéniablement une étude étudiant et attaquant Tor en tant que « réseau » et non plus « un nœud à la fois », trois années entières avant que Filiol vienne déclarer être le premier sur la balle.

S’il ne veut pas se retrouver avec des échardes de plagiat enfoncées dans son CV ainsi que sa page Wikipedia, il ferait donc bien d’être beaucoup plus prudent lors de ses présentations et déclarations à venir.

Est-ce que ça « casse » Tor ?

En théorie, ça le fragilise. En réalité, pas exactement.

Tout d’abord, même en supposant qu’une organisation assez organisée et ayant suffisamment de ressources parvienne à mettre hors service assez de nœuds, tout en mettant en ligne assez de nouveaux nœuds assez dispersés géographiquement pour ne pas être tous blacklisté par les gestionnaires de nœuds Tor attentifs, et que les nœuds Tor compromis soient assez nombreux et aient assez de bande passante pour être privilégiés lors de la création d’initéraires au sein du réseau Tor… ils ne feraient que se mettre hors-service.

En effet, même en supposant qu’une organisation parvienne à mettre tout ceci en place, elle devrait alors faire face à tout le débit supporté par l’infrastructure Tor « intacte » avant de tomber, qui cherchera à se re-router par les seuls nœuds restant en ligne. Si ce scénario est celui recherché par l’attaquant, et garantirait un haut taux de communication passant intégralement par des relais compromis, ces relais compromis receveraient tellement de requêtes en un intervalle si court de temps que l’issue la plus probable d’un tel procédé serait une surcharge colossale des nœuds compromis, probablement au point de ne même pas arriver à établir une seule route à travers les nœuds compromis (l’établissement de la route ayant un timeout de 60 secondes).

Pour que cette attaque soit efficace, il faudrait que l’attaquant déploie au moins une, voire deux ou trois fois la bande passante totale des 2500 nœuds présents avant l’attaque, sachant que bon nombre d’entre-eux ont une capacité de bande passante abyssale.

Conclusion

Nous avons donc vu que si cette attaque est redoutable pour perturber le bon fonctionnement du réseau Tor pendant un intervalle plus ou moins long avec relativement peu de ressources, il ne semble pas applicable de façon réliste à une un déploiement en situation réelle.

Il reste néanmoins que ce procédé fonctionne parfaitement en conditions simulées avec des proportions de bande passante à contrôler beaucoup plus équilibrées.

« Équilibré » est ici le mot clé.
La meilleure parade à cette attaque reste dans le fait qu’il serait démesurément couteux et complexe de mettre en place une infrastructure capable a la fois de faire passer assez de transit pour que le réseau privilégie ceux-ci, et de tenir la charge. (compte tenu du nombre de nœuds légitimes présents sur le réseau, de la capacité très importante des plus importants d’entre-eux, et du trafic constant circulant à travers Tor et qui cherchera à se re-router sur ces nouveaux nœuds, les surchargeant)

Cette attaque, comme la précédente, ne fait que nous confirmer la nécessité d’assurer la résistance du réseau Tor et sa fiabilité en hébergeant et en ayant le plus de nœuds possible sur le réseau, et si possible une bande passante conséquente pour qu’il soit encore plus difficile de renverser la balance vers un sous-réseau malicieux.

De plus, j’insiste sur le fait que pas le moindre aspect de l’attaque à laquelle j’ai ici consacré un article entier, et plus de 3500 mots, n’est issue d’Eric Filiol dans la moindre mesure possible.
Tout ceci a été décrit et présenté en 2008, plus de trois années entières avant que Filiol ne déclare être le premier à aborder Tor en tant que réseau dans une attaque, ce que —il me semble— cette attaque fait déjà.

Pas de quoi remettre en question la fiabilité du réseau Tor ici, donc, si ce n’est avoir une vision plus précise de ses limitations, et du fait qu’il est plus facile à perturber qu’on le pensait il y a quelques années.

Je conclurai donc en disant que NON, ce second « tiers d’attaque » ne « casse » toujours pas Tor, et que NON, ceci n’est toujours pas un exploit méritant ni publication académique, ni battage médiatique.

Cet article en trois parties se conclura dans les jours qui viennent avec son épilogue, décrivant cette fois ci le dernier et plus flou des aspects de l’attaque de Filiol, ainsi qu’un point fait sur la crédibilité de son auteur.

  25 Responses to “Did filiol break tor ? (2/3)”

  1. Il semble quand même que le réseau ne soit pas si sur que cela ! Une nouvelle version vient de sortir qui corrige un très gros problème de sécu : « Tor 0.2.2.34 fixes a critical anonymity vulnerability where an attacker can deanonymize Tor users. Everybody should upgrade » depuis https://blog.torproject.org/

    Et tout cela bien sur n’a rien à voir avec les travaux de recherche d’Éric Filiol … ?

  2. « Et tout cela bien sur n’a rien à voir avec les travaux de recherche d’Éric Filiol … ? »

    Tout cela n’a rien à voir avec les quelques informations qui sont déjà sorties, en tout cas. Et ça ne ressemble pas du tout à ce qu’il montre dans ses vidéos (il ne parle pas de désanonymiser un utilisateur mais de casser le chiffrement en modifiant les paramètres en mémoire). On saura bientôt de toute façon, la conf est ce week end 🙂

  3. Tout logiciel a des bugs, des failles de sécurité, et des correctifs à faire.

    Que ce soit Firefox, Opera, XMMS, Windows, Linux et même parfois des éditeurs de texte, tôt ou tard une faille de sécurité est découverte, et il devient nécessaire de la corriger.
    Ca fait partie du processus de développement de tout projet « sain ».

    Ce que je discute ici ce sont des failles dans le principe même de la technologie.

    Quand on trouve une faille dans un logiciel, on crée un patch.
    Quand on trouve une faille dans un principe (de chiffrage, d’anonymat, etc.), on ne peut que changer de principe, et en trouver un meilleur.

    Filliol prétends que Tor est une technologie dépassée, et que son principe n’est pas fiable, j’explique ici qu’il n’en est rien.

  4. @Antoine : J’ajouterai, en plus de la réponse de Koolfy, que la faille n’a aucun rapport avec les présumés travaux de Filliol. D’abord car personne, en dehors de l’équipe de Filliol ne connaît encore exactement les-dits travaux (donc difficile de corriger un truc que tu ignores). Ensuite car le TOR project indique ne pas avoir eu de contact avec l’équipe de Filliol (donc le TOR project n’en sait pas plus que nous). Enfin, en lisant le lien que tu communique, on voit bien que la faille concerne une réutilisation de certificat TLS et qu’on est loin des travaux de Filliol. Après, peut-être que le TOR project nous ment … M’enfin …

  5. heu il le cite le papier dont tu parles(Pappas), sur son twitter il dit même (slides 43,44,45)…..
    http://twitter.com/#!/efiliol

  6. Oui, et bien heureusement 🙂

    Cela ne change rien au fait que jusqu’ici et de ce que j’en ait vu (et j’attends encore quelques infos sur la dernière partie de son attaque pour ne pas m’avancer trop vite dans un domaine aussi flou et ambigu), tout ce qu’il a fait c’est d’assembler des attaques qui avaient déjà été découvertes/mises au point par d’autres chercheurs.

    Au moins, il les cite, ça aurait été très grave si ce ne fut pas le cas.

    Mais jusqu’ici ça ne semble pas être autre chose que coller des travaux déjà existant ensemble, et appeller ça de l’innovation… alors que les publications elles-mêmes suggéraient d’être utilisées comme ça.

  7. Toujours pas de 3/3 ? 🙂

  8. Non, j’ai tout en tête mais j’ai eu des imprévus et beaucoup de choses à faire, donc le rédaction a été mise en pause.

    le 3/3 devrait arriver bientot, merci de votre patience 🙂

  9. Ah! Je viens régulièrement pour avoir la suite de l’article (en surveillant MISC où Filiol publie régulièrement, mais à ma connaissance il n’y a rien sur TOR depuis sa présentation).

    Bon courage pour l’écriture 🙂

  10. Bonjour,

    Le domaine de la sécurité informatique m’intéresse énormément, c’est un article très intéressant, on attend la suite avec impatience vu que ça a été posté juste avant la présentation de Filiol.
    Depuis cette fameuse présentation on a rien de neuf, alors on aimerait savoir si finalement c’est une attaque crédible, si on peut craindre que TOR soit effectivement fragilisé au point où il perd son utilité face à des gouvernements qui ont les moyens de mettre en oeuvre ce type d’attaque, et surtout si les équipes de la fondation TOR ont prévu des correctifs 🙂

    Bon courage pour l’écriture comme dirait mon 0x1more !

  11. Bonjour,

    Pour moi la problématique de « packet spinning » que vous mentionnez a déjà été résolue pour le protocole IP : on utilise le Time To Leave (TTL). Le principe est qu’à la création d’un packet on attribue la valeur 255 au TTL. A chaque fois que le paquet est traité par un équipement de niveau 3 cet équipement décrémente la valeur du TTL. Une fois le TTL arrivé à 0 le paquet est détruit. Cela permet d’éviter qu’un paquet circule indéfinimément dans le réseau.

    On pourrait imaginer une solution où on ajoute un champs TTL au paquet Tor. La valeur initiale du champs pourrait être de 5 ou 6 par exemple (puisqu’en théorie il ne doit y avoir que 3 noeud). Ce TTL devrait être dans chaque paquet Tor. Ca pourrait être le premier octet de chaque paquet par exemple: chaque noeud décrypte cet octet, le décrémente, puis l’encrypte à nouveau avec la clef public du prochain destinataire.

    Il faudrait par contre trouver un moyen de savoir si la prochaine destination après la sortie du réseau Tor est à nouveau un noeud Tor. Si c’est le cas, celui-ci devra continuer de transmettre le TTL.

    Toute la difficulté semble là, car pour éviter l’utilisation de type « Tor dans Tor » il faut un moyen pour qu’un noeud puisse savoir si la destination suivante est également membre du réseau Tor. Ce moyen ne devra pas permettre d’obtenir facilement une liste exhaustive des noeuds Tor pour éviter le blacklistage.

  12. Le dispositif obligeant les Entry Guard de couper court les connexions demandant d’étendre le circuit à plus de 8 hops est déjà une forme de TLL élaboré.

    Quel qu’il soit, le TTL ne peut rien contre dur tor « récursif ».

    Pour plus d’information, je t’invite à lire le proposal 110 sur le sujet :

    https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/110-avoid-infinite-circuits.txt

  13. Plutot que le noeud1 transmette le TTL au noeud2 il faudrait que le noeud2 demande le TTL au noeud1.

    J’explique:
    Si on a une chaine Externe1->Noeud1->Noeud2->Noeud3->Externe2. Le problème qu’on a est qu’on ne connait pas si le paquet contient en faite une demande tor pour « Externe2 » et donc que « Externe2 » est un Noeud.

    Solution:
    Quand un noeud reçoit un paquet Tor, il demande à celui qui lui a envoyé le paquet de lui fournir le TTL. De cette façon le TTL n’est pas inclut dans le paquet et ne peut donc pas être contrefait, regénéré ou inclut dans le paquet data par « Externe1 ».

    Dans notre exemple Externe1->Noeud1->Noeud2->Noeud3->Externe2. Si « Externe2 » est en fait un noeud il va détecté que c’est un paquet Tor et va demandé au Noeud3 le TTL. « Externe1 » ne pourra pas agir sur la valeur du TTL transmit par le Noeud3 et donc l’attaque de « paquet spinning » devient innopérente.

    Si on applique se fonctionnement à tous les noeuds ça devrait fonctionner. Par contre, c’est mauvais pour l’optimisation réseau car cela veut dire que pour chaque paquet il faudra en échanger deux de plus (un pour demander le TTL et un pour la réponse).

  14. Ça ne marcherais pas.

    Pour la simple raison qu’aux yeux de externe2 (qui est donc un Noeud1), le Noeud3 est identique à n’importe quel externe1, et donc il n’y a aucune raison de lui demander un TTL, de la même façon qu’un Noed3 n’a pas à répondre à une demande de TTL provenant d’externe2

  15. Pour moi externe2 (qui est donc un nouveau noeud1) demande un TTL pour chaque paquet Tor reçu.
    Si celui qui lui a envoyé le paquet est :
    – un noeud (donc un noeud3), celui-ci prendra le TTL associé au paquet qu’il vient d’envoyer, le décrémente, le crypte avec la clef public de Externe2 (=nouveau noeud1) et l’envoi à celui-ci.
    – un externe1, c’est donc une nouvelle connexion Tor et le client Tor sur externe1 créera un nouveau TTL.

    Quand un noeud reçoit un TTL il fait ces deux vérifications:
    – Si TTL = 0, il détruit le paquet
    – Si TTL > 8 (par exemple), la valeur est trop grande, il détruit le paquet

    Quand le noeud reçoit un paquet Tor :
    1. il identifie le paquet avec un numéro unique par exemple
    2. il demande à celui qui lui a envoyé le paquet un TTL
    3.1. s’il ne reçoit aucune réponse, il détruit le paquet
    3.2. s’il reçoit une réponse, il vérifie puis décrémente le TTL et passe à l’étape suivante
    4. il enregistre dans son cache à quel numéro unique d’identification de paquet correspond le TTL.
    5. il décrypte le paquet puis l’envoie au noeud suivant (attention le TTL n’est pas envoyé pour l’instant)
    6. il attend de recevoir une demande de TTL pour le paquet qu’il vient d’envoyer
    7.1. s’il reçoit une demande de TTL, il y répond puis détruit l’enregistrement dans le cache
    7.2. s’il ne reçoit pas de demande pour ce TTL, après un certain temps il détruit l’enregistrement

    A l’étape 2, peut importe que la source soit un noeud ou un client. Les deux doivent impérativement envoyer un TTL pour que le paquet soit valide.

    L’étape 7.1 correspond au fonctionnement normale d’un Noeud1 et Noeud2. Si un Noeud3 reçoit une demande de TTL ça veut dire qu’il y a eu tentative de « paquet spinning » et suivant la valeur du TTL transmis par le Noeud3 le paquet sera rapidement détruit par la suite.

    L’étape 7.2 correspond au fonctionnement normale d’un Noeud3. Si un Noeud1 ou un Noeud2 atteint cette étape ça veut dire, soit que le Noeud suivant utilise l’ancien protocole Tor, soit que le paquet n’est pas arrivé à destination.

    Donc effectivement, en plus du problème de surcharge du réseau, cette solution n’est pas compatible avec d’ancienne version. Donc peut-être très bien théoriquement mais pas réaliste dans la pratique.

  16. Le handshake permet d’éviter tout problème de rétrocompatibilité.

    Je vais avoir besoin de quelques heures/jours de réflexions et de discussion avec les devs de Tor pour investiguer cette idée, en tout cas 🙂

  17. Le problème de ton approche est qu’il suffit qu’un ISP reconnaisse ces demandes de TTL et en spoofer les réponses pour paralyze tout traffic tor passant par son infra.

    De plus, cette approche a été abordée dans le tiquet #2667
    https://trac.torproject.org/projects/tor/ticket/2667

    La raison pour laquelle il n’y a rien d’implémenté est que toutes les solutions proposées créent plus de problèmes qu’elles n’en résolvent.

  18. Ha oui, c’est vrai que c’est facile pour un ISP de détecter ces demandes dans ce cas 🙁
    A part les masquer dans une demande anodine genre un TCP ACK ou n’importe quel type de paquet très fréquent où on pourrait ajouter un flag anodin je ne vois pas vraiment de solution. Et je suis d’accord, ça créer plus de problème que ça n’en résoud.

  19. > truquer le choix des relais au niveau du client
    > infecter votre ordinateur par un virus spécialement conçu pour affecter le comportement de Tor

    Si on en est là, c’est juste un peu con de s’attaquer à Tor!
    😉

  20. @Orunitia
    > dans une demande anodine genre un TCP ACK ou n’importe quel type de paquet très fréquent où on pourrait ajouter un flag anodin

    Pas une bonne idée :

    – Avec un flag supplémentaire, ce n’est plus un paquet fréquent. C’est facilement repérable.
    – Pour manipuler les paquets, il faut travailler à très bas niveau; la programmation est difficile et peu portable.
    – Pour travailler à ce niveau, il faut des droits d’admin.
    – Les pare-feux risquent de trouver ça bizarre et de tout bloquer.
    – Les NAPT-box ne comprendront rien à ces échanges.
    etc.

    Il ne faut pas s’imaginer qu’on va bidouiller des variantes des protocoles de base comme TCP, qu’on peut utiliser des fonctionnalités exotiques de ces protocoles, etc.

    Au contraire, il faut n’utiliser que des choses « normales » :
    – TCP, sans triche et sans fioritures
    – TLS

    Le protocole doit être défini *dans* TLS.

    Quelle que soit les informations que tu veux échanger entre les relais, je ne vois pas ce qui t’empêche de les passer dans la session TLS!

  21. @Orunitia
    > Dans notre exemple Externe1->Noeud1->Noeud2->Noeud3->Externe2. Si “Externe2″ est en fait un noeud il va détecté que c’est un paquet Tor

    Comment tu différencies un paquet venant de Tor d’un paquet ordinaire? Tu vas taguer les paquets qui permettent à un client de se connecter à un relais? Afin de faciliter la censure?

    En résumé :

    Le problème est que Tor essaie de bloquer les connexions vers Tor, exactement comme les dictatures. En principe cela ne doit pas être faisable.

    L’alternative est que les relais refusent les connexions depuis Tor. Mais on ne peut pas faire ça sans sur-blocage avec les NAT : si un relais Tor partage une IP avec d’autres PC utilisés par d’autres personnes, qui ne se connaissent pas (cybercafé, carrier-wide NAT), tu fais comment?

  22. > si on peut craindre que TOR soit effectivement fragilisé au point où il perd son utilité face à des gouvernements qui ont les moyens de mettre en oeuvre ce type d’attaque,

    Si des gouvernements ont ces moyens, on sait déjà qu’ils ne les ont pas mis en oeuvre.

  23. @corrector

    Amen.
    Et merci pour tes contributions 🙂

  24. @corrector
    Je ne connais pas assez le fonctionnement de TOR pour aller plus loin dans la réflexion (je me suis basé uniquement sur l’article de Koolfy qui expliquait suffisament de concept pour démarrer une réflexion). Et effectivement tes arguments sont très pertinents.

    >Comment tu différencies un paquet venant de Tor d’un paquet ordinaire?
    J’avais supposé que pour que le logiciel interprete un paquet Tor il faut qu’il sache déjà les reconnaître quand il en reçoit un. Apparament non.

    >L’alternative est que les relais refusent les connexions depuis Tor. Mais on ne peut pas faire ça sans sur-blocage avec les NAT
    Touché. Le NAT empèche effectivement ma solution.

    Je pense donc que tu as raison corrector et que ma proposition ne tient pas la route.

  25. Demain je devrais suffisament avancer dansla rédaction de l’article 3/3 sur Filiol

    Je prévoir rédiger un article sur les façons de filtrer/camoufler le traffic Tor par la suite (qui devrait être beaucoup plus rapide à rédiger)

    Plein de bonnes choses à venir, donc 🙂

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>