Dernière mise à jour de la page en November 2016.

Tor / Onion Routing

[Tor] [Onion Routing]

Tor et le routage en onion sont tous deux des réseaux de proxy d'anonymisation, permettant aux gens d'utiliser des tunnels à travers leur réseau à faible latence. Les deux principales différences entre Tor / Routage en oignon et I2P sont à nouveau liées à des différences dans le modèle de menace et le design de proxy sortant (quoique Tor prenne en charge les services cachés lui aussi). En outre, Tor utilise l'approche basée sur répertoire ("directory based") - fournissant un point central pour gérer la vue d'ensemble du réseau, ainsi que recueillir et communiquer les statistiques, à l'opposée de la base de données réseau distribuée de I2P et la sélection de pairs.

La fonctionnalité outproxy de I2P/Tor présente quelques faiblesses d'importance contre certains agresseurs, à savoir qu'une fois que la communication quitte le mixnet, les adversaires passifs globaux peuvent plus facilement monter une analyse du trafic. En outre, les outproxies ont accès au texte en clair des données transférées dans les deux sens, et les outproxies sont sujets à des abus, en plus de tous les autres soucis de sécurité que nous avons appris à connaître et à aimer ;) avec le trafic Internet normal.

Cependant, la plupart de personnes ne doivent pas s'inquiéter de ces situations, car elles sont à l'extérieur de leur modèle de menace. Et cela est, aussi, à l'extérieur du périmètre fonctionnel (formel) de I2P (si les gens veulent construire la fonctionnalité outproxy au-dessus d'une couche de communication anonyme, ils le peuvent). En fait, quelques utilisateurs I2P profitent actuellement de Tor comme proxy sortant.

Comparaison de terminologie entre Tor et I2P

Alors que Tor et I2P sont similaires à bien des égards, une grande partie de la terminologie est différente.

TorI2P
CelluleMessage
ClientRouteur ou client
CircuitTunnel
RépertoireNetDb
Serveur répertoireRouteur floodfill
Seuils de portes (entry guards)Pairs rapides
Noeud d'entréeProxy entrant
Noeud de sortieProxy sortant
Service cachéService caché, Eepsite ou Destination
Descripteur de service cachéJeu de baux
Point d'introductionPasserelle entrante
NoeudRouteur
Proxy OnionClient I2PTunnel (plus ou moins)
Onion ServiceService caché, Eepsite ou Destination
RelaiRouteur
Point Rendezvousun peu comme passerelle entrante + extrémité sortante (outbound endpoint)
Descripteur de routeurInfo routeur (RouterInfo)
ServeurRouteur

Avantages de Tor sur I2P

  • Plus grand nombre d'utilisateurs; beaucoup plus de visibilité dans les communautés académiques et de hackers; bénéficie d'études formelles d'anonymat, de résistance, et de performance; a un chef de file universitaire non-anonyme, visible
  • A déjà résolu certains problèmes d'échelle que I2P n'a pas eu encore à aborder
  • A un financement important
  • A davantage de développeurs, dont plusieurs sont financés
  • Plus résistant au blocage au niveau d'un État (state-level) en raison de la couche transport TLS et des ponts (I2P a des propositions pour des "routes restreintes pleines" mais celles-ci ne sont pas encore mises en œuvre)
  • Assez grand pour avoir dû s'adapter aux tentatives de blocage et de DOS
  • Conçu et optimisé pour le traffic sortant, avec un grand nombre de noeuds de sortie (exit nodes)
  • Une meilleure documentation, a des papiers et des spécifications formelles, meilleur site web, beaucoup plus de traductions
  • Plus efficace concernant l'utilisation de la mémoire
  • Les nœuds clients Tor subissent une très légère surcharge de bande passante
  • Le contrôle centralisé réduit la complexité à chaque nœud et peut répondre efficacement à des attaques Sybil
  • Un coeur de nœuds à grande capacité a la possibilité de fournir un plus haut débit tout en gardant une faible latence
  • C, pas Java

Avantages d'I2P sur Tor

  • Conçu et optimisé pour les services cachés, qui sont beaucoup plus rapide que dans Tor
  • Entièrement distribué et auto-organisé
  • Les pairs sont choisis par profilage continu et par classement de leurs performances, plutôt que de contenter de faire confiance à la capacité qu'ils revendiquent
  • Les pairs floodfill ("serveurs d'annuaire") sont variables et non éprouvés (en anglais untrusted), plutôt que codés en dur (en anglais hardcoded)
  • Tellement petit qu'il n'a pas été bloqué ni subi beaucoup de DOS, ou pas du tout
  • Pair à pair friendly
  • Commutation de paquets à la place de commutation de circuit
    • équilibrage de charge transparent et implicite des messages à travers plusieurs pairs, plutôt que par un seul chemin
    • résistance contre les défaillances, ceci par exécution de plusieurs tunnels en parallèle, ainsi que par rotation des tunnels
    • s'adapte à l'échelle des connexions de chaque client à O(1) au lieu de O(N) (Alice a par exemple 2 tunnels entrants qui sont utilisés par tous les pairs avec lesquels parle Alice, plutôt qu'un circuit pour chaque)
  • Tunnels unidirectionnels au lieu de circuits bidirectionnel, doublant le nombre de nœuds qu'un pair doit avoir à compromettre pour obtenir la même information. Counter-arguments and further discussion here.
  • Protection contre la détection d'activité du client, même quand un attaquant participe au tunnel, puisque les tunnels sont utilisés pour davantage que simplement passer des messages de bout en bout (par exemple netDb, gestion de tunnel, essais de tunnel)
  • Dans I2P les tunnels sont de courte durée de vie, ceci diminuant le nombre d'échantillons qu'un attaquant peut utiliser pour monter une attaque active avec, contrairement aux circuits dans Tor, qui ont généralement une longue durée de vie.
  • Les API de I2P sont conçues spécifiquement pour l'anonymat et la sécurité, tandis que SOCKS est conçu pour la fonctionnalité.
  • Par essence, tous les pairs participent à acheminer pour d'autres
  • Faible surcharge de bande passante d'un pair à part entière, plutôt que minime dans Tor où les nœuds ne participent pas pleinement au réseau croisé (en anglais mixnet).
  • Mécanisme intégré de mise à jour automatique
  • Utilise à la fois les transports TCP et UDP
  • Java, pas C

Autres avantages potentiels de I2P mais pas encore mis en œuvre

... et qui pourraient ne jamais être mis en œuvre, alors ne comptez pas sur eux !

  • Défense contre l'analyse du nombre de messages par enveloppement en oignon de plusieurs messages
  • Défense contre intersection long terme en ajoutant des retards à différents sauts (où les retards ne sont pas discernables par d'autres sauts)
  • Diverses stratégies de mélange au niveau du tunnel (par exemple créer un tunnel qui va gérer 500 messages / minute, dans lequel le point final va injecter des messages factices si il y a une nombre de messages insuffisant, etc)