Un certain nombre de choses que vous pouvez faire:

  1. Pensez à héberger un noeud pour aider à la croissance du réseau Tor.
  2. Informez vos amis ! Faites-leur héberger des serveurs. Faites-leur utiliser les services cachés. Encouragez-les à informer leurs propres amis.
  3. Si vous adhérez aux objectifs de Tor, prenez s'il-vous-plaît un moment pour faire un don et aider le développement futur de Tor. Nous recherchons également plus de sponsors — si vous connaissez des entreprises, des ONG, ou d'autres organisations qui veulent un anonymat,une protection de la vie privée, sécurité dans leurs communications, parlez-leur de nous.
  4. Nous sommes recherchons plus de bons exemples d'utilisateurs de Tor et des cas d'utilisation Tor. Si vous utilisez Tor dans un scénario ou le but, non encore décrits sur cette page, et vous êtes à l'aise pour le partager avec nous,nous aimerions que vous nous en parliez.

Tor a deux postes à pourvoir. Merci de nous contacter si vous êtes qualifié !

Documentation

  1. Aidez-nous à traduire le site et la documentation dans d'autres langues. Allez voir les conseils de traduction si vous souhaitez le faire. Nous avons besoin plus spécialement de personnes pour traduire en Arabe ou en Persan pour les utilisateurs Tor situés dans les zones censurées.
  2. Évaluer et documenter notre liste de programmes qui peuvent être configurés pour utiliser Tor.
  3. Nous avons toute une liste de programmes potentiellement utiles qui s'interfacent avec Tor. Lesquels sont utiles et dans quelles situations ? Contribuez à les tester et à documenter les résultats.

Plaidoyer

  1. Créer un logo communautaire sous licence Creative commons que chacun puisse utiliser et modifier
  2. Créer une présentation qui puisse être utilisée lors des nombreux meetings de groupe sur toute la planète.
  3. Créer une vidéo sur les utilisations positives de Tor, sur ce qu'est Tor ou comment l'utiliser. Quelques personnes ont déjà commencé sur le serveur Média de Tor, Howcast, et Youtube.
  4. Créer un poster ou un jeu de posters autour d'un thème tel que "Tor pour la Liberté !"

Bons Projets de code

Quelques-uns de ces projets peuvent sans doute faire de bonnes idées pour le Google Summer of Code 2010. Nous avons marqué chaque idée avec son niveau d'utilité globale pour le projet Tor (priorité), quelle quantité de travail nous attendons (niveau d'effort), avec quelles prérequis vous pouvez commencer (compétences requises) et lequel de nos développeurs de coeur de projet sont pré-sentis pour devenir tuteur. Si une (ou plus) de ces idées vous semble prometteuse, merci de nous contacter pour discuter de vos intentions plutôt que de nous envoyer une application toute faîte. Vous pouvez également nous proposer votre propre idée — ce qui conduit souvent à la meilleure application.

  1. Pack de Navigation Tor pour Mac OS X
    Priorité: Haute
    Effort à fournir: Haut
    Compétences requises: Moyennes
    Tuteurs potentiels: Steven, Erinn, Jacob, Andrew
    Le Pack de Navigation Tor contient Tor, Firefox, Polipo et l'interface graphique Vidalia (et en option le client de messagerie instantanée Pidgin). Les composants sont préconfigurés pour fonctionner de manière sécurisée et requièrent très peu de dépendances vis à vis du système d'exploitation installé. C'était autrefois un des moyens le plus facile et le plus populaire d'utiliser Tor sous Windows.
    Toutefois, il n'existe pas de paquets fonctionnant sous Mac Os X. C'est pourquoi ce projet consiste à créer un Pack de Navigation Tor sur OS X. Cela implique des modifications dans Vidalia (C++), peut-être dans Firefox (C) et enfin de créer et de tester le lanceur sur toute une gamme de versions de systèmes d'exploitation et de configuration différentes afin de vérifier la portabilité. Un peu de ce travail a été accompli lors du Google Summer of Code 2009. Une autre partie de ce projet consiste à identifier toutes les traces laissées après l'utilisation d'un Pack de Navigation sur Mac Os X ou Linux. L'étape finale consiste à trouver un moyen de stopper, de contrer ou de supprimer ces traces.
    Les étudiants désirant participer doivent connaître le développement d'applications, de préférence, sur les deux plateformes (Linux et Mac OS X) et doivent disposer de sérieuses compétences en C/C++ et en script shell.
    Une part de ce projet peut consister à tester ce Pack de Navigation sur le coeur de cible des utilisateurs concernés. Cela permettrait d'en savoir un peu plus sur ce qui a besoin d'être corrigé ou amélioré. Nous conservons cette description comme un simple élément d'information pour le moment mais un processus plus structuré serait bien meilleur.
    Une version Beta du pack de navigation pour GNU/Linux est déjà sortie mais il reste à travailler sur la partie messagerie instantanée. Ce travail est également en cours sur la version Mac OS X. Si vous désirez nous aider à améliorer la situation ou réaliser un audit sécurité sur l'un (ou l'autre) de ces projets, n'hésitez pas à contacter Erinn.
  2. Aider à mesurer l'état général du réseau Tor
    Priorité: Moyenne à Haute
    Effort à fournir: Moyen
    Compétences requises: Moyennes
    Tuteurs potentiels: Karsten, Roger
    Il serait bon de mettre en place un système automatisé pour rendre compte de la santé du réseau au cours du temps, avec des graphiques, etc... Une partie de ce projet consisterait à trouver un système de mesure adéquat pour évaluer la santé du réseau et sa croissance. Est-ce-que sa durée de fonctionnement augmente ? Combien de relais sont en cours de qualification pour adopter l'état Guard ce mois-ci comparé au mois précédent ? Comment est le turnover entre les nouveaux relais qui apparaissent et ceux qui s'éteignent ? Régulièrement, des personnes collectes de brèves photos d'état mais il est plus intéressant de le faire sur une longue période.
    Les données peuvent être collectées depuis les scanners du réseau Tor dans TorFlow, depuis les descripteurs de serveurs publiés par chaque relais et ailleurs également. Les résultats sur le long terme pourraient être présentés sur l'une des pages web de Tor Status ou éventuellement ailleurs. En parlant des pages Tor Status, prenez le temps de consulter la "whish-list" Tor Status de Roger.
  3. Réécrire TorDNSEL avec cette fois, une spécification !
    Priorité: Haute
    Effort à fournir: Moyen
    Compétences requises: Moyennes
    Tuteurs potentiels: Mike, Roger, Sebastian, Damian
    La Liste de Sortie DNS Tor (ndt: Tor DNS Exit List) est un programme en Haskell non maintenu qui a trois objectifs. Le premier est de fournir une interface DNS rbl pour les personnes qui souhaitent savoir si une adresse IP donnée est (ou a été récemment) un relais de sortie Tor. Le deuxième objectif est de construire activement des circuits dans le réseau Tor pour se reconnecter à lui-même de manière à connaître l'adresse IP réelle de sortie de chaque relais — certains relais Tor font sortir le trafic à une autre adresse que celle qui est affichée dans leur descripteur. Le troisième objectif consiste à exporter une liste de manière à ce que check.torproject.org puisse deviner si votre navigateur est configuré pour utiliser Tor.
    Ce projet utilisera TorFlow, un ensemble de scripts Python qui interagissent avec Tor pour déterminer comment notre Vérificateur de Relais de sortie Tor devrait fonctionner et donc, comment le compiler — probablement en Python car Torflow est en Python. L'objectif principal est de réduire, le plus possible, les faux positifs en étant assuré de connaître les nouveaux relais le plus rapidement possible, de s'assurer de terminer rapidement la phase de tests et que les réponses soient bien transmises au script de vérification. En bonus, il faudrait standardiser (rédiger la spécification) le format du fichier d'adresses de sortie et réécrire le script Tor Bulk Exit List de manière à utiliser ce fichier plutôt que l'horrible hack DNS qui est actuellement en vigueur. En extra-bonus, il faudrait travailler avec Freenode, OFTC et/ou les autres réseaux IRC pour être certains que les scripts réalisés sont bien ceux qu'ils attendent, en terme d'identification précise des utilisateurs issus du réseau Tor.
    Vous pouvez récupérer la dernière version de tordnsel via git.
  4. Améliorer les capacités de résistance à la censure de Tor
    Priorité: Moyenne à Haute
    Effort à fournir: Moyen à Important
    Compétences requises: Hautes
    Tuteurs potentiels: Nick, Roger, Steven
    La série 0.2.1.x de Tor a fait l'objet d'amélioration sensibles dans la résistance aux censures des États et des organisations. Néanmoins, Tor a toujours besoin de meilleurs mécanismes dans certaines parties de ses fonctionnalités anti-censure.
    Une des catégories sur laquelle il faut centrer les efforts est l'ajout de fonctionnalités à notre service Python bridgedb. Tor a pour objectif de distribuer des adresses de passerelles aux personnes qui ne peuvent accéder directement au réseau Tor. Néanmoins, il y a une course à l'échalotte entre les algorithmes de distribution d'adresses et les algorithmes de collecte et de bloquage de ces dernières. Consultez notre article de blog sur le sujet comme introduction et le message de Roger du mois de décembre sur la liste de diffusion or-dev pour plus de détails — un gros travail de spécification reste à accomplir.
    Si vous voulez mettre les mains dans le cambouis de Tor (en C), un problème moins important que nous devons gérer est le fait que Tor ne peut écouter le réseau que sur une seule combinaison adresse/port à la fois. Il existe une proposition visant à réduire cette limite et à permettre aux clients de se connecter à n'importe quel noeud Tor sur de multiples adresses et ports mais il y a besoin de plus de travail dessus.
    Ce projet implique un gros travail de recherche et de conception. Un des défis le plus important est d'identifier et de sélectionner des approches résistantes aux attaques y compris lorsque l'attaquant en connaît la conception. Il sera alors possible de conjuguer résistance à la censure avec facilité d'utilisation et robustesse.
  5. Interface de contrôle des évènements d'état de Tor
    Priorité: Moyenne
    Effort à fournir: Moyen
    Compétences requises: Faibles à Moyennes
    Tuteurs potentiels: Matt
    Il existe un grand nombre de changement d'état à l'intérieur de Tor qu'il serait bon de signaler à l'utilisateur. Par exemple, si l'utilisateur essaye de configure son noeud Tor en tant que relais et que Tor décide que ses ports ne sont pas accessibles depuis l'extérieur, l'utilisateur devrait en être averti. Actuellement, tous ce que l'utilisateur récupère sont les quelques messages de log dans la fenêtre Vidalia 'message log' qui est rarement consultée puisqu'aucun avertissement n'est notifié. Même si l'utilisateur consulte les messages de log, ces derniers sont souvent peu compréhensibles pour les novices.
    Tor a la possibilité d'informer Vidalia de ces nombreux changements d'état et nous avons récemment implémenté le support de quelques-uns d'entre-eux. Toutefois, il existe beaucoup d'autres changement d'état à notifier et nous avons besoin d'une meilleure interface pour les communiquer à l'utilisateur.
    L'objectif de ce projet est donc de concevoir et d'implémenter une interface pour notifier les évènements d'état à l'utilisateur. Par exemple, on pourrait mettre un petit badge sur l'icône de Vidalia qui alerterait l'utilisateur sur les évènement d'état qu'il doit consulter. Double-cliquer sur l'icône afficherait une fenêtre résumant les évènements récents en termes faciles à comprendre et peut-être également des suggestions pour remédier aux évènements négatifs qui pourraient être réglés par l'utilisateur. Bien entendu, c'est juste un exemple et les suggestions sont ouvertes.
    Une personne en charge de ce projet devrait avoir de solides compétences en conception et en ergonomie ainsi que de l'expérience dans le développement en C++. Une expérience avec Qt et le designer Qt serait un plus. Des capacités de rédaction en Anglais seraient appréciées car le projet implique probablement la rédaction de quelques documentations compréhensible par les utilisateurs non techniques. En bonus, des compétences graphiques permettrait de créer les belles nouvelles icônes dont nous aurons besoin.
  6. Améliorer notre processus de tests unitaires
    Priorité: Moyenne
    Effort à fournir: Moyen
    Compétences requises: Moyennes
    Tuteurs potentiels: Nick, Errin
    Tor a besoin d'être bien plus testé. Ce travail est composé de plusieurs parties. Pour commencer, notre couverture de tests unitaires devrait être plus large, spécialement du côté des fonctions utilitaires. Cela implique la refonte de certaines parties de Tor dans le but de dissocier le plus possible la logique du reste.
    Ensuite, nous devons automatiser les tests de performance. Nous avons utilisé builbot pour automatiser notre processus d'intégration et de tests de compilation (nous sommes à la recherche de quelqu'un qui pourrait le faire fonctionner sous Windows). Mais nous avons besoin de mettre à jour nos tests de simulation réseau (construits dans TorFlow) pour les versions récentes de Tor et de concevoir la mise en place d'un réseau de test soit sur une seule machine soit sur plusieurs de manière à tester automatiquement les changements de performances selon les rôles de chaque machine.
  7. Aider les implémentations de clients Tor indépendantes
    Priorité: Moyenne
    Effort à fournir: Important
    Compétences requises: Moyennes à Hautes
    Tuteurs potentiels: Karsten, Nick
    D'autres personnes travaillent en ce moment sur des clients Tor pour Java, Android et Maemo. La première étape est de vous intéresser au projet dans lequel vous désirez vous investir: Tor pour Java, Androif/Orbot ou Tor pour Maemo. Consultez les dépôts et familiarisez-vous avec le code source. De plus, nous recherchons quelqu'un qui pourrait (mais ce n'est pas requis) travailler sur l'interrogation ou même l'hébergement des services cachés Tor sur ces plateformes.
    Un développeur compétent devrait être capable de comprendre et d'écrire du code Java, y compris une API Java de chiffrement. Connaître le C serait également un vrai plus. Il faut également vouloir lire et contribuer à la documentation existante car l'implémentation du code est basée sur celle-ci. Ce projet est essentiellement un projet de code qui nécessite quelques compétences en matière de conception.
  8. Plus de développements spécifiques à Orbot & Androïd

    Priorité: Moyenne
    Effort à fournir: Important
    Niveau de compétences: Moyennes à élevées
    Tuteurs potentiels: Nathan
    Travail sur l'interface graphique Java Androïd: Écran d'accueil amélioré pour miex présenter les statistiques sur les transferts de données (entrée/sortie), nombre de circuits connectés, qualité de la connexion, etc... L'application Androïd "Tether Wifi" est un modèle à suivre car elle montre en temps réel le nombre d'octets transférés ainsi que les notifications lorsque le client wifi se connecte. De plus, il faudrait améliorer l'affichage des messages d'erreur. Enfin, l'ajout d'un assistant ou d'un tutoriel pour les novices qui leur expliquerait ce qu'est vraiment l'anonymat leur permettrait d'utiliser correctement Orbot.

    Travail sur le coeur de l'application Java Androïd: Il y a besoin d'un meilleur système d'indication, par la barre de notification, des pop-ups ou tout autre mode que le traffic d'une application circule à travers Orbot/Tor. Par exemple, vous devez consulter un site de vérification pour confirmer que votre navigateur web route bien son traffic à travers Tor. Orbot devrait être capable de notifier que les circuits ont été ouverts, utilisés, etc... Le pisteur de transfert de données mentionné ci-dessus pourrait également indiquer cette information.

    Travail de sensibilisation de la communauté sur un bibliothèque Java Android Nous devons mettre en paquet une bibliothèque simplifiée pour permettre de "Torifier" certaines applications sur les périphériques non-root (aka proxy transparent). Cette bibliothèque devrait inclure un wrapper pour la bibliothèque Apache HTTPClient, une classe pour détecter l'état de connexion d'Orbot et d'autres choses utiles pour une application Android qui aurait besoin de se rendre anonyme. Ce travail inclue la création de la bibliothèque, la documentation et un exemple de code. Le travail d'implémentation avec d'autres applications open-source suivra.

    Travail sur Android OS/C/Linux: Le portage de Tor sur Androïd est basiquement une compilation croisée sur Linux ARM. Aucun travail d'optimisation avec l'environnement matériel n'a été mené, ni sur le processeur ARM ou le matériel Android ou sur les réseaux mobiles. Malgré ce manque d'optimisation, Tor gère plutot bien l'environnement des réseaux mobiles, détecte automatiquement le changement d'adresse IP, reconnecte les circuits et gère le passage d'un réseau 2G à 3G à Wifi.
  9. Nouvelles fonctionnalités dans Torbutton
    Priorité: Moyenne
    Effort à fournir: Important
    Compétences requises: Hautes
    Tuteurs potentiels: Mike
    Il existe plusieurs demandes d'amélioration dans la section Torbutton de Flyspray. En particulier, l'intégration d'une 'Nouvelle Identité' avec Vidalia, les moyens de gérer plusieurs conteneurs de cookies par identité, la préservation de certains cookies lorsque ceux-ci sont effacés, une meilleure injection du champ referrer, une remontée correcte du statut de Tor, et la gestion des urls "tor://" et "tors://" sont toutes des fonctionnalités intéressantes qui pourraient être ajoutées.
    Ce travail devrait être réalisé en tant que code source indépendant réalisé en Javascript et en XUL sans trop interférer avec le fonctionnement interne de Tor.
  10. Simulateur pour les connexion Internet lentes
    Priorité: Moyenne
    Effort à fournir: Moyen
    Compétences requises: Moyennes
    Tuteurs potentiels: Steven
    De nombreux utilisateurs de Tor disposent de connexions à Internet de qualité médiocre avec une faible bande passante, beaucoup de latence et de nombreuses pertes ou tris de paquets. A l'usage, Tor ne se comporte pas très bien dans ces conditions mais il est difficile d'améliorer la situation sans pouvoir reproduire le problème en laboratoire.
    Ce projet consiste à élaborer un environnement de simulation d'une connection médiocre de manière à ce que l'effet sur Tor puisse être mesuré. D'autres composants à mettre en place pourraient être des utilitaires de test des propriétés des connexions disponibles pour mesurer l'effet sur les performance des modifications apportées à Tor.
    Le responsable du projet peut utiliser les outils de son choix mais dummynet (pour FreeBSD) et nisnet (pour Linux) sont deux composants sur lesquels le projet peut être construit. Les étudiants devraient avoir de l'expérience en programmation réseau et en TCP/IP, de préférence compétents en C et en langage de script.
  11. Une meilleure et plus utile carte du réseau dans Vidalia
    Priorité: Faible à Moyenne
    Effort à fournir: Moyen
    Compétences requises: Moyennes
    Tuteurs potentiels: Matt
    Une des fonctionnalités courantes de Vidalia est la carte du réseau qui montre à l'utilisateur l'emplacement approximatif des relais du réseau Tor et qui trace les chemins empruntés par le trafic qui y est injecté. La carte n'est pas très interactive pour le moment et est de médiocre qualité graphique. A la place, nous avons implémenté le widget KDE Marble pour nous donner une carte de meilleure qualité et nous permettre une meilleure interactivité tel que l'affichage des informations d'un relais ou d'un chemin lorsqu'on clique dessus. Nous voulons ajouter la possibilité pour les utilisateurs de cliquer sur un relais ou un pays contenant un ou plusieurs relais de sortie Tor et dire "Je veux que mes connexions de sortie se fasse à partir d'ici.".
    Ce projet implique d'abord d'être familiarisé avec Vidalia et l'API du widget Marble. On pourra ensuite intégrer le widget dans Vidalia et adapter Marble à notre application, comme rendre les circuits cliquables, l'enregistrement du cache des données de la carte dans le répertoire de Vidalia et l'adaptation de certaines des interfaces du widget.
    Une personne intéressée par ce projet devrait disposer d'une bonne expérience de développement en C++. Une expérience avec Qt et Cmake serait un vrai plus.
  12. Équivalent de Torbutton pour Thunderbird
    Priorité: Moyenne
    Effort à fournir: Important
    Compétences requises: Hautes
    Tuteurs potentiels: Mike
    Nous entendons parler d'un nombre de plus en plus important d'utilisateurs qui désirent utiliser Thunderbird avec Tor. Néanmoins, il y a plein de problèmes de niveau applicatifs, par exemple, par défaut Thunderbird ajoutera votre nom d'hôte au mail sortant qu'il envoie. A un certain niveau, nous devrions pousser la réalisation d'une extension Thunderbird similaire à Torbutton.
  13. Améliorer Tor Weather
    Priorité: Moyenne
    Effort à fournir: Moyen
    Compétences requises: moyennes
    Tuteurs potentiels: Christian, Roger, Damian
    Tor weather est un outil qui permet de recevoir un email indiquant le moment où le relais que vous désirez tracer s'arrête. Actuellement, il n'est pas vraiment utile pour les personnes qui utilisent la fonctionnalité d'hibernation de Tor ou pour ceux qui doivent éteindre régulièrement leur relais. Au cours du projet, Tor weather pourrait être enrichi pour permettre des configurations plus souples. D'autres améliorations sont également envisageables: Weather pourrait vous envoyer des avertissements lorsque votre relais fonctionne avec une version périmée de Tor ou lorsque votre bande passante atteint un seuil limite. Il pourrait être également un outil sympathique pour vous indiquer si votre relais vous permet d'avoir un T-Shirt ou envoyer des rappels aux autorités d'annuaire leur indiquant que leurs clefs vont bientôt expirer. Soyez créatifs et n'oubliez pas que ce projet vous permet de juger de l'état du réseau dans le but de vous aider à terminer votre travail plus rapidement ! Consultez également son README et TODO.
  14. Améliorer la mise en paquets de Tor et Vidalia sur Debian/Ubuntu
    Priorité: Moyenne
    Effort à fournir: Moyen
    Compétences requises: Moyennes
    Tuteurs potentiels: Erinn, Peter
    Vidalia ne fonctionne pas correctement avec Tor sur les plateformes Unix et Linux. En fait, sous Debian et Ubuntu, il y a un mécanisme de configuration qui permet à Vidalia d'empêcher Tor de se lancer au boot (en éditant /etc/default/tor.vidalia en indiquant RUN_DAEMON=no). Néanmoins, il y a besoin de d'implémenter complètement un ControlPort.
    Une meilleure solution sur les plateformes Linux et Unix serait d'utiliser la directive ControlSocket qui permet à Vidalia de communiquer avec Tor via une socket Unix et cela pourrait être activé par défaut dans les paquets Tor des distributions. Vidalia peut ensuite s'authentifier sur Tor en utilisant l'authentification du système de fichier (cookie) si l'utilisateur qui a lancé Vidalia est également dans le groupe spécifique à tor pour sa distribution.
    Ce projet implique d'abord le support de la directive ControlSocket dans Vidalia. L'étudiant développera et testera alors les paquets Vidalia pour de nombreuses distributions et s'assurera qu'ils fonctionnent correctement.
    Le challenge suivant sera de trouver un moyen intuitif et utilisable pour Vidalia de modifier la configuration de Tor (torrc) même s'il est situé dans /etc/tor/torrc. Sous Debian et Ubuntu, nous gérons cela avec le fichier /etc/default/tor.vidalia susmentionné, mais cette fonctionnalité pourrait être moins spécifique à ces distributions.
    La meilleure idée que nous avons trouvée jusqu'à présent est de faire passer cette configuration par le ControlSocket lorsque Vidalia démarre mais c'est une méthode discutable car si l'utilisateur n'utilise pas les derniers paquets Debian/Ubuntu de Tor, ils n'ont sans doute pas désactiver la capacité de Tor à se lancer au démarrage et ils récupéreront une configuration différente de ce qu'ils désirent. La deuxième idée consiste à faire écrire à Vidalia un fichier temporaire torrc et demander à l'utilisateur de le déplacer manuellement dans /etc/tor/torrc mais c'est également discutable car les utilisateurs ne devraient pas gérer ces fichiers directement.
    Une personne intéressée par ce projet doit disposer d'une certaine connaissance des règles d'empaquetage dans Debian et avoir une expérience en C++. Des compétences en QT seraient un vrai plus.
  15. Tests d'utilisation de Tor
    Priorité: Moyenne
    Effort à fournir: Moyen
    Compétences requises: Faibles à Moyennes
    Tuteurs potentiels: Andrew
    Spécialement le Pack de Navigation, idéalement parmi notre coeur de cible. Cela nous aiderait beaucoup à comprendre ce qui doit être réalisé en terme de correction de bugs ou de nouvelles fonctionnalités. Nous récupérons l'information de manière informelle pour le moment mais un processus plus structuré serait meilleur.
  16. Un proxy IRC d'authentification
    Priorité: Basse
    Effort à fournir: Moyen à Important
    Compétences requises: Moyennes à Hautes
    Tuteurs potentiels: Sebastian, Weasel, Roger
    Le monde entier a besoin d'un proxy IRC d'authentification. Comme nous le rappelle régulièrement la bande dessinée web Penny Arcade: "Utilisateur Internet+ anonymat = abruti". Toutefois, Tor n'a pas de problème avec les sites web car ces derniers permettent à leurs utilisateurs de connecter en utilisant des systèmes d'authentification situés à un autre niveau. Mais les serveurs IRC sont bien plus mauvais car pour la majorité d'entre-eux, le code source est écrit de manière médiocre: difficile à maintenir et plus difficile encore à modifier. De nombreux réseaux IRC bloquent maintenant les connexions depuis Tor et nous ne sommes plus acceptés que sur quasiement deux réseaux (OFTC et Freenode). Cet état signifie qu'un grand nombre de personnes dans le monde affirment "je vous l'avais bien dit" lorsqu'ils évoquent l'anonymat en ligne alors que c'est simplement dû à un manque de technologie pour rendre le problème gérable. Nous avons besoin d'un moyen pour les réseaux IRC de distinguer quels sont les utilisateurs qui ont prouvé leur réputation et qui sont les abrutis, de manière à bien séparer les deux. Il existe quels concepts de recherche comme Nymble qui permet aux sites web de blacklister les utilisateurs sans avoir besoin de connaître leur identité. Mais Nymble est conçu pour les interactions sur le web. Nous avons besoin de féderer nos efforts sur le protocole IRC afin de monter un projet semblable à Nymble (ou un plus simple pour démarrer en tant que preuve de concept). Un des moyens d'y parvenir serait de construire un proxy IRC sachant comment écouter les clients IRC et comment parler aux serveurs IRC et bien sûr qui disposerait d'une couche permettant aux utilisateurs de s'authentifier. Quelques travaux sur ce sujet ont été initiés par d'autres contributeurs; vous pouvez consultezr leurs progrès sur http://github.com/anonirc/orc.
  17. Faire fonctionner torsocks/dsocks sur OS X
    Priorité: Moyenne
    Effort à fournir: Moyen
    Compétences requises: Moyennes
    Tuteurs potentiels: ?
    Torsocks et dsocks sont des wrappers qui fonctionnent avec des applications, en interceptent leurs connexions réseau sortantes et les injectent dans Tor. L'objectif est de gérer les applications qui ne supportent pas les proxy (ou qui ne les supportent pas correctement). Ces wrappers doivent intercepter de nombreux appels systèmes. Ces appels systèmes sous Linux sont complètement différents de ceux de BSD. Ainsi, torsocks fonctionne bien sous Linux, dsocks fonctionne bien sous BSD (bien qu'il soit moins bien maintenu et qu'il puisse rater davantage d'appels systèmes) mais rien ne fonctionne bien sur les deux systèmes. D'abord, il faut patcher dsocks pour qu'il utilise les commandes de mapadress depuis l'interface de contrôle de manière à ne pas perdre trop de temps pendant la résolution qui s'effectue dans Tor avant la connexion. Ensuite, notre script torify doit détecter si tsocks ou dsocks est installé et appelé celui qui est légitime. Cela implique d'unifier l'interface de ces deux wrappers et peut-être de partager du code entre eux ou bien d'en laisser tomber un des deux.
  18. Amener de nouvelles idées !
    Vous n'aimez aucune de celles qui sont présentées ? Consultez la feuille de route de développement pour vous donner d'autres idées ou bien essayez simplement Tor, Vidalia et Torbutton pour trouver quelles sont les points à améliorer. Quelques-unes des propositions en cours ont également besoin de développeurs.

Autres idées de spécifications et de code

  1. Les relais Tor ne fonctionnent pas parfaitement sur Windows XP. Sous Windows, Tor utilise l'appel système standard select(), qui utilise l'espace non paginé dans le pool. Ce qui implique que les serveurs de taille moyenne vont vider l'espace non paginé, provoquant l'instabilité et le plantage du système. Nous devrions probablement utiliser des E/S recouvrables à la place. Une solution pourrait-être d'apprendre à la libevent comment utiliser les E/S recouvrables à la place de select() sous Windows, et alors d'adapter Tor à la nouvelle interface libevent. Christian King à bien démarré sur ce point l'été 2007.
  2. Nous avons besoin maintenant de commencer l'élaboration de notre conception de résistance au blocage. Ceci implique une refonte de la conception, une modification de différents aspects de Tor, une adaptation de Vidalia pour qu'il supporte les nouvelles fonctionnalités, et planifier le deploiement.
  3. Nous avons besoin d'un ensemble d'outils flexibles de simulation pour étudier de bout en bout les trafics de confirmation d'attaque. Beaucoups de chercheurs ont conçu des simulateurs ad hoc pour confirmer leurs intuitions comme quoi soit l'attaque marche vraiment bien ou que les défenses fonctionnent. Pouvons nous construire un simulateur qui soit clairement documenté et suffisament ouvert pour que tout le monde sache qu'il donne une réponse raisonnable ? Ceci stimulera un grand nombre de nouvelles recherches. Voyez l'entrée suivante sur les confirmations d'attaque pour les détails sur le coté recherche de cette tâche — qui sait, quand ceci sera fait peut-être pourrez aider en écrivant un rapport ou deux.
  4. Tor 0.1.1.x inclut le support d'accélérateurs matériels de chiffrage via OpenSSL. Cependant, personne ne l'a jamais testé. Est-ce que quelqu'un voudrait se procurer une carte et nous dire ce qu'il en est ?
  5. Faire une analyse de sureté de Tor avec du "fuzz". Déterminer s'il existe déjà de bonnes bibliothèques de fuzz pour ce que nous voulons faire. La célébrité pour celui grâce à qui une nouvelle version pourra voir le jour !
  6. Tor utilise TCP pour le transport et TLS pour le chiffrage des liens. C'est simple et efficace, mais cela implique que toutes les unités (cellules) d'un lien sont mises en attente lorsqu'un seul paquet est perdu, et cela signifie que seuls des flux TCP peuvent être raisonnablement supportés. Nous avons dressé une liste de raisons pour lesquelles nous n'avons pas bifurqué vers le transport par UDP, mais ce serait bien de voir cette liste se raccourcir. Nous avons aussi proposé une spécification pour Tor et UDP — lisez-la et faites-nous part de vos remarques et critiques, s'il-vous-plaît.
  7. Nous ne sommes plus très loin d'avoir le support pour IPV6 entre les serveurs de sorties et les adresses finales. Si IPV6 vous tient à cœur, partir de là est sans doute un premier pas.
  8. Nous avons besoin de générer les diagrammes du site web (par exemple les images de "Comment fonctionne Tor ?" sur la page d'aperçu à partir d'une source de manière à pouvoir les traduire comme du texte UTF-8 plutôt que de les modifier à la main avec un éditeur d'image. Nous voudrions intégrer ce processus dans un fichier wml pour faciliter les traductions et regénérer les images en plusieurs langues lorsque nous construisons le site web.
  9. Comment pouvons-nous maintenir, améliorer et documenter plus facilement les différents systèmes LiveCD/USB ? Le système Live (Amnesic) est un bon exemple.
  10. Un autre projet anti-censure est de rendre Tor plus résistant au scans réseaux. Pour le moment, un attaquant peut identifier les passerelles Tor en essayant simplement de se connecter à elles en utilisant le protocole Tor pour vérifier si elles répondent. Pour régler ce problème, les passerelles pourraient agir comme des serveurs webs (HTTP ou HTTPS) lorsqu'elles sont contactées par des outils de scan de port et agir comme des passerelles uniquement lorsque l'utilisateur aura amené une clef spécifique. Pour commencer, consultez la thèse et le prototype de Shane Pope.

Recherche

  1. "L'attaque par corrélation des trafics aux extrémités": par l'observation des trafics de Alice et Bob, il est possible de comparer les signatures des trafics et d'en déduire qu'il s'agit du même flux. Jusqu'ici, Tor considère ce type d'attaque comme intrinsèque et donc inévitable. Tout d'abord, est-ce réellement vrai ? Quelle quantité de trafic - et avec quelle distribution - est-elle nécessaire pour que l'adversaire soit certain d'avoir gagné ? Est-ce qu'il existe des scénarios (par exemple avoir un trafic faible) pour ralentir cette attaque ? Est-ce que certains types de remplissage ou de modelage de trafic fonctionnent mieux que d'autres ?
  2. On peut relier la question qui vient: Est-ce-que le fait de faire tourner un relais/passerelle offre une protection supplémentaire contre ces attaques basées sur les timings ? Un attaquant externe qui ne peut voir l'intérieur des flux TLS peut-il reconnaître de manière fiable les flux individuels ? Est-ce-que le volume de trafic transféré dégrade cette possibilité ? Que faire si le relais du client retarde délibérément le trafic montant pour former une queue pouvant être utilisée pour mimer les timings du trafic descendant du client pour le faire passer pour du trafic egalement relayé ? Cette queue identique pourrait être également utilisée pour masquer les temps du trafic montant du client à l'aide des techniques dites adaptative padding sans avoir besoin de trafic supplémentaire. Est-ce-qu'un tel entrelacement du trafic montant du client osbcurcit les temps pour des attaquants externes ? Les stratégies doivent-elles être ajustées pour les liens symétriques ? Ou bien est-ce plus évident que pour les liens symétriques ?
  3. L'attaque d'Oakland 05 par Repeat Murdoch et Danezi sur le réseau Tor acutel. Essayez de comprendre pourquoi elle fonctionne bien sur certains noeuds et pas sur les autres. (Ma théorie est que les noeuds rapides avec davantage de capacité résistent mieux à l'attaque). On peut expérimenter cette attaque avec la gestion des options RelayBandwithRate et RelayBandwithBurst pour faire tourner un relais utilisé comme client tout en relayant le traffic de l'attaquant: si nous limitons fortement le RelayBandwithRate, est-ce-que l'attaque est plus difficile ? Quel est le ratio correct de RelayBandwithRate par rapport à la capacité ? D'ailleurs, est-ce-que le ratio joue un rôle dans cette attaque ? Pendant qu'on y est, est-ce-qu'un plus grand nombre de relais candidats augmente le taux de faux positifs ou une autre complexité dans l'attaque ? (Le réseau Tor est maintenant deux fois plus étendu qu'il ne l'était au moment de la rédaction de leur papier). Prenez également le temps de consulter le document Don't Clog the Queue.
  4. L'attaque "routing zones": la majorité de ce qui est écrit sur Tor modélise le chemin réseau entre Alice et son noeud d'entrée (et entre Bob et le noeud de sortie) comme un simple lien sur un graphe. En pratique, le chemin traverse de nombreux systèmes automomes (SA) et il n'est pas rare que le même SA apparaissent à la fois sur le chemin d'entrée comme sur le chemin de retoure. Malheureusement, pour être sûr de prédire si un quartet Alice, noeud d'entrée, noeud de sortie, Bob sera dangereux, il faut télécharger entièrement une zone de routage Internet et effectuer de couteuses opérations dessus. Existe-t-il des approximations pratiques comme éviter les adresse IP situées dans le même réseau /8 ?
  5. D'autres points de recherche se pose la question de savoir, d'un point de vue diversité géographique, s'il est mieux d'avoir un circuit efficace ou de choisir un circuit au hasard. Consultez les travaux de Stephen Rollyson qui expliquent comment éviter les choix particulièrement inefficaces sans "trop" compromettre l'anonymat. Cet angle d'attaque a besoin d'être creusé et travaillé mais il a l'air très prometteur.
  6. Tor ne fonctionne pas bien lorsque les relais disposent d'une bande passante asymétrique (ex: câble ou ADSL). Etant donné que Tor sépare les connexions entre chaque hop, si les octets entrants arrivent trop vite et que du coup, les octets sortants arrivent plus lentement, les mécanismes de push-back de TCP ne retournent pas cette information aux flux entrants. Peut-être que Tor devrait détecter les rejets de paquets sortants et réguler les flux entrants de lui-même ? J'imagine un schéma d'ouverture/fermeture où l'on récupère un taux de transfert limite donné qu'on incrémente lentement jusqu'à perdre des paquets, moment où l'on diminuerait le taux, etc... Nous avons besoin de quelqu'un disposant de sérieuses compétences réseau pour simuler cela et apporter son aide pour la mise en place de ces fonctionnalités. Nous avons besoin de comprendre l'importance de la dégradation des performances et de l'utiliser comme élément moteur en vue de reconsidérer le transport par UDP.
  7. Le contrôle de la congestion est un sujet proche. Est-ce-que notre spécification permet de gérer les fortes charges ? Peut-être devrions-nous expérimenter des fenêtres de tailles variables plutôt que des fenêtres fixes ? Cela semble prometteur dans cette expérimentation autour de ssh. Nous avons besoin de mesurer, de corriger et peut-être de refondre quelquechose si les résultats s'avèrent bons.
  8. Nos objectifs de résistance à la censure incluent l'impossibilité pour un attaquant qui observe le trafic Tor de le distinguer d'un trafic SSL normal. Néanmoins, nous ne pouvons pas recréer une stéganographie parfaite tout en restant utilisable mais, dans un premier temps, nous aimerions pouvoir bloquer toute attaque qui pourrait réussir en observant quelques paquets seulement. Une des attaques qu'il nous reste à examiner est basée sur le fait que les paquets Tor font 512 octets et que par conséquence, les paquets du trafic réseau sont également des multiples de 512 octets. En quoi le fait de modifier les enregistrements TLS et leur en-tête pourrait brouiller ce trafic ? Différentes stratégies de fermeture de tampon dans Tor peuvent-elles avoir un impact sur ce sujet ? Est-ce-qu'un peu de remplissage ferait l'affaire ou bien est-ce-une attaque que nous pouvons accepter ?
  9. Les circuits Tor sont construit pas à pas. Ainsi, il est théoriquement possible de faire sortir des flux à partir du second pas, d'autres à partir du troisième et ainsi de suite. Cela semble une alternative séduisante car elle permet de passer outre la limite en sortie de chaque relais. Mais si nous voulons que chaque flux soit sécurisé, le chemin "le plus court" doit obligatoirement avoir au moins 3 pas selon notre logique actuelle. Nous devons examiner cette alternative sur l'aspect performance en balance de la sécurité
  10. Il n'est pas si difficile de faire du dénis de service sur les relais Tor ou les autorités d'annuaire. Les clients forment-ils la meilleure réponse ? Quelles sont les autres approches possibles ? Il serait bien qu'elles soient compatibles avec le protocole Tor actuel.
  11. Les programmes tels que Torbutton ont pour objectif de masquer le champ UserAgent de votre navigateur web en le replaçant par une réponse uniforme pour tous les utilisateurs Tor. Ainsi, un attaquant ne peut rien déduire de vous en regardant cet en-tête. Il essaye de récupérer une chaîne communément utilisée par les utilisateurs non-Tor. Première question: comment révélons-nous l'utilisation de Tor en mettant à jour régulièrement ce champ ? Si nous le mettons à jour trop souvent, nous supprimons nous-même de l'anonymat. Si nous ne le mettons pas à jour souvent alors tous les utilisateurs de Tor se dévoileront car leur navigateur web indiquera qu'ils utilisent tous une assez vieille version de Firefox. La réponse à la question dépend certainement des versions de Firefox utilisés dans la nature. Deuxième question: régulièrement, les gens nous demande de modifier le champ UserAgent selon un cycle de N chaînes de caractères différentes plutôt que de mettre toujours la même. Est-ce-que cette approche est vraiment utile, malfaisante ou neutre ? A prendre en considération: les cookies et le fait de reconnaître les utilisateurs de Torbutton par leur rotation de UserAgents; les sites webs malicieux qui n'attaque qu'un seul type de navigateur web; la réponse à la question un impact la réponse à la question deux.
  12. Actuellement, les clients Tor réutilisent un circuit donné pendant les dix minutes qui suivent sa première utilisation. L'objectif est d'éviter de surcharger le réseau avec des opérations de circuits étendus et également pour éviter que les clients utilisent le même circuit pendant trop longtemps ce qui permettrait au noeud de sortie de les profiler. Hélas, dix minutes est une période de temps sans doute trop longue, spécialement si des connexions vers des protocoles différents (ex messagerie instantanée et navigation internet) utilisent le même circuit. Si nous continuons à fixer le nombre global de la taille des circuits que le réseau a besoin d'établir, existe-t-il de meilleurs et/ou de plus sûrs moyens pour les clients d'affecter des flux aux circuits ou bien pour que les clients construisent des circuits préemptifs ? Peut-être que cet élément de recherche doit commencer par récupérer des traces sur les connexions typiques que les clients initient afin de disposer de données réalistes ?
  13. De combien de passerelles avez-vous besoin pour maintenir un bon niveau d'accessibilité ? Nous devrions mesurer le contenu de nos passerelles. Si ce contenu est bien fourni, existe-t-il des moyens de faire en sorte que les utilisateurs de passerelles restent connectés plus longtemps ?

Contactez-nous si vous avez avancé sur ces points !


"Tor" et le Logo Onion sont des marques déposées du Projet Tor, Inc.

Attention: Cette traduction peut être obsolète. La version anglaise originale est la 23009 alors que la version traduite est basée sur la (unknown).

Cette page est aussi disponible dans les langues suivantes : English, polski, Русский (Russkij).
Comment configurer la langue par défaut du document.

Les développeurs de Tor n'ont pas revu cette traduction en ce qui concerne la pertinence et l'exactitude. Elle peut être obsolète ou fausse. La version officielle du site web Tor est la version anglaise, disponible sur https://www.torproject.org/.

Webmaster - Dernière modification : Mon Aug 30 12:53:12 2010 - Dernière mise à jour : Wed Sep 1 08:33:58 2010