tor-webwml.git

1) 
2) 

3) 
4) 
5) 
6) 
7) ## translation metadata
8) # Revision: $Revision$
9) # Translation-Priority: 4-optional
10) #include "head.wmi" TITLE="Tor: Volunteer" CHARSET="UTF-8"

11) <div class="main-column">
12) 

13) 

14) <!-- PUT CONTENT AFTER THIS TAG -->

15) <h2>Un certain nombre de choses que vous pouvez faire:</h2>

16) <ol>

17) <li>Pensez à <a href="<page docs/tor-doc-relay>">héberger un noeud</a> pour
18) aider à la croissance du réseau Tor.</li>
19) <li>Informez vos amis ! Faites-leur héberger des serveurs. Faites-leur utiliser
20) les services

21) cachés. Encouragez-les à informer leurs propres amis.</li>

22) <li>Si vous adhérez aux objectifs de Tor, prenez s'il-vous-plaît un moment <a
23) href="<page donate>">pour faire un don et aider le développement futur de
24) Tor</a>. Nous recherchons également plus de sponsors &mdash; si vous
25) connaissez des entreprises, des ONG, ou d'autres organisations qui veulent
26) un anonymat,une protection de la vie privée, sécurité dans leurs
27) communications, parlez-leur de nous.</li>
28) <li>Nous sommes recherchons plus <a href = "<page torusers>"> de bons exemples
29) d'utilisateurs de Tor et des cas d'utilisation Tor</a>. Si vous utilisez Tor
30) dans un scénario ou le but, non encore décrits sur cette page, et vous êtes
31) à l'aise pour le partager avec nous,nous aimerions que vous nous en parliez.</li>

32) </ol>
33) 

34) <p>Tor a <a href="<page open-positions>">deux postes à pourvoir</a>, merci de
35) <a href="<page contact>">nous contacter</a> si vous êtes qualifié !</p>
36) 

37) <a id="Usability"></a>

38) <h2><a class="anchor" href="#Usability">Support d'applications</a></h2>

39) <ol>

40) <li>Nous avons besoin de méthodes plus efficaces d'interception des requêtes
41) DNS, pour qu'elles ne laissent pas transparaître d'informations à un
42) observateur local pendant que nous tentons d'être anonymes. (Ce qui arrive
43) lorsque l'application fait sa résolution DNS avant de passer par le proxy
44) SOCKS.)</li>
45) <li>Éléments tsocks/dsocks:

46) <ul>

47) <li>Nous devrions patcher le programme « dsocks » développé par Dug Song pour
48) utiliser les commandes <i>mapaddress</i> de Tor depuis l'interface de
49) contrôle, de manière à ne pas faire inutilement un aller-retour complet dans
50) Tor pour faire la résolution avant la connexion.</li>
51) <li>Notre script <i>torify</i> doit détecter lequel de tsocks ou dsocks est
52) installé pour l'appeler correctement. Cela nécessite certainement d'unifier
53) leurs interfaces, et peut amener à faire un mix des deux voire à en éliminer
54) un des deux.</li>

55) </ul>

56) </li>

57) <li>Les gens qui hébergent des serveurs nous signalent qu'ils aimeraient avoir
58) une passante allouée durant une partie de la journée, et une autre bande
59) passante à d'autre moment de la journée.Plutôt que de coder ceci dans Tor,
60) nous aimerions utiliser un petit script qui communique avec <a href="<page
61) gui/index>">l'interface de contrôle de Tor</a>, et ferait un setconf pour
62) changer la valeur de la bande passante. Il en existe dejà un pour Unix et
63) Mac (qui utilise bash et cron), mais les utilisateurs de Windows ont encore
64) besoin d'une solution.
65) </li>
66) <li>En parlant de géolocalisation, quelqu'un devrait faire une carte de la Terre
67) indiquant chaque serveur Tor par un point. La cerise sur le gâteau serait la
68) mise à jour dynamique de la carte à mesure que le réseau Tor évolue et
69) grandit. Malheureusement, les moyens aisés de faire cela passent par l'envoi
70) de toutes les données à Google pour qu'il trace cette carte pour vous. Dans
71) quelle mesure cela jouerait-il sur la confidentialité, et par ailleurs,
72) existe-t-il des solutions de remplacement valables ?</li>
73) </ol>
74) 
75) <a id="Advocacy"></a>
76) <h2><a class="anchor" href="#Advocacy">Plaidoyer</a></h2>
77) <ol>
78) <li>Créer un <a href="https://wiki.torproject.org/noreply/CommunityLogos">logo
79) communautaire</a> sous licence Creative commons que chacun puisse utiliser
80) et modifier</li>
81) <li>Créer une présentation qui puisse être utilisée lors des nombreux meetings
82) de groupe sur toute la planète.</li>
83) <li>Créer une vidéo sur les utilisations positives de Tor, sur ce qu'est Tor ou
84) comment l'utiliser.  Quelques personnes ont déjà commencé sur <a
85) href="http://media.torproject.org/video/">le serveur Média de Tor</a>, <a
86) href="http://www.howcast.com/videos/90601-How-To-Circumvent-an-Internet-Proxy">Howcast</a>,
87) et <a href="http://www.youtube.com/freedom4internet">Youtube</a>.</li> 
88) <li>Créer un poster ou un jeu de posters autour d'un thème tel que "Tor pour la
89) Liberté !"</li>

90) </ol>
91) 
92) <a id="Documentation"></a>
93) <h2><a class="anchor" href="#Documentation">Documentation</a></h2>
94) <ol>

95) <li>Aidez Matt Edman à documenter et à écrire des tutoriaux pour son contrôleur
96) Tor, <a href="<page vidalia/index>">Vidalia</a>.</li>
97) <li>Évaluez et documentez <a
98) href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">notre

99) liste de programmes</a> pouvant être utilisés avec Tor.</li>

100) <li>Nous avons besoin d'une meilleure documentation traitant de l'interception
101) dynamique de connexions et de leur envoi à travers Tor. tsocks (Linux),
102) dsocks (BSD), et freecap (Windows) semblent être de bons candidats, et
103) utiliserait au mieux notre nouvelle fonctionnalité Transport.</li>
104) <li>Nous avons toute une liste de <a
105) href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">programmes
106) potentiellement utiles qui s'interfacent avec Tor</a>. Lesquels sont utiles
107) et dans quelles situations ? Contribuez à les tester et à documenter les
108) résultats.</li>
109) <li>Aidez-nous à traduire le site et la documentation dans d'autres
110) langues. Allez voir les <a href="<page translation>">conseils de
111) traduction</a> si vous souhaitez le faire. Nous avons besoin plus
112) spécialement de personnes pour traduire en Arabe ou en Persan pour les
113) utilisateurs Tor situés dans les zones censurées.</li>

114) </ol>
115) 

116) <a id="Coding"></a> <a id="Summer"></a> <a id="Projects"></a>
117) <h2><h2><a class="anchor" href="#Projects">Bons Projets de code</a></h2></h2>

118) 

119) <p>
120) Quelques-uns de ces projets peuvent sans doute faire de bonnes idées pour le
121) <a href="<page gsoc>">Google Summer of Code 2010</a>. Nous avons 
122) </p>

123) 

124) <ol>

125) 

126) <li>

127) <b>Pack de Navigation Tor pour Linux/Mac OS X</b> <br /> Priorité:
128) <i>Haute</i> <br /> Effort à fournir: <i>Haut</i> <br /> Compétences
129) requises: <i> Moyennes</i> <br /> Tuteurs potentiels: <i>Steven, Erinn,
130) Jacob, Andrew</i> <br /> Le Pack de Navigation Tor contient Tor, Firefox,
131) Polipo et l'interface graphique Vidalia (et en option le client de
132) messagerie instantanée <a href="http://pidgin.im/">Pidgin</a>). Les
133) composants sont préconfigurés pour fonctionner de manière sécurisée et
134) requièrent très peu de dépendances vis à vis du système d'exploitation
135) installé. C'était autrefois un des moyens les plus faciles et le plus
136) populaire d'utiliser Tor sous Windows.  <br /> Toutefois, il n'existe pas de
137) paquets fonctionnant sous Linux ou Mac Os X. C'est pourquoi ce projet
138) consiste à créer un Pack de Navigation Tor sur ces plateformes. Cela
139) implique des modifications dans Vidalia (C++), peut-être dans Firefox (C) et
140) enfin de créer et de tester le lanceur sur toute une gamme de versions de
141) systèmes d'exploitation et de configuration différentes afin de vérifier la
142) portabilité. Un peu de ce travail a été accompli lors du Google Summer of
143) Code 2009. <br /> Les étudiants désirant participer doivent connaître le
144) développement d'applications, de préférence, sur les deux plateformes (Linux
145) et Mac OS X) et doivent disposer de sérieuses compétences en C/C++ et en
146) script shell.  <br /> Une part de ce projet peut consister à tester ce Pack
147) de Navigation sur le coeur de cible des utilisateurs concernés. Cela
148) permettrait d'en savoir un peu plus sur ce qui a besoin d'être corrigé ou
149) amélioré. Nous conservons cette description comme un simple élément
150) d'information pour le moment mais un processus plus structuré serait
151) meilleur.

152) </li>
153) 
154) <li>

155) <b>Aider à mesurer l'état général du réseau Tor</b> <br /> Priorité:
156) <i>Moyenne à Haute</i> <br /> Effort à fournir: <i>Moyen</i> <br />
157) Compétences requises: <i>Moyennes</i> <br /> Tuteurs potentiels: <i>Karsten,
158) Roger</i> <br /> Il serait bon de mettre en place un système automatisé pour
159) rendre compte de la santé du réseau au cours du temps, avec des graphiques,
160) etc... Une partie de ce projet consisterait à trouver un système de mesure
161) adéquat pour évaluer la santé du réseau et sa croissance. Est-ce-que sa
162) durée de fonctionnement augmente ? Combien de relais sont en cours de
163) qualification pour adopter l'état Guard ce mois-ci comparé au mois précédent
164) ? Comment est le turnover entre les nouveaux relais qui apparaissent et ceux
165) qui s'éteignent ? Régulièrement, des personnes collectes de brèves photos
166) d'état mais il est plus intéressant de le faire sur une longue période.  <br
167) ./> Les données peuvent être collectées depuis les scanners du réseau Tor
168) dans <a
169) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>,
170) depuis les descripteurs de serveurs publiés par chaque relais et ailleurs
171) également. Les résultats sur le long terme pourraient être présentés sur
172) l'une des pages web de <a href="https://torstatus.blutmagie.de/">Tor
173) Status</a> ou éventuellement ailleurs. En parlant des pages Tor Status,
174) prenez le temps de consulter <a
175) href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">la
176) "whish-list" Tor Status</a> de Roger.

177) </li>
178) 
179) <li>

180) <b>Améliorer les capacités de résistance à la censure de Tor</b> <br />
181) Priorité: <i>Moyenne à Haute</i> <br /> Effort à fournir: <i>Moyen</i> <br
182) /> Compétences requises: <i>Hautes</i> <br /> Tuteurs potentiels: <i>Nick,
183) Roger, Steven</i> <br /> La série 0.2.1.x de Tor a fait l'objet <a
184) href="<gitblob>doc/design-paper/blocking.html">d'amélioration sensibles</a>
185) dans la résistance aux censures des États et des organisations.  Néanmoins,
186) Tor a toujours besoin de meilleurs mécanismes dans certaines parties de ses
187) fonctionnalités anti-censure.  Par exemple, Tor ne peut écouter le réseau
188) que sur une seule combinaison adresse/port à la fois.  Il existe <a
189) href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">une proposition
190) visant à réduire cette limite</a> et permettre aux clients de se connecter à
191) n'importe quel noeud Tor sur de multiples adresses et ports mais il y a
192) besoin de plus de travail dessus.  Un autre projet anti-censure est
193) d'essayer de rendre Tor plus résistant au scans.  Actuellement, un attaquant
194) peut identifier <a href="<gitblob>doc/spec/proposals/125-bridges.txt">les
195) passerelles Tor</a> simplement en essayant de s'y connecter, en suivant le
196) protocole Tor et voir si elles répondent.  Pour régler ce problème, les
197) passerelles pourraient <a
198) href="<gitblob>doc/design-paper/blocking.html#tth_sEc9.3">simuler des
199) serveurs web</a> (HTTP ou HTTPS) lorsqu'elles sont contactées par des outils
200) de scans de port et ne pas répondre en tant que passerelle Tor avant que
201) l'utilisateur ne lui ait fourni une clef spécificque.  <br /> Ce projet
202) implique un gros travail de recherche et de conception. Un des défis le plus
203) important est d'identifier et de sélectionner des approches résistantes aux
204) attaques y compris lorsque l'attaquant en connaît la conception. Il sera
205) alors possible de conjuguer résistance à la censure avec facilité
206) d'utilisation et robustesse.

207) </li>

208) 

209) <li>

210) <b>Tuner Tor !</b> <br /> Priorité: <i>Moyenne à Haute</i> <br /> Effort à
211) fournir: <i>Moyen à Important</i> <br /> Compétences requises: <i>Hautes</i>
212) <br /> Tuteurs potentiels: <i>Nick, Roger, Mike, Karsten</i> <br />Pour le
213) moment, les relais Tor mesurent et remontent leur propre bande passante, les
214) clients choisissent quels relais ils vont utiliser en partie selon cette
215) bande passante.  Cette approche présent des vulnérabilités <a
216) href="http://freehaven.net/anonbib/#bauer:wpes2007">aux attaques dans
217) lesquelles le relais ment sur sa bande passante</a>. Pour régler ce
218) problème, Tor plafonne la bande passante maximale affichée par un relais.
219) C'est une correction limitée et une perte de bande passante.  A la place,
220) Tor devrait mesure la bande passante selon un mode distribué, peut-être
221) comme décrit dans le document <a
222) href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
223) Tor"</a> de Snader et Borisov. On pourrait utiliser du code source en test
224) pour confirmer les trouvailles de ce document et vérifier la manière dont
225) elles concordent avec le fonctionnement réel de Tor. On pourrait trouver les
226) bons moyens d'incorporer ces suggestions dans le réseau Tor sans ajouter
227) trop de trafic entre les relais et les autorités d'annuaire.

228) </li>

229) 

230) <li>

231) <b>Améliorer Polipo sous Windows</b> <br /> Priorité: <i>Moyenne à Haute</i>
232) <br /> Effort à fournir: <i>Moyen</i> <br /> Compétences requises:
233) <i>Moyennes</i> <br /> Tuteurs potentiels: <i>Chris</i> <br />Il faut nous
234) aider à porter <a
235) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> sous
236) Windows. Quelques exemples de sujets à retenir:
237) <ol><li> la possibilité d'interroger de manière asynchrone les serveurs de noms,
238) trouver les serveurs de noms utilisés par le système et gérer les requêtes
239) netbios et dns.</li>
240) <li> gérer nativement les tampons et les évènement (i.e. sous les OS de type
241) Unix, Polipo occupe 25% de la ram, sous Windows, c'est selon la
242) configuration).</li>
243) <li> un outil graphique de configuration et de rapport, avec en bonus, une icône
244) de barre système avec un menu d'option par clic-droit. Double-bonus si c'est
245) multiplateforme.</li>
246) <li> permettre au logiciel d'utiliser le registre Windows et de gérer
247) correctement les emplacements de répertoire Windows tels que "C:\Program
248) Files\Polipo"</li>
249) </ol>

250) </li>

251) 

252) <li>

253) <b>Interface de contrôle des évènements d'état de Tor</b> <br /> Priorité:
254) <i>Moyenne</i> <br /> Effort à fournir: <i>Moyen</i> <br /> Compétences
255) requises: <i>Faibles à Moyennes</i> <br /> Tuteurs potentiels: <i>Matt</i>
256) <br /> Il existe un grand nombre de changement d'état à l'intérieur de Tor
257) qu'il serait bon de signaler à l'utilisateur. Par exemple, si l'utilisateur
258) essaye de configure son noeud Tor en tant que relais et que Tor décide que
259) ses ports ne sont pas accessibles depuis l'extérieur, l'utilisateur devrait
260) en être averti. Actuellement, tous ce que l'utilisateur récupère sont les
261) quelques messages de log dans la fenêtre Vidalia 'message log' qui est
262) rarement consultée puisqu'aucun avertissement n'est notifié. Même si
263) l'utilisateur consulte les messages de log, ces derniers sont souvent peu
264) compréhensibles pour les novices.  <br /> Tor a la possibilité d'informer
265) Vidalia de ces nombreux changements d'état et nous avons récemment
266) implémenté le support de quelques-uns d'entre-eux. Toutefois, il existe
267) beaucoup d'autres changement d'état à notifier et nous avons besoin d'une
268) meilleure interface pour les communiquer à l'utilisateur.  <br /> L'objectif
269) de ce projet est donc de concevoir et d'implémenter une interface pour
270) notifier les évènements d'état à l'utilisateur. Par exemple, on pourrait
271) mettre un petit badge sur l'icône de Vidalia qui alerterait l'utilisateur
272) sur les évènement de status qu'il doit consulter. Double-cliquer sur l'icône
273) afficherait une fenêtre résumant les évènements récents en termes faciles à
274) comprendre et peut-être également des suggestions pour remédier aux
275) évènements négatifs qui pourraient être réglés par l'utilisateur. Bien
276) entendu, c'est juste un exemple et les suggestions sont ouvertes.  <br ./>
277) Une personne en charge de ce projet devrait avoir de solides compétences en
278) conception et en ergonomie ainsi que de l'expérience dans le développement
279) en C++. Une expérience avec Qt et le designer Qt serait un plus. Des
280) capacités de rédaction en Anglais seraient appréciées car le projet implique
281) probablement la rédaction de quelques documentations compréhensible par les
282) utilisateurs non techniques. En bonus, des compétences graphiques
283) permettrait de créer les belles nouvelles icônes dont nous aurons besoin.

284) </li>

285) 

286) <li>

287) <b>Améliorer notre processus de tests unitaires</b> <br /> Priorité:
288) <i>Moyenne</i> <br /> Effort à fournir: <i>Moyen</i> <br /> Compétences
289) requises: <i>Moyennes</i> <br /> Tuteurs potentiels: <i>Nick, Roger</i> <br
290) /> Tor a besoin d'être bien plus testé. Ce travail est composé de plusieurs
291) parties. Pour commencer, notre couverture de tests unitaires devrait être
292) plus large, spécialement du côté des fonctions utilitaires. Cela implique la
293) refonte de certaines parties de Tor dans le but de dissocier le plus
294) possible la logique du reste.  <br /> Ensuite, nous devons automatiser les
295) tests de performance. Nous avons utilisé builbot pour automatiser notre
296) processus d'intégration et de tests de compilation (nous sommes à la
297) recherche de quelqu'un qui pourrait le faire fonctionner sous Windows). Mais
298) nous avons besoin de mettre à jour nos tests de simulation réseau
299) (construits dans <a
300) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>) pour
301) les versions récentes de Tor et de concevoir la mise en place d'un réseau de
302) test soit sur une seule machine soit sur plusieurs de manière à tester
303) automatiquement les changements de performances selon les rôles de chaque
304) machine.

305) </li>

306) 

307) <li>

308) <b>Aider les implémentations de clients Tor indépendantes</b> <br />
309) Priorité: <i>Moyenne</i> <br /> Effort à fournir: <i>Important</i> <br />
310) Compétences requises: <i>Moyennes à Hautes</i> <br /> Tuteurs potentiels:
311) <i>Karsten, Nick</i> <br /> D'autres personnes travaillent en ce moment sur
312) des clients Tor pour Java, Android et Maemo.  La première étape est de vous
313) intéresser au projet dans lequel vous désirez vous investir: <a
314) href="http://github.com/brl/JTor">Tor pour Java</a>, <a
315) href="https://svn.torproject.org/svn/projects/android/trunk/">Androif/Orbot</a>
316) ou Tor pour Maemo. Consultez les dépôts et familiarisez-vous avec le code
317) source.  De plus, nous recherchons quelqu'un qui pourrait  (mais ce n'est
318) pas requis) travailler sur l'interrogation ou même l'hébergement des
319) services cachés Tor sur ces plateformes.  <br /> Un développeur compétent
320) devrait être capable de comprendre et d'écrire du code Java, y compris une
321) API Java de chiffrement. Connaître le C serait également un vrai plus. Il
322) faut également vouloir lire et contribuer à la documentation existante car
323) l'implémentation du code est basée sur celle-ci. Ce projet est
324) essentiellement un projet de code qui nécessite quelques compétences en
325) matière de conception.

326) </li>

327) 

328) <li>

329) <b>Nouvelles fonctionnalités dans Torbutton<b> <br /> Priorité:
330) <i>Moyenne</i> <br /> Effort à fournir: <i>Important</i> <br /> Compétences
331) requises: <i>Hautes</i> <br /> Tuteurs potentiels: <i>Mike</i> <br /> Il
332) existe plusieurs <a

333) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&project=5&type=2">demandes
334) d'amélioration</a> dans la section Torbutton de Flyspray. En particulier, <a
335) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=523">l'intégration
336) de la 'Nouvelle Identité' avec Vidalia</a>, <a
337) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=940">les
338) moyens de gérer plusieurs conteneurs de cookies par identité</a>, <a
339) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=637">la
340) préservation de certains cookies</a> lorsque ceux-ci sont effacés, <a
341) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=524">une
342) meilleure injection du champ referrer</a>, <a
343) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=564">une
344) remontée correcte du statut de Tor</a>, et <a
345) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=462">la
346) gestion des urls "tor://" et "tors://"</a> sont toutes des fonctionnalités
347) intéressantes qui pourraient être ajoutées.  <br /> Ce travail devrait être
348) réalisé en tant que code source indépendant réalisé en Javascript et en <a
349) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>
350) sans trop interférer avec le fonctionnement interne de Tor.

351) </li>

352) 

353) <li>

354) <b>Nouvelles fonctionnalités</b> Priorité: <i>Moyenne</i> <br /> Effort à
355) fournir: <i>Moyen</i> <br /> Compétences requises: <i>Moyennes à Hautes</i>
356) <br /> Tuteurs potentiels: <i>Martin</i> <br /> De nouvelles fonctionnalités
357) doivent être implémentées en ce qui concerne les assistants de mises à jour
358) de l'ensemble des logiciels Tor sous Windows et sous les autres systèmes
359) d'exploitation. Ces fonctionnalité incluent:
360) <ol>
361) <li> Intégration de <a href="http://chandlerproject.org/Projects/MeTooCrypto">la
362) bibliohthèque Python MeTooCrypto</a> pour les téléchargements HTTPS
363) authentifiés.</li>
364) <li> Ajouter un système de pointeurs entre les singatures d'horodatage et les
365) fichiers de paquets inclus dans une mise à jour. Consultez le fil de
366) discussion "Thandy attacks / suggestions" sur la liste de diffusion or-dev.</li>
367) <li> Le support des langues dans les assistants d'installation et de
368) configuration, basées sur les préférences régionales de la machine ou compte
369) utilisateur.  Nous avons besoin de compétences sur les codepages Windows,
370) sur unicode et les autres jeux de caractères ainsi que d'une expérience dans
371) les API win32 et posix ainsi que dans Python.</li>
372) </ol>

373) </li>

374) 

375) <li>

376) <b>Simulateur pour les connexion Internet lentes</b> <br /> Priorité:
377) <i>Moyenne</i> <br /> Effort à fournir: <i>Moyen</i> <br /> Compétences
378) requises: <i>Moyennes</i> <br /> Tuteurs potentiels: <i>Steven</i> <br /> De
379) nombreux utilisateurs de Tor disposent de connexions à Internet de qualité
380) médiocre avec une faible bande passante, beaucoup de latence et de
381) nombreuses pertes ou tris de paquets. A l'usage, Tor ne se comporte pas très
382) bien dans ces conditions mais il est difficile d'améliorer la situation sans
383) pouvoir reproduire le problème en laboratoire.  <br /> Ce projet consiste à
384) élaborer un environnement de simulation d'une connection médiocre de manière
385) à ce que l'effet sur Tor puisse être mesuré. D'autres composants à mettre en
386) place pourraient être des utilitaires de test des propriétés des connexions
387) disponibles pour mesurer l'effet sur les performance des modifications
388) apportées à Tor.  <br /> Le responsable du projet peut utiliser les outils
389) de son choix mais dummynet (pour FreeBSD) et nisnet (pour Linux) sont deux
390) composants sur lesquels le projet peut être construit. Les étudiants
391) devraient avoir de l'expérience en programmation réseau et en TCP/IP, de
392) préférence compétents en C et en langage de script.

393) </li>

394) 

395) <li>

396) <b>Une meilleure et plus utile carte du réseau dans Vidalia</b> <br />
397) Priorité: <i>Faible à Moyenne</i> <br /> Effort à fournir: <i>Moyen</i> <br
398) /> Compétences requises: <i>Moyennes</i> <br /> Tuteurs potentiels:
399) <i>Matt</i> <br /> Une des fonctionnalités courantes de Vidalia est la carte
400) du réseau qui montre à l'utilisateur l'emplacement approximatif des relais
401) du réseau Tor et qui trace les chemins empruntés par le trafic qui y est
402) injecté. La carte n'est pas très interactive pour le moment et est de
403) médiocre qualité graphique. A la place, nous avons implémenté le widget KDE
404) Marble pour nous donner une carte de meilleure qualité et nous permettre une
405) meilleure interactivité tel que l'affichage des informations d'un relais ou
406) d'un chemin lorsqu'on clique dessus. Nous voulons ajouter la possibilité
407) pour les utilisateurs de cliquer sur un relais ou un pays contenant un ou
408) plusieurs relais de sortie Tor et dire "Je veux que mes connexions de sortie
409) se fasse à partir d'ici.". <br /> Ce projet implique d'abord d'être
410) familiarisé avec Vidalia et l'API du widget Marble. On pourra ensuite
411) intégrer le widget dans Vidalia et adapter Marble à notre application, comme
412) rendre les circuits cliquables, l'enregistrement du cache des données de la
413) carte dans le répertoire de Vidalia et l'adaptation de certaines des
414) interfaces du widget.  <br /> Une personne intéressée par ce projet devrait
415) disposer d'une bonne expérience de développement en C++. Une expérience avec
416) Qt et Cmake serait un vrai plus.

417) </li>

418) 

419) <li>

420) <b>Équivalent de Torbutton pour Thunderbird</b> <br /> Priorité:
421) <i>Faible</i> <br /> Effort à fournir: <i>Important</i> <br /> Compétences
422) requises: <i>Hautes</i> <br /> Tuteurs potentiels: <i>Mike</i> <br /> Nous
423) entendons parler d'un nombre de plus en plus important d'utilisateurs qui
424) désirent utiliser Thunderbird avec Tor. Néanmoins, il y a plein de problèmes
425) de niveau applicatifs, par exemple, par défaut Thunderbird ajoutera votre
426) nom d'hôte au mail sortant qu'il envoie. A un certain niveau, nous devrions
427) pousser la réalisation d'une extension Thunderbird similaire à Torbutton.

428) </li>

429) 

430) <li>

431) <b>Pilote réseau de niveau intermédiaire</b> <br /> Priorité: <i>Faible</i>
432) <br /> Effort à fournir: <i>Important</i> <br /> Compétences requises:
433) <i>Hautes</i> <br /> Tuteurs potentiels: <i>Martin</i> <br /> Le pilote
434) WinPCAP utilisé par la Machine Virtuelle Tor pour les réseaux translatés ne
435) supporte pas un certain nombre d'adaptateurs de réseaux sans-fil ou
436) non-Ethernet.  L'implémentation d'un pilote réseau de niveau intermédiaire
437) pour win32 et win64 fournirait un moyen d'intercepter et de router du trafic
438) sur ces réseaux. Ce projet nécessite des connaissances et de l'expérience
439) dans le développement de pilote de périphériques du noyau Windows ainsi que
440) des tests. Connaître Winsock et Qemu serait un plus.

441) </li>

442) 

443) <li>

444) <b>Améliorer Tor Weather</b> <br /> Priorité: <i>Moyenne</i> <br /> Effort à
445) fournir: <i>Moyen</i> <br /> Compétences requises: <i>moyennes</i> <br />
446) Tuteurs potentiels: <i>Christian, Roger</i> <br /> <a
447) href="https://weather.torproject.org/">Tor weather</a> est un outil qui
448) permet de recevoir un email indiquant le moment où le relais que vous
449) désirez tracer s'arrête. Actuellement, il n'est pas vraiment utile pour les
450) personnes qui utilisent la fonctionnalité d'hibernation de Tor ou pour ceux
451) qui doivent éteindre régulièrement leur relais. Au cours du projet, Tor
452) weather pourrait être enrichi pour permettre des configurations plus
453) souples.  D'autres améliorations sont également envisageables: Weather
454) pourrait vous envoyer des avertissements lorsque votre relais fonctionne
455) avec une version périmée de Tor ou lorsque votre bande passante atteint un
456) seuil limite. Il pourrait être également un outil sympathique pour vous
457) indiquer si votre relais vous permet d'avoir un <a href="<page
458) tshirt>">T-Shirt</a> ou envoyer des rappels au autorités d'annuaire que
459) leurs clefs vont bientôt expirer. Soyez créatifs et n'oubliez pas que ce
460) projet vous permet de juger de l'état du réseau dans le but de vous aider à
461) terminer votre travail plus rapidement ! Consultez également son <a
462) href="https://svn.torproject.org/svn/weather/trunk/README">README</a> et <a
463) href="https://svn.torproject.org/svn/weather/trunk/TODO">TODO</a>.

464) </li>
465) 
466) <li>

467) <b>Améliorer la mise en paquets de Tor et Vidalia sur Debian/Ubuntu</b> <br
468) /> Vidalia ne fonctionne pas correctement sous Debian et Ubuntu avec les
469) paquets par défaut de Tor. Les paquets Tor actuels lancement automatiquement
470) Tor en tant que démon sous le compte utilisateur debian-tor et (visiblement)
471) n'ont pas de directive <a
472) href="<gitblob>doc/spec/control-spec.txt">ControlPort</a> définie dans le
473) fichier de configuration torrc par défaut. En conséquence, Vidalia tente de
474) démarrer sont propre processus Tor étant donné qu'il ne peut se connecter au
475) Tor existant; à la suite de quoi , le processus Tor lancé par Vidalia génère
476) un message d'erreur peu compréhensible indiquant que Tor ne peut pas
477) utiliser ses ports d'écoute &mdash; ils sont déjà utilisé par le démon Tor
478) initial.  <br /> La solution implique soit d'indiquer à l'utilisateur
479) d'arrêter le démon existant et de laisser Vidalia démarrer son propre
480) processus Tor soit d'expliquer à l'utilisateur comment configurer un port de
481) contrôle et un mot de passe dans son torrc. Une meilleure solution pour
482) Debian serait d'utiliser la directive ControlSocket qui permet à Vidalia de
483) communiquer avec Tor via une socket Unix et cela pourrait être activé par
484) défaut dans les paquets Debian de Tor. Vidalia peut ensuite s'authentifier
485) sur Tor en utilisant l'authentification du système de fichier (cookie) si
486) l'utilisateur qui a lancé Vidalia est également dans le groupe debian-tor.
487) <br /> Ce projet implique d'abord le support de la directive ControlSocket
488) dans Vidalia. L'étudiant développera et testera alors les paquets Vidalia
489) pour Debian et Ubuntu de manière conforme aux standards d'empaquetage de
490) Debian et s'assurera qu'ils fonctionnent correctement avec les paquets Tor
491) existant. Nous pouvons aussi mettre en place un dépôt pour héberger les
492) nouveaux paquets Vidalia.  <br /> Le défi qui suit consiste à trouver un
493) moyen efficace pour Vidalia de pouvoir modifier la configuration de Tor
494) (torrc) même si celle-ci est située dans <code>/etc/tor/torrc</code> et
495) reste immuable. La meilleure idée que nous avons trouvée jusqu'à présent est
496) de faire passer cette configuration par le ControlSocket lorsque Vidalia
497) démarre mais c'est une méthode discutable car Tor se lance à chaque
498) démarrage avec une configuration différente de celle que désire
499) l'utilisateur. La deuxième idée consiste à faire écrire à Vidalia un fichier
500) temporaire torrc et demander à l'utilisateur de le déplacer manuellement
501) dans <code>/etc/tor/torrc</code> mais c'est également discutable car les
502) utilisateurs ne devraient pas gérer ces fichiers directement.  <br />Une
503) personne intéressée par ce projet doit disposer d'une certaine connaissance
504) des règles d'empaquetage dans Debian et avoir une expérience en C++. Des
505) compétences en QT seraient un vrai plus.

506) </li>
507) 
508) <li>

509) <b>Framework de mise à jour automatique pour Tor/Polipo/Vidalia</b> <br
510) />Nous avons besoin d'un bon framework pour les mises à jour authentifiées.
511) Vidalia dispose déjà de la capacité à avertir l'utilisateur qu'il utilise
512) une version périmée ou non recommandée de Tor en utilisant des annonces
513) signées issue des information d'annuaire. Pour le moment, Vidalia affiche
514) simplement une petit boîte de dialogue qui informe l'utilisateur qu'il doit
515) manuellement mettre à jour ses logiciels. L'objectif du projet serait
516) d'offrir la possibilité à Vidalia de récupérer et installer les logiciels
517) Tor mis à jour pour le compte de l'utilisateur. Nous devrions récupérer les
518) fichiers via Tor si possible mais également par des moyens plus directs. Si
519) le temps le permet, nous aimerions mettre à jour les autres applications
520) incluses dans les installeurs telles que Polipo et Vidalia lui-même.  <br />
521) Pour mener à bien ce projet, l'étudient devra d'abord se renseigner sur les
522) frameworks de mise à jour automatique (e.g. Sparkle sur OS X) pour évaluer
523) leurs avantages/inconvénients ainsi que leurs failles de sécurité et leur
524) capacité à s'intégrer à Vidalia. Si aucun de ces framworks ne convient,
525) l'étudiant concevra sont propre framework, documentera les spécifications et
526) en discutera avec les autres développeurs pour gérer les problèmes de
527) sécurité. L'étudiant implémentera ensuite le framework (ou intégrera un de
528) ceux qui existent) et procédera aux tests.  <br /> Une personne motivée par
529) ce projet doit disposer d'une bonne expérience en C++. Une expérience
530) antérieure avec Qt serait un vrai plus. Il est également important de bien
531) comprendre les bonnes pratiques de sécurité telles que la vérification de
532) signature des paquets. De bonnes capacités de rédaction sont également
533) importantes pour ce projet car une des étapes vitales est de produire la
534) documentation des spécifications à relire et à discuter avec les autres
535) avant l'implémentation.

536) </li>
537) 
538) <li>

539) <b>Améliorer le processus qualité de Tor: Intégration continue de
540) compilation</b> <br /> Il serait très utile d'avoir un processus de
541) compilation automatisé pour Windows et pour les autres plateformes. Le but
542) d'avoir un tel environnement est de s'assurer que Windows ne reste pas à la
543) traîne sur aucun des logiciels employés dans le projet Tor. <br />Buildbot
544) semble être un bon choix car il supporte toutes les plateformes
545) surlesquelles Tor fonctionne. Consultez <a
546) href="http://en.wikipedia.org/wiki/BuildBot">l'article Wikipedia sur
547) buildbot</a>.<br /> Il y a sans doute de meilleures options que la personne
548) désirant gérer cette tâche doit évaluer. Toute personne travaillant sur ce
549) processus de compilation automatique doit avoir de l'expérience ou le désir
550) d'apprendre comment compiler l'ensemble du code source en lien avec Tor à
551) partir de rien. De plus, cette personne doit disposer d'une expérience dans
552) la compilation de logiciels sous l'environnement Windows car c'est le coeur
553) de cible à ne pas rater de ce projet. Ce travail impose d'utiliser le code
554) source de Tor mais uniquement du point de vue compilation et non
555) d'écriture.<br />Ensuite, nous avons besoin d'automatiser nos tests de
556) performance pour toutes les plateformes. Nous disposons là encore de builbot
557) (sauf sur Windows &mdash; comme indiqué ci-dessus) pour automatiser nos
558) intégrations régulières de code et nos tests de compilation mais nous avons
559) besoin de mettre à jour nos tests de simulation réseau pour les versions les
560) plus récente de Tor. Enfin, nous avons besoin de lancer des tests réseau à
561) la fois sur une seule machine et également à travers plusieurs autres de
562) manière à tester automatiquement les changement de performance avec des
563) rôles différents.

564) </li>
565) 
566) <li>

567) <b>Tests d'utilisation de Tor</b> <br /> Priorité: <i>Moyenne</i> <br />
568) Effort à fournir: <i>Moyen</i> <br /> Compétences requises: <i>Faibles à
569) Moyennes</i> <br /> Tuteurs potentiels: <i>Andrew</i> <br /> Spécialement le
570) Pack de Navigation, idéalement parmi notre coeur de cible.  Cela nous
571) aiderait beaucoup à comprendre ce qui doit être réalisé en terme de
572) correction de bugs ou de nouvelles fonctionnalités. Nous récupérons
573) l'information de manière informelle pour le moment mais un processus plus
574) structuré serait meilleur.

575) </li>
576) 
577) <li>

578) <b>Un proxy IRC d'authentification</b> <br /> Priorité: <i>Moyenne</i> <br
579) /> Effort à fournir: <i>Moyen à Important</i> <br /> Compétences requises:
580) <i>Moyennes à Hautes</i> <br /> Tuteurs potentiels: <i>Sebastian, Weasel,
581) Roger</i> <br /> Le monde entier a besoin d'un proxy IRC
582) d'authentification. Comme nous le rappelle régulièrement la bande dessinée
583) web Penny Arcade: "Utilisateur Internet+ anonymat = abruti". Toutefois, Tor
584) n'a pas de problème avec le sites web car ces derniers permettent à leurs
585) utilisateurs de connecter en utilisant des systèmes d'authentification
586) situés à un autre niveau. Mais les serveurs IRC sont bien plus mauvais car
587) pour la majorité d'entre-eux, le code source est écrit de manière médiocre:
588) difficile à maintenir et plus difficile encore à modifier. De nombreux
589) réseaux IRC bloquent maintenant les connexions depuis Tor et nous sommes
590) quasiment acceptés seulement sur deux réseaux (OFTC et Freenode). Cet état
591) signifie qu'un grand nombre de personnes dans le monde affirment "je vous
592) l'avais bien dit" lorsqu'ils évoquent l'anonymat en ligne alors que c'est
593) simplement dû à un manque de technologie pour rendre le problème
594) gérable. Nous avons besoin d'un moyen pour les réseaux IRC de distinguer
595) quels sont les utilisateurs qui ont prouvé leur réputation et qui sont les
596) abrutis, de manière à bien séparer les deux. Il existe quels concepts de
597) recherche comme <a href="http://www.cs.dartmouth.edu/~nymble/">Nymble</a>
598) qui permet aux sites web de blacklister les utilisateurs sans avoir besoin
599) de connaître leur identité. Mais Nymble est conçu pour les interactions sur
600) le web. Nous avons besoin de féderer nos efforts sur le protocole IRC afin
601) de monter un projet semblable à Nymble (ou un plus simple pour démarrer en
602) tant que preuve de concept). Un des moyens d'y parvenir serait de construire
603) un proxy IRC sachant comment écouter les clients IRC et comment parler aux
604) serveurs IRC et bien sûr qui disposerait d'une couche permettant aux
605) utilisateurs de s'authentifier.

606) </li>
607) 
608) <li>

609) <b>Amener de nouvelles idées !</b> <br />Vous n'aimez aucune de celles qui
610) sont présentées ? Consultez <a
611) href="<gitblob>doc/roadmaps/2008-12-19-roadmap-full.pdf">la feuille de route
612) de développement</a> pour vous donner d'autres idées.  Quelques-unes <a
613) href="<gittree>doc/spec/proposals/">des propositions en cours</a> ont
614) également besoin de développeurs.

615) </li>
616) 
617) </ol>
618) 

619) <a id="OtherCoding"></a>
620) <h2><a class="anchor" href="#OtherCoding">Autres idées de spécifications et de
621) code</a></h2>

622) <ol>

623) <li>Les serveurs de Tor ne fonctionnent pas parfaitement sur Windows
624) XP. SurWindows, Tor utilise l'appel système standard <tt>select()</tt>, qui
625) utilise l'espace non paginé dans le pool. Ce qui implique que les serveurs
626) de taille moyenne vont vider l'espace non paginé, <a
627) href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">provocant
628) l'instabilité et le plantage du système</a>. Nous devrions probablement
629) utiliser des E/S recouvrables à la place. Une solution pourrait-être
630) d'apprendre à la <a
631) href="http://www.monkey.org/~provos/libevent/">libevent</a> comment utiliser
632) les E/S recouvrables à la place de select() sous Windows, et alors d'adapter
633) Tor à la nouvelle interface libevent. Christian King à <a
634) href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">bien

635) démarré</a> sur ce point l'été 2007.</li>

636) 
637) <li>Nous avons besoin maintenant de commencer l'élaboration de notre <a
638) href="<page documentation>#DesignDoc">conception de résistance au
639) blocage</a>. Ceci implique une refonte de la conception, une modification de
640) différents aspects de Tor, une adaptation de <a href="<page
641) vidalia/index>">Vidalia</a> pour qu'il supporte les nouvelles

642) fonctionnalités, et planifier le deploiement.</li>

643) 
644) <li>Nous avons besoin d'un ensemble d'outils flexibles de simulation pour
645) étudier de bout en bout les trafics de confirmation d'attaque. Beaucoups de
646) chercheurs ont conçu des simulateurs ad hoc pour confirmer leurs intuitions
647) comme quoi soit l'attaque marche vraiment bien ou que les défenses
648) fonctionnent. Pouvons nous construire un simulateur qui soit clairement
649) documenté et suffisament ouvert pour que tout le monde sache qu'il donne une
650) réponse raisonnable ? Ceci stimulera un grand nombre de nouvelles
651) recherches. Voyez l'entrée <a href="#Research">suivante</a> sur les
652) confirmations d'attaque pour les détails sur le coté recherche de cette
653) tâche &mdash; qui sait, quand ceci sera fait peut-être pourrez aider en
654) écrivant un rapport ou deux.</li>
655) 
656) <li>Tor 0.1.1.x inclut le support d'accélérateurs matériels de chiffrage via
657) OpenSSL. Cependant, personne ne l'a jamais testé. Est-ce que quelqu'un
658) voudrait se procurer une carte et nous dire ce qu'il en est ?</li>
659) 

660) <li>Faire une analyse de sureté de Tor avec <a

661) href="http://en.wikipedia.org/wiki/Fuzz_testing">du "fuzz"</a>. Déterminer
662) s'il existe déjà de bonnes bibliothèques de fuzz pour ce que nous voulons
663) faire. La célébrité pour celui grâce à qui une nouvelle version pourra voir
664) le jour !</li>
665) 
666) <li>Tor utilise TCP pour le transport et TLS pour le chiffrage des liens. C'est
667) simple et efficace, mais cela implique que toutes les unités (cellules) d'un
668) lien sont mises en attente lorsqu'un seul paquet est perdu, et cela signifie
669) que seuls des flux TCP peuvent être raisonnablement supportés. Nous avons
670) dressé une <a
671) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">
672) liste de raisons pour lesquelles nous n'avons pas bifurqué vers le transport
673) par UDP</a>, mais ce serait bien de voir cette liste se raccourcir. Nous
674) avons aussi proposé <a href="<gitblob>tor/doc/100-tor-spec-udp.txt">une
675) spécification pour Tor et UDP</a> &mdash; lisez-la et faites-nous part de
676) vos remarques et critiques, s'il-vous-plaît.</li>
677) 
678) <li>Nous ne sommes plus très loin d'avoir le support pour IPV6 entre les
679) serveurs de sorties et les adresses finales. Si IPV6 vous tient à cœur,
680) partir de là est sans doute un premier pas.</li>
681) 
682) <li>Nous avons besoin de générer les diagrammes du site web (par exemple les
683) images de "Comment fonctionne Tor ?" sur <a href="<page overview>">la page
684) d'aperçu</a> à partir d'une source de manière à pouvoir les traduire comme
685) du texte UTF-8 plutôt que de les éditer à la main avec Gimp. Nous voudrions
686) intégrer ce processus dans un fichier wml pour faciliter les traductions et
687) regénérer les images en plusieurs langues lorsque nous construisons le site
688) web.</li>
689) 
690) <li>Comment pouvons-nous maintenir, améliorer et documenter plus facilement les
691) différents systèmes LiveCD/USB ? <a href="http://amnesia.boum.org/">Le
692) LiveCD/USB amnesia</a>et <a
693) href="http://anonymityanywhere.com/incognito/">le LiveCD Incognito</a> sont
694) quelques exemples.
695) </li>

696) </ol>
697) 
698) <a id="Research"></a>
699) <h2><a class="anchor" href="#Research">Recherche</a></h2>
700) <ol>

701) <li>"L'attaque par empreinte de sites": faire une liste de quelques centaines de
702) sites populaires, en télécharger les pages, et faire des "signatures" pour
703) chaque site. Ensuite, observer le trafic d'un client Tor. L'analyse de ses
704) réceptions de données donne rapidement une idée des sites qu'il
705) visite. Premièrement, quelle est l'efficacité de cette attaque sur le code
706) actuellement utilisé dans Tor ? Ensuite, tester les défenses possibles : par
707) exemple, changer la taille des cellules de Tor de 512 octets à 1024,
708) utiliser des techniques de remplissage comme <a
709) href="http://freehaven.net/anonbib/#timing-fc2004">le lâcher défensif</a>,
710) ou ajouter des délais de trafic. Quel impact ces stratégies de défense
711) ont-elles, et, dans les cas où elles sont efficaces en défense, quel impact
712) ont-elles en terme de perte d'utilisabilité de Tor (à quantifier) ?</li>
713) <li>"L'attaque par corrélation des trafics aux extrémités": par l'observation
714) des trafics de Alice et Bob, il est possible de <a
715) href="http://freehaven.net/anonbib/#danezis:pet2004">comparer les signatures
716) des trafics et d'en déduire qu'il s'agit du même flux</a>. Jusqu'ici, Tor
717) considère ce type d'attaque comme intrinsèque et donc inévitable. Tout
718) d'abord, est-ce réellement vrai ? Quelle quantité de trafic - et avec quelle
719) distribution - est-elle nécessaire pour que l'adversaire soit certain
720) d'avoir gagné ? Est-ce qu'il existe des scénarios (par exemple avoir un
721) trafic faible) pour ralentir cette attaque ? Est-ce que certains types de
722) remplissage ou de modelage de trafic fonctionnent mieux que d'autres ?</li>
723) <li>On peut relier la question qui vient: Est-ce-que le fait de faire tourner un
724) relais/passerelle offre une protection supplémentaire contre ces attaques
725) basées sur les timings ? Un attaquant externe qui ne peut voir l'intérieur
726) des flux TLS peut-il reconnaître de manière fiable les flux individuels ?
727) Est-ce-que le volume de trafic transféré dégrade cette possibilité ? Que
728) faire si le relais du client retarde délibérément le trafic montant pour
729) former une queue pouvant être utilisée pour mimer les timings du trafic
730) descendant du client pour le faire passer pour du trafic egalement relayé ?
731) Cette queue identique pourrait être également utilisée pour masquer les
732) temps du trafic montant du client à l'aide des techniques dites <a
733) href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptative
734) padding</a> sans avoir besoin de trafic supplémentaire. Est-ce-qu'un tel
735) entrelacement du trafic montant du client osbcurcit les temps pour des
736) attaquants externes ? Les stratégies doivent-elles être ajustées pour les
737) liens symétriques ? Ou bien est-ce plus évident que pour les liens
738) symétriques ?</li>
739) <li><a href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">L'attaque
740) d'Oakland 05</a> par Repeat Murdoch et Danezi sur le réseau Tor
741) acutel. Essayez de comprendre pourquoi elle fonctionne bien sur certains
742) noeuds et pas sur les autres. (Ma théorie est que les noeuds rapides avec
743) davantage de capacité résistent mieux à l'attaque). On peut expérimenter
744) cette attaque avec la gestion des options RelayBandwithRate et
745) RelayBandwithBurst pour faire tourner un relais utilisé comme client tout en
746) relayant le traffic de l'attaquant: si nous limitons fortement le
747) RelayBandwithRate, est-ce-que l'attaque est plus difficile ? Quel est le
748) ratio correct de RelayBandwithRate par rapport à la capacité ? D'ailleurs,
749) est-ce-que le ratio joue un rôle dans cette attaque ? Pendant qu'on y est,
750) est-ce-qu'un plus grand nombre de relais candidats augmente le taux de faux
751) positifs ou une autre complexité dans l'attaque ? (Le réseau Tor est
752) maintenant deux fois plus étendu qu'il ne l'était au moment de la rédaction
753) de leur papier). Prenez également le temps de consulter le document <a
754) href="http://freehaven.net/anonbib/#clog-the-queue">Don't Clog the
755) Queue</a>.</li>
756) <li>L'attaque "routing zones": la majorité de ce qui est écrit sur Tor modélise
757) le chemin réseau entre Alice et son noeud d'entrée (et entre Bob et le noeud
758) de sortie) comme un simple lien sur un graphe. En pratique, le chemin
759) traverse de nombreux systèmes automomes (SA) et <a
760) href="http://freehaven.net/anonbib/#feamster:wpes2004">il n'est pas rare que
761) le même SA apparaissent à la fois sur le chemin d'entrée comme sur le chemin
762) de retoure</a>.  Malheureusement, pour être sûr de prédire si un quartet
763) Alice, noeud d'entrée, noeud de sortie, Bob sera dangereux, il faut
764) télécharger entièrement une zone de routage Internet et effectuer de
765) couteuses opérations dessus. Existe-t-il des approximations pratiques comme
766) éviter les adresse IP situées dans le même réseau /8 ?</li>
767) <li>D'autres points de recherche se pose la question de savoir, d'un point de
768) vue diversité géographique, s'il est mieux d'avoir un circuit efficace ou de
769) choisir un circuit au hasard. Consultez <a
770) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">les
771) travaux de Stephen Rollyson</a> qui expliquent comment éviter les choix
772) particulièrement inefficaces sans "trop" compromettre l'anonymat. Cet angle
773) d'attaque a besoin d'être creusé et travaillé mais il a l'air très
774) prometteur.</li>
775) <li>Tor ne fonctionne pas bien lorsque les relais disposent d'une bande passante
776) asymétrique (ex: câble ou ADSL). Etant donné que Tor sépare les connexions
777) entre chaque hop, si les octets entrants arrivent trop vite et que du coup,
778) les octets sortants arrivent plus lentement, les mécanismes de push-back de
779) TCP ne retournent pas cette information aux flux entrants.  Peut-être que
780) Tor devrait détecter les rejets de paquets sortants et réguler les flux
781) entrants de lui-même ? J'imagine un schéma d'ouverture/fermeture où l'on
782) récupère un taux de transfert limite donné qu'on incrémente lentement
783) jusqu'à perdre des paquets, moment où l'on diminuerait le taux, etc... Nous
784) avons besoin de quelqu'un disposant de sérieuses compétences réseau pour
785) simuler cela et apporter son aide pour la mise en place de ces
786) fonctionnalités. Nous avons besoin de comprendre l'importance de la
787) dégradation des performances et de l'utiliser comme élément moteur en vue de
788) reconsidérer le transport par UDP.</li>
789) <li>Le contrôle de la congestion est un sujet proche. Est-ce-que notre
790) spécification permet de gérer les fortes charges ? Peut-être devrions-nous
791) expérimenter des fenêtres de tailles variables plutôt que des fenêtres fixes
792) ? Cela semble prometteur dans <a
793) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">cette
794) expérimentation autour de ssh</a>. Nous avons besoin de mesurer, de corriger
795) et peut-être de refondre quelquechose si les résultats s'avèrent bons.</li>
796) <li>Nos objectifs de résistance à la censure incluent l'impossibilité pour un
797) attaquant qui observe le trafic Tor de <a
798) href="<gitblob>doc/design-paper/blocking.html#sec:network-fingerprint">le
799) distinguer d'un trafic SSL normal</a>. Néanmoins, nous ne pouvons pas
800) recréer une stéganographie parfaire tout en restant utilisable mais, dans un
801) premier temps, nous aimerions pouvoir bloquer toute attaque qui pourrait
802) réussir en observant quelques paquets seulement. Une des attaques qu'il nous
803) reste à examiner est basée sur le fait que les paquets Tor font 512 octets
804) et que par conséquence, les paquets du trafic réseau sont également des
805) multiples de 512 octets.  En quoi le fait de modifier les enregistrements
806) TLS et leur en-tête pourrait brouiller ce trafic ? Différentes stratégies de
807) fermeture de tampon dans Tor peuvent-elles avoir un impact sur ce sujet ?
808) Est-ce-qu'un peu de remplissage ferait l'affaire ou bien est-ce-une attaque
809) que nous pouvons accepter ?</li>
810) <li>Les circuits Tor sont construit pas à pas. Ainsi, il est théoriquement
811) possible de faire sortir des flux à partir du second pas, d'autres à partir
812) du troisième et ainsi de suite. Cela semble une alternative séduisante car
813) elle permet de passer outre la limite en sortie de chaque relais. Mais si
814) nous voulons que chaque flux soit sécurisé, le chemin "le plus court" doit
815) obligatoirement avoir au moins 3 pas selon notre logique actuelle. Nous
816) devons examiner cette alternative sur l'aspect performance en balance de la
817) sécurité</li>
818) <li>Il n'est pas si difficile de faire du dénis de service sur les relais Tor ou
819) les autorités d'annuaire. Les clients forment-ils la meilleure réponse ?
820) Quelles sont les autres approches possibles ? Il serait bien qu'elles soient
821) compatibles avec le protocole Tor actuel.</li>
822) <li>Les programmes tels que <a href="<page torbutton/index>">Torbutton</a> ont
823) pour objectif de masquer le champ UserAgent de votre navigateur web en le
824) replaçant par une réponse uniforme pour tous les utilisateurs Tor. Ainsi, un
825) attaquant ne peut rien déduire de vous en regardant cet en-tête. Il essaye
826) de récupérer une chaîne communément utilisée par les utilisateurs
827) non-Tor. Première question: comment révélons-nous l'utilisation de Tor en
828) mettant à jour régulièrement ce champ ? Si nous le mettons à jour trop
829) souvent, nous supprimons nous-même de l'anonymat. Si nous ne le mettons pas
830) à jour souvent alors tous les utilisateurs de Tor se dévoileront car leur
831) navigateur web indiquera qu'ils utilisent tous une assez vieille version de
832) Firefox. La réponse à la question dépend certainement des versions de
833) Firefox utilisés dans la nature. Deuxième question: régulièrement, les gens
834) nous demande de modifier le champ UserAgent selon un cycle de N chaînes de
835) caractères différentes plutôt que de mettre toujours la même. Est-ce-que
836) cette approche est vraiment utile, malfaisante ou neutre ? A prendre en
837) considération: les cookies et le fait de reconnaître les utilisateurs de
838) Torbutton par leur rotation de UserAgents; les sites webs malicieux qui
839) n'attaque qu'un seul type de navigateur web; la réponse à la question un
840) impact la réponse à la question deux.
841) </li>
842) <li>Actuellement, les clients Tor réutilisent un circuit donné pendant les dix
843) minutes qui suivent sa première utilisation. L'objectif est d'éviter de
844) surcharger le réseau avec des opérations de circuits étendus et également
845) pour éviter que les clients utilisent le même circuit pendant trop longtemps
846) ce qui permettrait au noeud de sortie de les profiler. Hélas, dix minutes
847) est une période de temps sans doute trop longue, spécialement si des
848) connexions vers des protocoles différents (ex messagerie instantanée et
849) navigation internet) utilisent le même circuit. Si nous continuons à fixer
850) le nombre global de la taille des circuits que le réseau a besoin d'établir,
851) existe-t-il de meilleurs et/ou de plus sûrs moyens pour les clients
852) d'affecter des flux aux circuits ou bien pour que les clients construisent
853) des circuits préemptifs ? Peut-être que cet élément de recherche doit
854) commencer par récupérer des traces sur les connexions typiques que les
855) clients initient afin de disposer de données réalistes ?
856) </li>
857) <li>De combien de passerelles avez-vous besoin pour maintenir un bon niveau
858) d'accessibilité ? Nous devrions mesurer le contenu de nos passerelles. Si ce
859) contenu est bien fourni, existe-t-il des moyens de faire en sorte que les
860) utilisateurs de passerelles restent connectés plus longtemps ?

861) </li>

862) </ol>
863) 

864) <p>

865) <a href="<page contact>">Contactez-nous</a> si vous avez avancé sur ces
866) points !

867) </p>

868) 

869)   </div>

870) 

871)