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="Documentation"></a>
38) <h2><a class="anchor" href="#Documentation">Documentation</a></h2>

39) <ol>

40) <li>Aidez-nous à traduire le site et la documentation dans d'autres
41) langues. Allez voir les <a href="<page translation>">conseils de
42) traduction</a> si vous souhaitez le faire. Nous avons besoin plus
43) spécialement de personnes pour traduire en Arabe ou en Persan pour les
44) utilisateurs Tor situés dans les zones censurées.</li>
45) <li>Évaluez et documentez <a
46) href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">notre
47) liste de programmes</a> pouvant être utilisés avec Tor.</li>
48) <li>Nous avons toute une liste de <a
49) href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">programmes
50) potentiellement utiles qui s'interfacent avec Tor</a>. Lesquels sont utiles
51) et dans quelles situations ? Contribuez à les tester et à documenter les
52) résultats.</li>

53) </ol>
54) 
55) <a id="Advocacy"></a>
56) <h2><a class="anchor" href="#Advocacy">Plaidoyer</a></h2>
57) <ol>
58) <li>Créer un <a href="https://wiki.torproject.org/noreply/CommunityLogos">logo
59) communautaire</a> sous licence Creative commons que chacun puisse utiliser
60) et modifier</li>
61) <li>Créer une présentation qui puisse être utilisée lors des nombreux meetings
62) de groupe sur toute la planète.</li>
63) <li>Créer une vidéo sur les utilisations positives de Tor, sur ce qu'est Tor ou
64) comment l'utiliser.  Quelques personnes ont déjà commencé sur <a
65) href="http://media.torproject.org/video/">le serveur Média de Tor</a>, <a
66) href="http://www.howcast.com/videos/90601-How-To-Circumvent-an-Internet-Proxy">Howcast</a>,
67) et <a href="http://www.youtube.com/freedom4internet">Youtube</a>.</li> 
68) <li>Créer un poster ou un jeu de posters autour d'un thème tel que "Tor pour la
69) Liberté !"</li>

70) </ol>
71) 

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

74) 

75) <p>

76) Quelques-uns de ces projets peuvent sans doute faire de bonnes idées pour le
77) <a href="<page gsoc>">Google Summer of Code 2010</a>. Nous avons marqué
78) chaque idée avec son niveau d'utilité globale pour le projet Tor (priorité),
79) quelle quantité de travail nous attendons (niveau d'effort), avec quelles
80) prérequis vous pouvez commencer (compétences requises) et lequel de nos <a
81) href="<page people>#Core">développeurs de coeur de projet</a> sont
82) pré-sentis pour devenir tuteur.  Si une (ou plus) de ces idées vous semble
83) prometteuse, merci de <a href="<page contact>">nous contacter</a> pour
84) discuter de vos intentions plutôt que de nous envoyer une application toute
85) faîte. Vous pouvez également nous proposer votre propre idée &mdash; ce qui
86) conduit souvent à la meilleure application.

87) </p>

88) 

89) <ol>

90) 

91) <li>

92) <b>Pack de Navigation Tor pour Linux/Mac OS X</b> <br /> Priorité:
93) <i>Haute</i> <br /> Effort à fournir: <i>Haut</i> <br /> Compétences
94) requises: <i> Moyennes</i> <br /> Tuteurs potentiels: <i>Steven, Erinn,
95) Jacob, Andrew</i> <br /> Le Pack de Navigation Tor contient Tor, Firefox,
96) Polipo et l'interface graphique Vidalia (et en option le client de
97) messagerie instantanée <a href="http://pidgin.im/">Pidgin</a>). Les
98) composants sont préconfigurés pour fonctionner de manière sécurisée et
99) requièrent très peu de dépendances vis à vis du système d'exploitation
100) installé. C'était autrefois un des moyens le plus facile et le plus
101) populaire d'utiliser Tor sous Windows.  <br /> Toutefois, il n'existe pas de
102) paquets fonctionnant sous Linux ou Mac Os X. C'est pourquoi ce projet
103) consiste à créer un Pack de Navigation Tor sur OS X et d'étendre ce travail
104) à un autre pour Linux. Cela implique des modifications dans Vidalia (C++),
105) peut-être dans Firefox (C) et enfin de créer et de tester le lanceur sur
106) toute une gamme de versions de systèmes d'exploitation et de configuration
107) différentes afin de vérifier la portabilité.  Un peu de ce travail a été
108) accompli lors du Google Summer of Code 2009. Une autre partie de ce projet
109) consiste à identifier toutes les traces laissées après l'utilisation d'un
110) Pack de Navigation sur Mac Os X ou Linux.  L'étape finale consiste à trouver
111) un moyen de stopper, de contrer ou de supprimer ces traces.  <br /> Les
112) étudiants désirant participer doivent connaître le développement
113) d'applications, de préférence, sur les deux plateformes (Linux et Mac OS X)
114) et doivent disposer de sérieuses compétences en C/C++ et en script shell.
115) <br /> Une part de ce projet peut consister à tester ce Pack de Navigation
116) sur le coeur de cible des utilisateurs concernés. Cela permettrait d'en
117) savoir un peu plus sur ce qui a besoin d'être corrigé ou amélioré. Nous
118) conservons cette description comme un simple élément d'information pour le
119) moment mais un processus plus structuré serait bien meilleur.

120) </li>
121) 
122) <li>

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

145) </li>
146) 

147) <li>
148) <b>Réécrire TorDNSEL avec cette fois, une spécification !</b> <br />
149) Priorité: <i>Haute</i> <br /> Effort à fournir: <i>Moyen</i> <br />
150) Compétences requises: <i>Moyennes</i> <br /> Tuteurs potentiels: <i>Mike,
151) Roger, Sebastian</i> <br /> La <a href="<page tordnsel/index>">Liste de
152) Sortie DNS Tor (ndt: Tor DNS Exit List) est un programme en Haskell non
153) maintenu qui a trois objectifs. Le premier est de fournir une interface DNS
154) rbl pour les personne qui souhaitent savoir si une adresse IP donnée est (ou
155) a été récemment) un relais de sortie Tor. Le deuxième objectif est de
156) construire activement des circuits dans le réseau Tor pour se reconnecter à
157) lui-même de manière à connaître l'adresse IP réelle de sortie de chaque
158) relais &mdash; certains relais Tor font sortir le trafic à une autre adresse
159) que celle qui est affichée dans leur descripteur. Le troisième objectif
160) consiste à exporter <a
161) href="http://exitlist.torproject.org/exitAddresses">une liste</a> de manière
162) à ce que <a href="https://check.torproject.org/">check.torproject.org</a>
163) puisse deviner si votre navigateur est configuré pour utiliser Tor.  <br />
164) Ce projet utilisera <a
165) href="https://check.torproject.org/">check.torproject.org</a>, un ensemble
166) de scripts Python qui interagissent avec Tor pour déterminer comment notre
167) Vérificateur de Relais de sortie Tor devrait fonctionner et donc, comment le
168) compiler &mdash; probablement en Python car Torflow est en
169) Python. L'objectif principal est de réduire, le plus possible, les faux
170) positifs en étant assuré de connaître les nouveaux relais le plus rapidement
171) possible, de s'assurer de terminer rapidement la phase de tests et que les
172) réponses soient bien transmises au script de vérification. En bonus, il
173) faudrait standardiser (rédiger la spécification) le format du fichier
174) d'adresses de sortie et réécrire le script  <a
175) href="https://svn.torproject.org/svn/check/trunk/cgi-bin/TorBulkExitList.py">Tor
176) Bulk Exit List</a> de manière à utiliser ce fichier plutôt que  <a
177) href="https://svn.torproject.org/svn/check/trunk/cgi-bin/TorBulkExitList.py">Tor
178) Bulk Exit List</a>l'horrible hack DNS</a> qui est actuellement en
179) vigueur. En extra-bonus, il faudrait travailler avec Freenode, OFTC et/ou
180) les autres réseaux IRC pour être certains que les scripts réalisés sont bien
181) ceux qu'ils attendent, en terme d'identification précise des utilisateurs
182) issus du réseau Tor.  <br /> Vous pouvez récupérer <a
183) href="git://git.torproject.org/git/tordnsel">la dernière version de
184) tordnsel</a> via git.
185) </li>
186) 

187) <li>

188) <b>Improving Tor's ability to resist censorship</b> <br /> Priority:
189) <i>Medium to High</i> <br /> Effort Level: <i>Medium</i> <br /> Skill Level:
190) <i>High</i> <br /> Likely Mentors: <i>Nick, Roger, Steven</i> <br /> The Tor
191) 0.2.1.x series makes <a

192) href="<svnprojects>design-paper/blocking.html">significant improvements</a>

193) in resisting national and organizational censorship.  But Tor still needs
194) better mechanisms for some parts of its anti-censorship design.  For
195) example, current Tors can only listen on a single address/port combination
196) at a time.  There's <a
197) href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">a proposal to
198) address this limitation</a> and allow clients to connect to any given Tor on
199) multiple addresses and ports, but it needs more work.  <br /> Another area
200) that needs work is our <a
201) href="http://gitweb.torproject.org//bridgedb.git?a=tree">bridgedb</a>
202) service. See e.g. <a
203) href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html">Roger's or-dev
204) post</a> from December for details &mdash; lots of design work remains.  <br
205) /> This project involves a lot of research and design. One of the big
206) challenges will be identifying and crafting approaches that can still resist
207) an adversary even after the adversary knows the design, and then trading off
208) censorship resistance with usability and robustness.

209) </li>

210) 
211) 

212) 
213) <!--<li>
214) 
215) <b>Tuneup Tor!</b>
216) <br />
217) Priority: <i>Medium to High</i>
218) <br />
219) Effort Level: <i>Medium to High</i>
220) <br />
221) Skill Level: <i>High</i>
222) <br />
223) Likely Mentors: <i>Nick, Roger, Mike, Karsten</i>
224) <br />
225) Right now, Tor relays measure and report their own bandwidth, and Tor
226) clients choose which relays to use in part based on that bandwidth.
227) This approach is vulnerable to
228) <a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where
229) relays lie about their bandwidth</a>;
230) to address this, Tor currently caps the maximum bandwidth
231) it's willing to believe any relay provides.  This is a limited fix, and
232) a waste of bandwidth capacity to boot.  Instead,
233) Tor should possibly measure bandwidth in a more distributed way, perhaps
234) as described in the
235) <a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
236) Tor"</a> paper
237) by Snader and Borisov. One could use current testing code to
238) double-check this paper's findings and verify the extent to which they
239) dovetail with Tor as deployed in the wild, and determine good ways to
240) incorporate them into their suggestions Tor network without adding too
241) much communications overhead between relays and directory
242) authorities.
243) </li>-->

244) <li>

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

264) </li>

265) 

266) <li>

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

298) </li>

299) 

300) <li>

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

319) </li>

320) 

321) <li>

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

340) </li>

341) 
342) 

343) 
344) 

345) 
346) <!--<li>
347) 
348) <b>New Torbutton Features</b>
349) <br />
350) Priority: <i>Medium</i>
351) <br />
352) Effort Level: <i>High</i>
353) <br />
354) Skill Level: <i>High</i>
355) <br />
356) Likely Mentors: <i>Mike</i>
357) <br/>
358) There are several <a
359) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5&amp;type=2">good
360) feature requests</a> on the Torbutton Flyspray section. In particular, <a
361) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=523">Integrating
362) 'New Identity' with Vidalia</a>,
363) <a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=940">ways of
364) managing multiple cookie jars/identities</a>, <a
365) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=637">preserving
366) specific cookies</a> when cookies are cleared,
367) <a
368) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=524">better
369) referrer spoofing</a>, <a
370) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=564">correct
371) Tor status reporting</a>, and <a
372) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=462">"tor://"
373) and "tors://" urls</a> are all interesting
374) features that could be added.
375) <br />
376) This work would be independent coding in Javascript and the fun world of <a
377) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
378) with not too much involvement in the Tor internals.
379) </li>-->

380) <!-- <li>
381) 
382) <b>New Thandy Features</b>
383) <br />
384) Priority: <i>Medium</i>
385) <br />
386) Effort Level: <i>Medium</i>
387) <br />
388) Skill Level: <i>Medium to High</i>
389) <br />
390) Likely Mentors: <i>Martin</i>
391) <br />
392) Additional capabilities are needed for assisted updates of all the Tor
393) related software for Windows and other operating systems. Some of the
394) features to consider include:

395) <ol>

396) <li> Integration of the <a
397) href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto
398) Python library</a>
399) for authenticated HTTPS downloads.</li>
400) <li> Adding a level of indirection
401) between the timestamp signatures and the package files included in an
402) update. See the "Thandy attacks / suggestions" thread on or-dev.</li>
403) <li> Support locale specific installation and configuration of assisted
404) updates based on preference, host, or user account language settings.
405) Familiarity with Windows codepages, unicode, and other character sets
406) is helpful in addition to general win32 and posix API experience and
407) Python proficiency.</li>

408) </ol>

409) </li> -->

410) <li>

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

428) </li>

429) 

430) <li>

431) <b>Une meilleure et plus utile carte du réseau dans Vidalia</b> <br />
432) Priorité: <i>Faible à Moyenne</i> <br /> Effort à fournir: <i>Moyen</i> <br
433) /> Compétences requises: <i>Moyennes</i> <br /> Tuteurs potentiels:
434) <i>Matt</i> <br /> Une des fonctionnalités courantes de Vidalia est la carte
435) du réseau qui montre à l'utilisateur l'emplacement approximatif des relais
436) du réseau Tor et qui trace les chemins empruntés par le trafic qui y est
437) injecté. La carte n'est pas très interactive pour le moment et est de
438) médiocre qualité graphique. A la place, nous avons implémenté le widget KDE
439) Marble pour nous donner une carte de meilleure qualité et nous permettre une
440) meilleure interactivité tel que l'affichage des informations d'un relais ou
441) d'un chemin lorsqu'on clique dessus. Nous voulons ajouter la possibilité
442) pour les utilisateurs de cliquer sur un relais ou un pays contenant un ou
443) plusieurs relais de sortie Tor et dire "Je veux que mes connexions de sortie
444) se fasse à partir d'ici.". <br /> Ce projet implique d'abord d'être
445) familiarisé avec Vidalia et l'API du widget Marble. On pourra ensuite
446) intégrer le widget dans Vidalia et adapter Marble à notre application, comme
447) rendre les circuits cliquables, l'enregistrement du cache des données de la
448) carte dans le répertoire de Vidalia et l'adaptation de certaines des
449) interfaces du widget.  <br /> Une personne intéressée par ce projet devrait
450) disposer d'une bonne expérience de développement en C++. Une expérience avec
451) Qt et Cmake serait un vrai plus.

452) </li>

453) 

454) <li>

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

463) </li>

464) 
465) 

466) 
467) <!--<li>
468) 
469) <b>Intermediate Level Network Device Driver</b>
470) <br />
471) Priority: <i>Low</i>
472) <br />
473) Effort Level: <i>High</i>
474) <br />
475) Skill Level: <i>High</i>
476) <br />
477) Likely Mentors: <i>Martin</i>
478) <br />
479) The WinPCAP device driver used by Tor VM for bridged networking does
480) not support a number of wireless and non-Ethernet network adapters.
481) Implementation of a intermediate level network device driver for win32
482) and 64bit would provide a way to intercept and route traffic over such
483) networks. This project will require knowledge of and experience with
484) Windows kernel device driver development and testing. Familiarity with
485) Winsock and Qemu would also be helpful.
486) </li>-->

487) <li>

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

508) </li>
509) 
510) <li>

511) <b>Améliorer la mise en paquets de Tor et Vidalia sur Debian/Ubuntu</b> <br
512) /> Priorité: <i>Moyenne</i> <br /> Effort à fournir: <i>Moyen</i> <br />
513) Compétences requises: <i>Moyennes</i> <br /> Tuteurs potentiels: <i>Erinn,
514) Peter</i> <br />Vidalia ne fonctionne pas correctement sous Debian et Ubuntu
515) avec les paquets par défaut de Tor. Les paquets Tor actuels lancement
516) automatiquement Tor en tant que démon sous le compte utilisateur debian-tor
517) et (visiblement) n'ont pas de directive <a
518) href="<gitblob>doc/spec/control-spec.txt">ControlPort</a> définie dans le
519) fichier de configuration torrc par défaut. En conséquence, Vidalia tente de
520) démarrer sont propre processus Tor étant donné qu'il ne peut se connecter au
521) Tor existant; à la suite de quoi , le processus Tor lancé par Vidalia génère
522) un message d'erreur peu compréhensible indiquant que Tor ne peut pas
523) utiliser ses ports d'écoute &mdash; ils sont déjà utilisé par le démon Tor
524) initial.  <br /> La solution implique soit d'indiquer à l'utilisateur
525) d'arrêter le démon existant et de laisser Vidalia démarrer son propre
526) processus Tor soit d'expliquer à l'utilisateur comment configurer un port de
527) contrôle et un mot de passe dans son torrc. Une meilleure solution pour
528) Debian serait d'utiliser la directive ControlSocket qui permet à Vidalia de
529) communiquer avec Tor via une socket Unix et cela pourrait être activé par
530) défaut dans les paquets Debian de Tor. Vidalia peut ensuite s'authentifier
531) sur Tor en utilisant l'authentification du système de fichier (cookie) si
532) l'utilisateur qui a lancé Vidalia est également dans le groupe debian-tor.
533) <br /> Ce projet implique d'abord le support de la directive ControlSocket
534) dans Vidalia. L'étudiant développera et testera alors les paquets Vidalia
535) pour Debian et Ubuntu de manière conforme aux standards d'empaquetage de
536) Debian et s'assurera qu'ils fonctionnent correctement avec les paquets Tor
537) existant. Nous pouvons aussi mettre en place un dépôt pour héberger les
538) nouveaux paquets Vidalia.  <br /> Le défi qui suit consiste à trouver un
539) moyen efficace pour Vidalia de pouvoir modifier la configuration de Tor
540) (torrc) même si celle-ci est située dans <code>/etc/tor/torrc</code> et
541) reste immuable. La meilleure idée que nous avons trouvée jusqu'à présent est
542) de faire passer cette configuration par le ControlSocket lorsque Vidalia
543) démarre mais c'est une méthode discutable car Tor se lance à chaque
544) démarrage avec une configuration différente de celle que désire
545) l'utilisateur. La deuxième idée consiste à faire écrire à Vidalia un fichier
546) temporaire torrc et demander à l'utilisateur de le déplacer manuellement
547) dans <code>/etc/tor/torrc</code> mais c'est également discutable car les
548) utilisateurs ne devraient pas gérer ces fichiers directement.  <br />Une
549) personne intéressée par ce projet doit disposer d'une certaine connaissance
550) des règles d'empaquetage dans Debian et avoir une expérience en C++. Des
551) compétences en QT seraient un vrai plus.

552) </li>
553) 
554) 

555) 
556) <!--<li>
557) 
558) <b>Tor/Polipo/Vidalia Auto-Update Framework</b>
559) <br />
560) We're in need of a good authenticated-update framework.
561) Vidalia already has the ability to notice when the user is running an
562) outdated or unrecommended version of Tor, using signed statements inside
563) the Tor directory information. Currently, Vidalia simply pops
564) up a little message box that lets the user know they should manually
565) upgrade. The goal of this project would be to extend Vidalia with the
566) ability to also fetch and install the updated Tor software for the
567) user. We should do the fetches via Tor when possible, but also fall back
568) to direct fetches in a smart way. Time permitting, we would also like
569) to be able to update other
570) applications included in the bundled installers, such as Polipo and
571) Vidalia itself.
572) <br />
573) To complete this project, the student will first need to first investigate
574) the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
575) their strengths, weaknesses, security properties, and ability to be
576) integrated into Vidalia. If none are found to be suitable, the student
577) will design their own auto-update framework, document the design, and
578) then discuss the design with other developers to assess any security
579) issues. The student will then implement their framework (or integrate
580) an existing one) and test it.
581) <br />
582) A person undertaking this project should have good C++ development
583) experience. Previous experience with Qt is helpful, but not required. One
584) should also have a good understanding of common security
585) practices, such as package signature verification. Good writing ability
586) is also important for this project, since a vital step of the project
587) will be producing a design document to review and discuss
588) with others prior to implementation.
589) </li>-->

590) <li>

591) <b>Améliorer le processus qualité de Tor: Intégration continue de
592) compilation</b> <br /> Priorité: <i>Moyenne</i> <br /> Effort à fournir:
593) <i>Moyen</i> <br /> Compétences requises: <i>Moyennes</i> <br /> Tuteurs
594) potentiels: <i>Erinn</i> <br /> Il serait très utile d'avoir un processus de
595) compilation automatisée pour Windows et pour les autres plateformes. Le but
596) d'avoir un tel environnement est de s'assurer que Windows ne reste pas à la
597) traîne sur aucun des logiciels employés dans le projet Tor. <br />Buildbot
598) semble être un bon choix car il supporte toutes les plateformes
599) surlesquelles Tor fonctionne. Consultez <a
600) href="http://en.wikipedia.org/wiki/BuildBot">l'article Wikipedia sur
601) buildbot</a>.<br /> Il y a sans doute de meilleures options que la personne
602) désirant gérer cette tâche doit évaluer. Toute personne travaillant sur ce
603) processus de compilation automatique doit avoir de l'expérience ou le désir
604) d'apprendre comment compiler l'ensemble du code source en lien avec Tor à
605) partir de rien. De plus, cette personne doit disposer d'une expérience dans
606) la compilation de logiciels sous l'environnement Windows car c'est le coeur
607) de cible à ne pas rater de ce projet. Ce travail impose d'utiliser le code
608) source de Tor mais uniquement du point de vue compilation et non
609) d'écriture.<br /> Ensuite, nous avons besoin d'automatiser nos tests de
610) performance pour toutes les plateformes. Nous disposons là encore de builbot
611) (sauf sur Windows &mdash; comme indiqué ci-dessus) pour automatiser nos
612) intégrations régulières de code et nos tests de compilation mais nous avons
613) besoin de mettre à jour nos tests de simulation réseau pour les versions les
614) plus récente de Tor. Enfin, nous avons besoin de lancer des tests réseau à
615) la fois sur une seule machine et également à travers plusieurs autres de
616) manière à tester automatiquement les changement de performance avec des
617) rôles différents.

618) </li>
619) 
620) 

621) 
622) <!--<li>
623) 
624) <b>Usability testing of Tor</b>
625) <br />
626) Priority: <i>Medium</i>
627) <br />
628) Effort Level: <i>Medium</i>
629) <br />
630) Skill Level: <i>Low to Medium</i>
631) <br />
632) Likely Mentors: <i>Andrew</i>
633) <br />
634) Especially the browser bundle, ideally amongst our target demographic.
635) That would help a lot in knowing what needs to be done in terms of bug
636) fixes or new features. We get this informally at the moment, but a more
637) structured process would be better.
638) </li>-->

639) <li>

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

667) utilisateurs de s'authentifier.  Quelques travaux sur ce sujet ont été
668) initiés par d'autres contributeurs; vous pouvez consultezr leurs progrès sur
669) <a href="http://github.com/anonirc/orc">http://github.com/anonirc/orc</a>.

670) </li>
671) 
672) <li>

673) <b>Faire fonctionner torsocks/dsocks sur OS X</b> <br /> Priorité:
674) <i>Moyenne</i> <br /> Effort à fournir: <i>Moyen</i> <br /> Compétences
675) requises: <i>Moyennes</i> <br /> Tuteurs potentiels: <i>?</i> <br /> <a
676) href="http://code.google.com/p/torsocks/">Torsocks</a> et <a
677) href="http://code.google.com/p/dsocks/">dsocks</a> sont des wrappers qui
678) fonctionnent avec des applications, en interceptent leurs connexions réseau
679) sortantes et les injectent dans Tor. L'objectif est de gérer les
680) applications qui ne supportent pas les proxy (ou qui ne les supportent pas
681) correctement). Ces wrappers doivent intercepter de nombreux appels
682) systèmes. Ces appels systèmes sous Linux sont complètement différents de
683) ceux de BSD. Ainsi, torsocks fonctionne bien sous Linux, dsocks fonctionne
684) bien sous BSD (bien qu'il soit moins bien maintenu et qu'il puisse rater
685) davantage d'appels systèmes) mais rien ne fonctionne bien sur les deux
686) systèmes. D'abord, il faut patcher dsocks pour qu'il utilise les commandes
687) de <i>mapadress</i> depuis l'interface de contrôle de manière à ne pas
688) perdre trop de temps pendant la résolution qui s'effectue dans Tor avant la
689) connexion. Ensuite, notre script <i>torify</i> doit détecter si tsocks ou
690) dsocks est installé et appelé celui qui est légitime. Cela implique
691) d'unifier l'interface de ces deux wrappers et peut-être de partager du code
692) entre eux ou bien d'en laisser tomber un des deux.

693) </li>
694) 
695) <li>

696) <b>Amener de nouvelles idées !</b> <br />Vous n'aimez aucune de celles qui
697) sont présentées ? Consultez <a
698) href="<gitblob>doc/roadmaps/2008-12-19-roadmap-full.pdf">la feuille de route
699) de développement</a> pour vous donner d'autres idées ou bien essayez
700) simplement Tor, Vidalia et Torbutton pour trouver quelles sont les points à
701) améliorer.  Quelques-unes <a href="<gittree>doc/spec/proposals/">des
702) propositions en cours</a> ont également besoin de développeurs.

703) </li>
704) 
705) </ol>
706) 

707) <a id="OtherCoding"></a>
708) <h2><a class="anchor" href="#OtherCoding">Autres idées de spécifications et de
709) code</a></h2>

710) <ol>

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

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

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

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

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

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

749) href="http://en.wikipedia.org/wiki/Fuzz_testing">du "fuzz"</a>. Déterminer
750) s'il existe déjà de bonnes bibliothèques de fuzz pour ce que nous voulons
751) faire. La célébrité pour celui grâce à qui une nouvelle version pourra voir
752) le jour !</li>
753) 
754) <li>Tor utilise TCP pour le transport et TLS pour le chiffrage des liens. C'est
755) simple et efficace, mais cela implique que toutes les unités (cellules) d'un
756) lien sont mises en attente lorsqu'un seul paquet est perdu, et cela signifie
757) que seuls des flux TCP peuvent être raisonnablement supportés. Nous avons
758) dressé une <a
759) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">
760) liste de raisons pour lesquelles nous n'avons pas bifurqué vers le transport
761) par UDP</a>, mais ce serait bien de voir cette liste se raccourcir. Nous
762) avons aussi proposé <a href="<gitblob>tor/doc/100-tor-spec-udp.txt">une
763) spécification pour Tor et UDP</a> &mdash; lisez-la et faites-nous part de
764) vos remarques et critiques, s'il-vous-plaît.</li>
765) 
766) <li>Nous ne sommes plus très loin d'avoir le support pour IPV6 entre les
767) serveurs de sorties et les adresses finales. Si IPV6 vous tient à cœur,
768) partir de là est sans doute un premier pas.</li>
769) 
770) <li>Nous avons besoin de générer les diagrammes du site web (par exemple les
771) images de "Comment fonctionne Tor ?" sur <a href="<page overview>">la page
772) d'aperçu</a> à partir d'une source de manière à pouvoir les traduire comme
773) du texte UTF-8 plutôt que de les éditer à la main avec Gimp. Nous voudrions
774) intégrer ce processus dans un fichier wml pour faciliter les traductions et
775) regénérer les images en plusieurs langues lorsque nous construisons le site
776) web.</li>
777) 
778) <li>Comment pouvons-nous maintenir, améliorer et documenter plus facilement les
779) différents systèmes LiveCD/USB ? <a href="http://amnesia.boum.org/">Le
780) LiveCD/USB amnesia</a>et <a
781) href="http://anonymityanywhere.com/incognito/">le LiveCD Incognito</a> sont
782) quelques exemples.
783) </li>

784) 
785) <li>
786) Another anti-censorship project is to try to make Tor more
787) scanning-resistant.  Right now, an adversary can identify <a
788) href="<gitblob>doc/spec/proposals/125-bridges.txt">Tor bridges</a> just by
789) trying to connect to them, following the Tor protocol, and seeing if they
790) respond.  To solve this, bridges could <a

791) href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">act like

792) webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools, and
793) not act like bridges until the user provides a bridge-specific key.  To
794) start, check out Shane Pope's <a
795) href="http://dl.dropbox.com/u/37735/index.html">thesis and prototype</a>.
796) </li>
797) 

798) </ol>
799) 
800) <a id="Research"></a>
801) <h2><a class="anchor" href="#Research">Recherche</a></h2>
802) <ol>

803) <li>"L'attaque par empreinte de sites": faire une liste de quelques centaines de
804) sites populaires, en télécharger les pages, et faire des "signatures" pour
805) chaque site. Ensuite, observer le trafic d'un client Tor. L'analyse de ses
806) réceptions de données donne rapidement une idée des sites qu'il
807) visite. Premièrement, quelle est l'efficacité de cette attaque sur le code
808) actuellement utilisé dans Tor ? Ensuite, tester les défenses possibles : par
809) exemple, changer la taille des cellules de Tor de 512 octets à 1024,
810) utiliser des techniques de remplissage comme <a
811) href="http://freehaven.net/anonbib/#timing-fc2004">le lâcher défensif</a>,
812) ou ajouter des délais de trafic. Quel impact ces stratégies de défense
813) ont-elles, et, dans les cas où elles sont efficaces en défense, quel impact
814) ont-elles en terme de perte d'utilisabilité de Tor (à quantifier) ?</li>
815) <li>"L'attaque par corrélation des trafics aux extrémités": par l'observation
816) des trafics de Alice et Bob, il est possible de <a
817) href="http://freehaven.net/anonbib/#danezis:pet2004">comparer les signatures
818) des trafics et d'en déduire qu'il s'agit du même flux</a>. Jusqu'ici, Tor
819) considère ce type d'attaque comme intrinsèque et donc inévitable. Tout
820) d'abord, est-ce réellement vrai ? Quelle quantité de trafic - et avec quelle
821) distribution - est-elle nécessaire pour que l'adversaire soit certain
822) d'avoir gagné ? Est-ce qu'il existe des scénarios (par exemple avoir un
823) trafic faible) pour ralentir cette attaque ? Est-ce que certains types de
824) remplissage ou de modelage de trafic fonctionnent mieux que d'autres ?</li>
825) <li>On peut relier la question qui vient: Est-ce-que le fait de faire tourner un
826) relais/passerelle offre une protection supplémentaire contre ces attaques
827) basées sur les timings ? Un attaquant externe qui ne peut voir l'intérieur
828) des flux TLS peut-il reconnaître de manière fiable les flux individuels ?
829) Est-ce-que le volume de trafic transféré dégrade cette possibilité ? Que
830) faire si le relais du client retarde délibérément le trafic montant pour
831) former une queue pouvant être utilisée pour mimer les timings du trafic
832) descendant du client pour le faire passer pour du trafic egalement relayé ?
833) Cette queue identique pourrait être également utilisée pour masquer les
834) temps du trafic montant du client à l'aide des techniques dites <a
835) href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptative
836) padding</a> sans avoir besoin de trafic supplémentaire. Est-ce-qu'un tel
837) entrelacement du trafic montant du client osbcurcit les temps pour des
838) attaquants externes ? Les stratégies doivent-elles être ajustées pour les
839) liens symétriques ? Ou bien est-ce plus évident que pour les liens
840) symétriques ?</li>
841) <li><a href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">L'attaque
842) d'Oakland 05</a> par Repeat Murdoch et Danezi sur le réseau Tor
843) acutel. Essayez de comprendre pourquoi elle fonctionne bien sur certains
844) noeuds et pas sur les autres. (Ma théorie est que les noeuds rapides avec
845) davantage de capacité résistent mieux à l'attaque). On peut expérimenter
846) cette attaque avec la gestion des options RelayBandwithRate et
847) RelayBandwithBurst pour faire tourner un relais utilisé comme client tout en
848) relayant le traffic de l'attaquant: si nous limitons fortement le
849) RelayBandwithRate, est-ce-que l'attaque est plus difficile ? Quel est le
850) ratio correct de RelayBandwithRate par rapport à la capacité ? D'ailleurs,
851) est-ce-que le ratio joue un rôle dans cette attaque ? Pendant qu'on y est,
852) est-ce-qu'un plus grand nombre de relais candidats augmente le taux de faux
853) positifs ou une autre complexité dans l'attaque ? (Le réseau Tor est
854) maintenant deux fois plus étendu qu'il ne l'était au moment de la rédaction
855) de leur papier). Prenez également le temps de consulter le document <a
856) href="http://freehaven.net/anonbib/#clog-the-queue">Don't Clog the
857) Queue</a>.</li>
858) <li>L'attaque "routing zones": la majorité de ce qui est écrit sur Tor modélise
859) le chemin réseau entre Alice et son noeud d'entrée (et entre Bob et le noeud
860) de sortie) comme un simple lien sur un graphe. En pratique, le chemin
861) traverse de nombreux systèmes automomes (SA) et <a
862) href="http://freehaven.net/anonbib/#feamster:wpes2004">il n'est pas rare que
863) le même SA apparaissent à la fois sur le chemin d'entrée comme sur le chemin
864) de retoure</a>.  Malheureusement, pour être sûr de prédire si un quartet
865) Alice, noeud d'entrée, noeud de sortie, Bob sera dangereux, il faut
866) télécharger entièrement une zone de routage Internet et effectuer de
867) couteuses opérations dessus. Existe-t-il des approximations pratiques comme
868) éviter les adresse IP situées dans le même réseau /8 ?</li>
869) <li>D'autres points de recherche se pose la question de savoir, d'un point de
870) vue diversité géographique, s'il est mieux d'avoir un circuit efficace ou de
871) choisir un circuit au hasard. Consultez <a
872) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">les
873) travaux de Stephen Rollyson</a> qui expliquent comment éviter les choix
874) particulièrement inefficaces sans "trop" compromettre l'anonymat. Cet angle
875) d'attaque a besoin d'être creusé et travaillé mais il a l'air très
876) prometteur.</li>
877) <li>Tor ne fonctionne pas bien lorsque les relais disposent d'une bande passante
878) asymétrique (ex: câble ou ADSL). Etant donné que Tor sépare les connexions
879) entre chaque hop, si les octets entrants arrivent trop vite et que du coup,
880) les octets sortants arrivent plus lentement, les mécanismes de push-back de
881) TCP ne retournent pas cette information aux flux entrants.  Peut-être que
882) Tor devrait détecter les rejets de paquets sortants et réguler les flux
883) entrants de lui-même ? J'imagine un schéma d'ouverture/fermeture où l'on
884) récupère un taux de transfert limite donné qu'on incrémente lentement
885) jusqu'à perdre des paquets, moment où l'on diminuerait le taux, etc... Nous
886) avons besoin de quelqu'un disposant de sérieuses compétences réseau pour
887) simuler cela et apporter son aide pour la mise en place de ces
888) fonctionnalités. Nous avons besoin de comprendre l'importance de la
889) dégradation des performances et de l'utiliser comme élément moteur en vue de
890) reconsidérer le transport par UDP.</li>
891) <li>Le contrôle de la congestion est un sujet proche. Est-ce-que notre
892) spécification permet de gérer les fortes charges ? Peut-être devrions-nous
893) expérimenter des fenêtres de tailles variables plutôt que des fenêtres fixes
894) ? Cela semble prometteur dans <a
895) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">cette
896) expérimentation autour de ssh</a>. Nous avons besoin de mesurer, de corriger
897) et peut-être de refondre quelquechose si les résultats s'avèrent bons.</li>

898) <li>Our censorship-resistance goals include preventing an attacker who's looking
899) at Tor traffic on the wire from <a
900) href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">distinguishing
901) it from normal SSL traffic</a>. Obviously we can't achieve perfect
902) steganography and still remain usable, but for a first step we'd like to
903) block any attacks that can win by observing only a few packets. One of the
904) remaining attacks we haven't examined much is that Tor cells are 512 bytes,
905) so the traffic on the wire may well be a multiple of 512 bytes.  How much
906) does the batching and overhead in TLS records blur this on the wire? Do
907) different buffer flushing strategies in Tor affect this? Could a bit of
908) padding help a lot, or is this an attack we must accept?</li>

909) <li>Les circuits Tor sont construit pas à pas. Ainsi, il est théoriquement
910) possible de faire sortir des flux à partir du second pas, d'autres à partir
911) du troisième et ainsi de suite. Cela semble une alternative séduisante car
912) elle permet de passer outre la limite en sortie de chaque relais. Mais si
913) nous voulons que chaque flux soit sécurisé, le chemin "le plus court" doit
914) obligatoirement avoir au moins 3 pas selon notre logique actuelle. Nous
915) devons examiner cette alternative sur l'aspect performance en balance de la
916) sécurité</li>
917) <li>Il n'est pas si difficile de faire du dénis de service sur les relais Tor ou
918) les autorités d'annuaire. Les clients forment-ils la meilleure réponse ?
919) Quelles sont les autres approches possibles ? Il serait bien qu'elles soient
920) compatibles avec le protocole Tor actuel.</li>
921) <li>Les programmes tels que <a href="<page torbutton/index>">Torbutton</a> ont
922) pour objectif de masquer le champ UserAgent de votre navigateur web en le
923) replaçant par une réponse uniforme pour tous les utilisateurs Tor. Ainsi, un
924) attaquant ne peut rien déduire de vous en regardant cet en-tête. Il essaye
925) de récupérer une chaîne communément utilisée par les utilisateurs
926) non-Tor. Première question: comment révélons-nous l'utilisation de Tor en
927) mettant à jour régulièrement ce champ ? Si nous le mettons à jour trop
928) souvent, nous supprimons nous-même de l'anonymat. Si nous ne le mettons pas
929) à jour souvent alors tous les utilisateurs de Tor se dévoileront car leur
930) navigateur web indiquera qu'ils utilisent tous une assez vieille version de
931) Firefox. La réponse à la question dépend certainement des versions de
932) Firefox utilisés dans la nature. Deuxième question: régulièrement, les gens
933) nous demande de modifier le champ UserAgent selon un cycle de N chaînes de
934) caractères différentes plutôt que de mettre toujours la même. Est-ce-que
935) cette approche est vraiment utile, malfaisante ou neutre ? A prendre en
936) considération: les cookies et le fait de reconnaître les utilisateurs de
937) Torbutton par leur rotation de UserAgents; les sites webs malicieux qui
938) n'attaque qu'un seul type de navigateur web; la réponse à la question un
939) impact la réponse à la question deux.
940) </li>
941) <li>Actuellement, les clients Tor réutilisent un circuit donné pendant les dix
942) minutes qui suivent sa première utilisation. L'objectif est d'éviter de
943) surcharger le réseau avec des opérations de circuits étendus et également
944) pour éviter que les clients utilisent le même circuit pendant trop longtemps
945) ce qui permettrait au noeud de sortie de les profiler. Hélas, dix minutes
946) est une période de temps sans doute trop longue, spécialement si des
947) connexions vers des protocoles différents (ex messagerie instantanée et
948) navigation internet) utilisent le même circuit. Si nous continuons à fixer
949) le nombre global de la taille des circuits que le réseau a besoin d'établir,
950) existe-t-il de meilleurs et/ou de plus sûrs moyens pour les clients
951) d'affecter des flux aux circuits ou bien pour que les clients construisent
952) des circuits préemptifs ? Peut-être que cet élément de recherche doit
953) commencer par récupérer des traces sur les connexions typiques que les
954) clients initient afin de disposer de données réalistes ?
955) </li>
956) <li>De combien de passerelles avez-vous besoin pour maintenir un bon niveau
957) d'accessibilité ? Nous devrions mesurer le contenu de nos passerelles. Si ce
958) contenu est bien fourni, existe-t-il des moyens de faire en sorte que les
959) utilisateurs de passerelles restent connectés plus longtemps ?

960) </li>

961) </ol>
962) 

963) <p>

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

966) </p>

967) 

968)   </div>

969) 

970)