tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 15882

3) # Last-Translator: mfr(ä]misericordia.be, fredzupy@gmail.com

4) 

5) #include "head.wmi" CHARSET="UTF-8" TITLE="Tor : Contribuer"

6) 
7) <div class="main-column">
8) 
9) <!-- PUT CONTENT AFTER THIS TAG -->

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

11) <ol>

12) <li>Pensez à <a href="<page docs/tor-doc-relay>">héberger 

13) un relais</a> pour aider à la croissance du réseau Tor.</li>

14) <li> Informez vos amis ! Faites-leur héberger des serveurs. Faites-leur utiliser les services 
15) cachés. Encouragez-les à informer leurs propres amis.</li>
16) <li> Si vous adhérez aux objectifs de Tor, prenez s'il-vous-plaît un moment 

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

24) </ol>
25) 
26) <a id="Usability"></a>

27) <h2><a class="anchor" href="#Usability">Supporting Applications</a></h2>

28) <ol>

29) <li>Nous avons besoin de méthodes plus efficaces d'interception des requêtes DNS, pour qu'elles ne laissent pas transparaitre d'informations à un observateur local pendant que nous tentons d'être anonymes. (Ce qui 

30) arrive lorsque l'application fait sa résolution DNS avant de passer par 
31) le proxy SOCKS.)</li>

32) <li>Éléments tsocks/dsocks :

33) <ul>

34) <li>Nous avons besoin <a href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">d'appliquer 

35) tout nos patchs à tsocks</a> et d'en maintenir une nouvelle branche. Nous l'hébergerons si 
36) vous le souhaitez.</li>
37) <li>Nous devrions patcher le programme « dsocks » développé par Dug Song pour utiliser les commandes 
38) <i>mapaddress</i> de Tor depuis l'interface de contrôle, de manière à ne pas faire 
39) inutilement un aller-retour complet dans Tor pour faire la résolution avant la 
40) connexion.</li>
41) <li>Notre script <i>torify</i> doit détecter lequel de tsocks ou 
42) dsocks est installé pour l'appeler correctement. Cela nécessite certainement 
43) d'unifier leurs interfaces, et peut amener à faire un mix des deux 
44) voire à en éliminer un des deux.</li>

45) </ul>

46) </li>

47) <li>Les gens qui hébergent des serveurs nous signalent qu'ils aimeraient avoir une passante allouée 

48) durant une partie de la journée, et une autre bande passante à d'autre moment de la journée.

49) Plutôt que de coder ceci dans Tor, nous aimerions utiliser un petit 
50) script qui communique avec <a href="<page gui/index>">l'interface de contrôle de Tor</a>, 

51) et ferait un setconf pour changer la valeur de la bande passante.
52) Il en existe dejà un pour Unix et Mac (qui utilise bash et cron),
53) mais les utilisateurs de Windows ont encore besoin d'une solution.

54) </li>
55) <li>Tor peut <a 

56) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">quitter 

57) le réseau Tor par un noeud de sortie particulier</a>, mais il serait pratique 
58) de n'avoir qu'à spécifier un pays, et que le serveur de sortie soit choisi automatiquement. Le 
59) meilleur moyen est probablement de récupérer le répertoire de Blossom, et d'utiliser en local un client 
60) qui récupère ce répertoire de manière sûre (via Tor et en vérifiant sa 

61) signature), lise les noms des machines <tt>.country.blossom</tt> et se charge
62)  ensuite de choisir le serveur.</li>
63) <li>En parlant de géolocalisation, quelqu'un devrait faire une carte de
64)  la Terre indiquant chaque serveur Tor par un point. La cerise sur le gâteau 
65) 	serait la mise à jour dynamique de la carte à mesure que le réseau Tor évolue
66)  et grandit. Malheureusement, les moyens aisés de faire cela passent par l'envoi
67)  de toutes les données à Google pour qu'il trace cette carte pour vous.
68)  Dans quelle mesure cela jouerait-il sur la confidentialité, et par ailleurs, 
69) 	existe-t-il des solutions de remplacement valables ?</li>

70) </ol>
71) 
72) <a id="Documentation"></a>
73) <h2><a class="anchor" href="#Documentation">Documentation</a></h2>
74) <ol>

75) <li>Aidez Matt Edman à documenter et à écrire des tutoriaux pour son 
76) contrôleur Tor,
77) <a href="http://vidalia-project.net/">Vidalia</a>.</li>
78) <li>Évaluez et documentez 

79) <a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">notre 

80) liste de programmes</a> pouvant être utilisés avec Tor.</li>
81) <li>Nous avons besoin d'une meilleure documentation traitant de l'interception dynamique de 
82) connexions et de leur envoi à travers Tor. tsocks (Linux), dsocks (BSD), 
83) et freecap (Windows) semblent être de bons candidats, et utiliserait au mieux
84) notre nouvelle fonctionnalité Transport.</li>

85) <li>Nous avons toute une liste de <a href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">programmes 

86) potentiellement utiles qui s'interfacent avec Tor</a>. Lesquels sont utiles et dans quelles 

87) situations ? Contribuez à les tester et à documenter les résultats.</li>

88) <li>Aidez-nous à traduire le site et la documentation dans d'autres 
89) langues. Allez voir les <a href="<page translation>">conseils de 

90) traduction</a> si vous souhaitez le faire. Nous avons besoin plus spécialement de personnes pour 
91) traduire en Arabe ou en Persan pour les utilisateurs Tor situés dans les zones censurées.</li>

92) </ol>
93) 
94) <a id="Coding"></a>

95) <a id="Summer"></a>
96) <a id="Projects"></a>

97) <h2><a class="anchor" href="#Projects">Bons Projets de codage</a></h2>
98) <p>Vous pouvez trouver que certains de ces projets sont de bonnes idées pour le <a href="<page
99)   	 gsoc>">Google Summer of Code 2008</a>. Nous avons marqué chaque idée en fonction de l'utilité qu'il apporte à l'ensemble du projet Tor (priorité), de la quantité de travail que nous estimons (niveau d'effort), du l'expérience que vous devriez avoir pour commencer (niveau de qualification), et qui de <a href="<page
100)   	 people>#Core">nos principaux développeurs</a> pourrait être de bons tuteurs. Il ya plein d'autres bonnes idées pour travailler - voir par exemple la liste des <a
101)   	 href="<svnsandbox>doc/spec/proposals/">propositions actuelles</a>, ou tout simplement vos propres idées.</p>

102) <ol>

103) 

104) <li>

105) <b>Amélioration du scanneur des sorties Tor</b>

106) <br />
107) Priorité : <i>élevée</i>
108) <br />
109) Niveau d'effort : <i>élevé</i>
110) <br />

111) Niveau de compétence: <i>élevé</i>

112) <br />
113) Mentors supposés : <i>Mike</i>
114) <br />

115) Demandes au premier Avril 00:00 UTC: <i>5</i>

116) <br />
117) 
118) Le scanner des nœuds de sortie Tor 'SoaT', partie du <a
119) href="<svnsandbox>torflow/">projet Torflow</a>, est
120) pour l'instant écrit dans un perl plutôt bancal et s'appuie sur des MD5sums de
121) documents entiers dans le but de savoir si un nœud de sortie modifie les contenus. 
122) The problem with this is threefold: 1) Perl sucks at life.
123) 2) The scanner can't verify pages that are dynamic, and attackers can
124) focus malicious content injection on only those dynamic pages. 3)
125) Pages change after a while (or based on GeoIP) and begin generating
126) false positives.
127) <br />
128) Ideally, soat.pl would be reimplemented in a sane language with a
129) robust html parser library (since the rest of Torflow is in Python
130) that would be nice, but it is not required), and calculate signatures only for
131) tags and content likely to be targeted by a malicious attacker (script
132) tags, object links, images, css). It should also be robust in the face of
133) changes to content outside of Tor, and ultimately even GeoIP localized
134) content.
135) <br />
136) This scanner would likely be run by the Directory Authorities and
137) report its results to the control port via the AuthDirBadExit config
138) setting.
139) <br />
140) </li>
141) 
142) <li>
143) <b>Amélioration du scanner de noeux Tor</b>
144) <br />

145) Priorité: <i>élevé</i>

146) <br />

147) Niveau d'effort : <i>moyen à élevé</i>

148) <br />

149) Niveau de difficulté : <i>moyen à élevé</i>

150) <br />
151) Mentors supposés : <i>Mike</i>
152) <br />

153) Demandes au premier Avril 00:00 UTC: <i>1</i>

154) <br />
155) Similar to the exit scanner (or perhaps even during exit scanning),
156) statistics can be gathered about the reliability of nodes. Nodes that
157) fail too high a percentage of their circuits should not be given
158) Guard status. Perhaps they should have their reported bandwidth
159) penalized by some ratio as well, or just get marked as Invalid. In
160) addition, nodes that exhibit a very low average stream capacity but
161) advertise a very high node bandwidth can also be marked as Invalid.
162) Much of this statistics gathering is already done, it just needs to be
163) transformed into something that can be reported to the Directory
164) Authorities to blacklist/penalize nodes in such a way that clients
165) will listen.
166) <br />
167) In addition, these same statistics can be gathered about the traffic
168) through a node. Events can be added to the <a
169) href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor Control
170) Protocol</a> to
171) report if a circuit extend attempt through the node succeeds or fails, and
172) passive statistics can be gathered on both bandwidth and reliability
173) of other nodes via a node-based monitor using these events. Such a
174) scanner would also report information on oddly-behaving nodes to
175) the Directory Authorities, but a communication channel for this
176) currently does not exist and would need to be developed as well.
177) </li>
178) 
179) <li>
180) <b>Help track the overall Tor Network status</b>
181) <br />

182) Priorité: <i>élevé</i>

183) <br />

184) Niveau d'effort : <i>moyen</i>

185) <br />

186) Niveau de difficulté : <i>moyen</i>

187) <br />
188) Mentors supposés : <i>Roger, Nick, Mike</i>
189) <br />
190) It would be great to set up an automated system for tracking network
191) health over time, graphing it, etc. Part of this project would involve
192) inventing better metrics for assessing network health and growth. Is the
193) average uptime of the network increasing? How many relays are qualifying
194) for Guard status this month compared to last month? What's the turnover
195) in terms of new relays showing up and relays shutting off? Periodically
196) people collect brief snapshots, but where it gets really interesting is
197) when we start tracking data points over time.
198) <br />
199) Data could be collected from the "Tor Node Scanner" item above, from
200) the server descriptors that each relay publishes, and from other
201) sources. Results over time could be integrated into one of the <a
202) href="https://torstatus.blutmagie.de/">Tor Status</a> web pages, or be
203) kept separate. Speaking of the Tor Status pages, take a look at Roger's
204) <a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">Tor
205) Status wish list</a>.
206) </li>
207) 
208) <li>
209) <b>Tor path selection improvements</b>
210) <br />

211) Priorité: <i>élevé</i>

212) <br />

213) Niveau d'effort : <i>faible à moyen</i>

214) <br />

215) Niveau de difficulté : <i>élevé</i>

216) <br />
217) Mentors supposés : <i>Roger, Nick, Mike</i>
218) <br />

219) Demandes au premier Avril 00:00 UTC: <i>3</i>

220) <br />
221) Some simple improvements can be made to Tor's path selection to vastly
222) improve Tor speed. For instance, some of the (unofficial) <a
223) href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Tor
224) Performance Recommendations</a> on the wiki are to increase the number of
225) guards and decrease the CircuitBuildTimeout. Ideally, the client would
226) <a href="http://archives.seul.org/or/talk/Feb-2008/msg00012.html">learn
227) these values by gathering statistics on circuit construction
228) time</a> (and/or using values gained from Torflow), and set the timeouts
229) low enough such that some high percentile (75%, 90%, 1-stddev?) of
230) circuits succeed, yet extremely slow nodes are avoided. This would
231) involve some statistics gathering+basic research, and some changes to
232) Tor path selection code.
233) <br />
234) In addition, to improve path security, some elements from the <a
235) href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt">Two
236) Hop Paths proposal</a> could be done as part of this (since it will
237) likely touch the same code anyways), regardless of the adoption of
238) that proposal. In particular, clients probably should avoid guards that
239) seem to fail an excessive percentage of their circuits through them,
240) and non-firewalled clients should issue a warning if they are only able
241) to connect to a limited set of guard nodes. See also
242) <a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html">this
243) or-dev post</a>.
244) </li>
245) 
246) <li>
247) <b>Translation Wiki</b>
248) <br />

249) Priorité: <i>élevé</i>

250) <br />

251) Niveau d'effort : <i>moyen</i>

252) <br />

253) Niveau de difficulté : <i>moyen</i>

254) <br />
255) Mentors supposés : <i>Jacob</i>
256) <br />
257) Nous avons besoin d'un moyen d'éditer et traduire le éléments du site web. 
258) Actuellement le site web est fait d'un lot de <a href="<svnwebsite>en/">fichiers wml
259) </a>, et <a href="<page translation>">les traducteurs</a> vont chercher ces
260) fichiers wml, les traduisent dans un éditeur, et soit nous envoient la traduction
261) ou utilisent svn pour valider leur traduction.
262) L'actuel «coût» de la publication des modifications apportées au site Web 
263) est assez élevé, même pour l'anglais.
264) Pour changer un seul mot ou n'importe quel type de changement mineur, 
265) la page peut ne jamais être corrigée ou traduite. Il serait
266) bien d'avoir un wiki qui a été spécialement conçu pour la traduction
267) et qui pourrait traquer à partir de la version officielle (anglaise) si
268) une nouvelle traduction est nécessaire, comme notre actuelle 
269) <a href="<page translation-status>">page d'état de traduction</a>.
270) Cela semble être le travail d'un intégrateur wiki
271) ou un auteur de logiciel wiki. Certes, la personne devra
272) être intéressées par les langues et la traduction. Il devrait au moins
273) à minima être familier avec ce que Tor est mais n'aurait pas d'interaction
274) avec le logiciel, seulement la documentation sur le site.
275) </li>
276) 
277) <li>
278) <b>Améliorer la mise en paquet Debian/Ubuntu pour Tor+Vidalia</b>
279) <br />

280) Priorité: <i>élevé</i>

281) <br />

282) Niveau d'effort : <i>moyen</i>

283) <br />

284) Niveau de difficulté : <i>moyen</i>

285) <br />
286) Mentors supposés : <i>Peter, Matt</i>
287) <br />

288) Demandes au premier Avril 00:00 UTC: <i>1</i>

289) <br />
290) Vidalia currently doesn't play nicely on Debian and Ubuntu with the
291) default Tor packages. The current Tor packages automatically start Tor
292) as a daemon running as the debian-tor user and (sensibly) do not have a
293) <a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined
294) in the default torrc. Consequently, Vidalia will try
295) to start its own Tor process since it could not connect to the existing
296) Tor, and Vidalia's Tor process will then exit with an error message
297) the user likely doesn't understand since Tor cannot bind its listening
298) ports &mdash; they're already in use by the original Tor daemon.
299) <br />
300) The current solution involves either telling the user to stop the
301) existing Tor daemon and let Vidalia start its own Tor process, or
302) explaining to the user how to set a control port and password in their
303) torrc. A better solution on Debian would be to use Tor's ControlSocket,
304) which allows Vidalia to talk to Tor via a Unix domain socket, and could
305) possibly be enabled by default in Tor's Debian packages. Vidalia can
306) then authenticate to Tor using filesystem-based (cookie) authentication
307) if the user running Vidalia is also in the debian-tor group.
308) <br />
309) This project will first involve adding support for Tor's ControlSocket
310) to Vidalia. The student will then develop and test Debian and Ubuntu
311) packages for Vidalia that conform to Debian's packaging standards and
312) make sure they work well with the existing Tor packages. We can also
313) set up an apt repository to host the new Vidalia packages.
314) <br />
315) The next challenge would be to find an intuitive usable way for Vidalia
316) to be able to change Tor's configuration (torrc) even though it is
317) located in <code>/etc/tor/torrc</code> and thus immutable. The best
318) idea we've come up with so far is to feed Tor a new configuration via
319) the ControlSocket when Vidalia starts, but that's bad because Tor starts
320) each boot with a different configuration than the user wants. The second
321) best idea
322) we've come up with is for Vidalia to write out a temporary torrc file
323) and ask the user to manually move it to <code>/etc/tor/torrc</code>,
324) but that's bad because users shouldn't have to mess with files directly.
325) <br />
326) A student undertaking this project should have prior knowledge of
327) Debian package management and some C++ development experience. Previous
328) experience with Qt is helpful, but not required.
329) </li>
330) 

331) <li>

332) <b>Accroitre la capacité de Tor à résister à la censure.</b>
333) <br />

334) Priorité: <i>élevé</i>

335) <br />

336) Niveau d'effort : <i>élevé</i>

337) <br />

338) Niveau de difficulté : <i>élevé</i>

339) <br />
340) Mentors supposés : <i>Nick</i>
341) <br />
342) The Tor 0.2.0.x series makes <a
343) href="<svnsandbox>doc/design-paper/blocking.html">significant
344) improvements</a> in resisting national and organizational censorship.
345) But Tor still needs better mechanisms for some parts of its
346) anti-censorship design.  For example, current Tors can only listen on a
347) single address/port combination at a time.  There's
348) <a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">a
349) proposal to address this limitation</a> and allow clients to connect
350) to any given Tor on multiple addresses and ports, but it needs more
351) work.  Another anti-censorship project (far more difficult) is to try
352) to make Tor more scanning-resistant.  Right now, an adversary can identify
353) <a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">Tor bridges</a>
354) just by trying to connect to them, following the Tor protocol, and
355) seeing if they respond.  To solve this, bridges could
356) <a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">act like
357) webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,
358) and not act like bridges until the user provides a bridge-specific key.
359) <br />
360) This project involves a lot of research and design. One of the big
361) challenges will be identifying and crafting approaches that can still
362) resist an adversary even after the adversary knows the design, and
363) then trading off censorship resistance with usability and robustness.
364) </li>
365) 
366) <li>
367) <b>Tor/Polipo/Vidalia Auto-Update Framework</b>
368) <br />

369) Priorité: <i>moyen</i>

370) <br />

371) Niveau d'effort : <i>élevé</i>

372) <br />

373) Niveau de difficulté : <i>élevé</i>

374) <br />
375) Mentors supposés : <i>Matt, Jacob</i>
376) <br />
377) We're in need of a good authenticated-update framework.
378) Vidalia already has the ability to notice when the user is running an
379) outdated or unrecommended version of Tor, using signed statements inside
380) the Tor directory information. Currently, Vidalia simply pops
381) up a little message box that lets the user know they should manually
382) upgrade. The goal of this project would be to extend Vidalia with the
383) ability to also fetch and install the updated Tor software for the
384) user. We should do the fetches via Tor when possible, but also fall back
385) to direct fetches in a smart way. Time permitting, we would also like
386) to be able to update other
387) applications included in the bundled installers, such as Polipo and
388) Vidalia itself.
389) <br />
390) To complete this project, the student will first need to first investigate
391) the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
392) their strengths, weaknesses, security properties, and ability to be
393) integrated into Vidalia. If none are found to be suitable, the student
394) will design their own auto-update framework, document the design, and
395) then discuss the design with other developers to assess any security
396) issues. The student will then implement their framework (or integrate
397) an existing one) and test it.
398) <br />
399) A student undertaking this project should have good C++ development
400) experience. Previous experience with Qt is helpful, but not required. The
401) student should also have a good understanding of common security
402) practices, such as package signature verification. Good writing ability
403) is also important for this project, since a vital step of the project
404) will be producing a design document for others to review and discuss
405) with the student prior to implementation.
406) </li>
407) 
408) <li>
409) <b>Une carte du réseau dans Vidalia, améliorée et plus pratique</b>
410) <br />

411) Priorité: <i>moyen</i>

412) <br />

413) Niveau d'effort : <i>moyen</i>

414) <br />

415) Niveau de difficulté : <i>moyen à élevé</i>

416) <br />
417) Mentors supposés : <i>Matt</i>
418) <br />
419) L'une des composantes existantes de Vidalia est une carte du réseau qui montre 
420) la localisation géographique approximative du relais dans le réseau Tor et

421) trace le chemin du trafic utilisateur tel qu'il est tunnellisé à travers le
422) réseau Tor. La carte n'est pour l'instant pas très interactive et est plutôt 
423) pauvre graphiquement. À la place, nous  aimerions profiter du widget Marble de KDE
424) qui nous apporterait une carte de meilleur qualité et étendrait l'interactivité,
425) en permettant à l'utilisateur de cliquer sur des relais ou circuit pour 
426) obtenir des informations supplémentaires. Il serait aussi souhaitable de permettre
427) à l'utilisateur de cliquer sur un relais particulier ou un pays contenant un ou
428) plusieurs relais Tor de sortie et dire « je souhaite que mes connexions à truc.com sortent
429) par là ».
430) <br />
431) Ce projet nécessite d'abord que l'étudiant soit à l'aise avec Vidalia
432) et l'API de l'objet Marble. L'étudiant devra alors intégrer l'objet dans 
433) Vidalia et configurer Marble pour s'indapter dans notre application,
434) comme faire des circuits cliquable, stocker des données cartes dans le répertoire
435) de donnée de Vidalia, et adapter quelques une des boites de dialogue.
436) <br />
437) L'étudiant prenant en charge ce projet devra avoir une bonne expérience en 
438) développement C++. Une expérience avec Qt et CMake est utile, mais non
439) requise.
440) </li>

441) 

442) <li>

443) <b>Tor Controller Status Event Interface</b>
444) <br />

445) Priorité: <i>moyen</i>

446) <br />

447) Niveau d'effort : <i>moyen</i>

448) <br />

449) Niveau de difficulté : <i>moyen</i>

450) <br />
451) Mentors supposés : <i>Matt, Roger</i>
452) <br />
453) There are a number of status changes inside Tor of which the user may need
454) to be informed. For example, if the user is trying to set up his Tor as a
455) relay and Tor decides that its ports are not reachable from outside
456) the user's network, we should alert the user. Currently, all the user
457) gets is a couple log messages in Vidalia's 'message log' window, which they
458) likely never see since they don't receive a notification that something
459) has gone wrong. Even if the user does actually look at the message log,
460) most of the messages make little sense to the novice user.
461) <br />
462) Tor has the ability to inform Vidalia of many such status changes, and
463) we recently implemented support for a couple of these events. Still,
464) there are many more status events the user should be informed of and we
465) need a better UI for actually displaying them to the user.
466) <br />
467) The goal of this project then is to design and implement a UI for
468) displaying Tor status events to the user. For example, we might put a
469) little badge on Vidalia's tray icon that alerts the user to new status
470) events they should look at. Double-clicking the icon could bring up a
471) dialog that summarizes recent status events in simple terms and maybe
472) suggests a remedy for any negative events if they can be corrected by
473) the user. Of course, this is just an example and the student is free to
474) suggest another approach.
475) <br />
476) A student undertaking this project should have good UI design and layout
477) and some C++ development experience. Previous experience with Qt and
478) Qt's Designer will be very helpful, but are not required. Some
479) English writing ability will also be useful, since this project will
480) likely involve writing small amounts of help documentation that should
481) be understandable by non-technical users. Bonus points for some graphic
482) design/Photoshop fu, since we might want/need some shiny new icons too.

483) </li>

484) 

485) <li>
486) <b>Améliorations de notre testeur de configuration active de navigateur</b> -

487) <a href="https://check.torproject.org/">https://check.torproject.org/</a>
488) <br />

489) Priorité: <i>moyen</i>

490) <br />

491) Niveau d'effort : <i>faible</i>

492) <br />

493) Niveau de difficulté : <i>faible à moyen</i>

494) <br />
495) Mentors supposés : <i>Jacob, Steven</i>
496) <br />

497) Demandes au premier Avril 00:00 UTC: <i>1</i>

498) <br />
499) Actuellement, nous avons une page Web fonctionnelle pour détecter si Tor fonctionne. Il  	 
500) ya des manques à quelques endroits. Il nécessite quelques améliorations s'agissant
501) des langues par défaut et des fonctionnalités. Il répond pour l'instant qu'en
502) Anglais. De plus, c'est un hack d'un script perl qui n'aurait
503) jamais dû voir le jour. Il devrait être réécrit en python

504) avec un support multi-langues. Il utilise actuellement <a
505) href="http://exitlist.torproject.org/">la liste de sortie DNS 
506) Tor</a> et devrait continuer à faire de même dans le futur. Il peut y avoir de temps en temps
507) des faux positifs et ceci devrait être découvert, documenté et corrigé lorsque 

508) c'est possible. Toute personne travaillant sur ce projet devrait être interessée par 
509) DNS, les bases de perl ou de préférence python et auront un peu à interagir avec
510) Tor pour tester leur code.

511) <br />
512) If you want to make the project more exciting
513) and involve more design and coding, take a look at <a
514) href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal
515) 131-verify-tor-usage.txt</a>.

516) </li>

517) 

518) <li>
519) <b>Amélioration de notre liste de sortie DNS</b> -

520) <a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a>
521) <br />

522) Priorité: <i>moyen</i>

523) <br />

524) Niveau d'effort : <i>faible</i>

525) <br />

526) Niveau de difficulté : <i>faible</i>

527) <br />
528) Mentors supposés : <i>Jacob, Tup</i>
529) <br />
530) Le <a href="http://p56soo2ibjkx23xo.onion/">logiciel exitlist</a> est écrit par notre fabuleux contributeur anonyme Tup. C'est un serveur DNS écrit en Haskell qui supporte 
531) une partie de notre <a

532) href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt">document
533) de conception exitlist</a>. Actuellement, c'est fonctionnel et utilisé par
534) check.torproject.org et d'autres utilisateurs. Les problèmes qui sont en suspens
535) sont pour la plupart esthétiques. Ce service merveilleux pourrait bien mieux utiliser
536) le site web en utilisant la charte graphique Tor. It serait mieux servi avec une meilleure
537) documentation pour les services communs qui utilisent une RBL. Il pourrait y'avoir d'avantage
538) de publicité. La personne travaillant sur ce projet devrait être interessée par les DNS,
539) la configuration basique de RBL pour des services populaires, et écrire de la documentation.
540) La personne devrait avoir un peu d'interaction avec Tor &mdash; tester leur propre
541) documentation au minimum. De plus, ce serait utile
542) qu'il soit interessé par Haskell et souhaite implémenter d'avantages des suggestions du 
543) torel-design.txt.
544) </li>

545) 

546) <li>

547) <b>Tester l'intégration de Tor avec les navigateurs pour nos utilisateurs finaux</b>

548) <br />

549) Priorité: <i>moyen</i>

550) <br />

551) Niveau d'effort : <i>moyen</i>

552) <br />

553) Niveau de difficulté : <i>moyen</i>

554) <br />
555) Mentors supposés : <i>Jacob, Mike, Greg</i>
556) <br />

557) Demandes au premier Avril 00:00 UTC: <i>1</i>

558) <br />
559) Le Projet Tor manque actuellement d'un ensemble de tests efficaces pour s'assurer que 

560) l'utilisateur a proprement configuré son navigateur. Il devrait tester la plupart
561) des problèmes connus autant que possible. Il devrait essayer de découvrir 
562) l'utilisateur par tous les moyens possibles. Deux pages web qui tracent ces
563) type de problèmes sont fournies par Greg et HD Moore. Greg conserve une bonne <a
564) href="http://pseudo-flaw.net/tor/torbutton/">liste de problèmes avec 
565) leur code de preuve de concept, les bugs, etc</a>. HD Moore fournit
566) le <a href="http://metasploit.com/research/misc/decloak/">site
567) decloak</a>. Une personne interessée par l'attaque de Tor peut commencer

568) par collecter autant de solutions fonctionnelles et de méthodes connues pour révèler

569) un utilisateur Tor. La personne devrait être familière des écueils courants mais pourrait
570) avoir d'autres méthodes en tête pour implémenter des outils de désanonymisation. Le
571) site web devrait s'assurer d'informer l'utilisateur de ce que sont ses problèmes. Il
572) devra l'aider à les résoudre ou les renvoyer directement sur le bon canal de 
573) soutien. La personne devra être très familière dans l'utilisation de Tor et comment
574) palier aux fuites de Tor.
575) </li>

576) 

577) <li>
578) <b>Amélioration de l'intégration Libevent et Tor</b>
579) <br />

580) Priorité: <i>moyen</i>

581) <br />

582) Niveau d'effort : <i>élevé</i>

583) <br />

584) Niveau de difficulté : <i>moyen à élevé</i>

585) <br />
586) Mentors supposés : <i>Nick</i>
587) <br />

588) Tor devrait faire un meilleur usage des récentes options de Niels Provos dans

589) la bibliothèque <a href="http://monkey.org/~provos/libevent/">Libevent</a>.
590) Tor utilise dejà Libevent apour ces appels IO bas niveau, et peut aussi utiliser Libevent 
591) plus pour l'HTTP et les tampons de socket.
592) This wouldn't be simply a matter of replacing Tor's internal 
593) calls with calls to Libevent: instead, we'll
594) need to refactor Tor to use Libevent calls that do not follow the
595) same models as Tor's existing backends. Et nous aurons à améliorer le code
596) de libevent autant que nécessaire ; particulièrement, pour 
597) ajouter un bon support openssl au dessus de la couche d'abstraction 
598) des tampons de libevent.
599) Also tricky will be adding rate-limiting to Libevent.

600) </li>

601) 

602) <li>

603) <b>Accroitre les performances de Tor!</b>
604) <br />

605) Priorité: <i>moyen</i>

606) <br />

607) Niveau d'effort : <i>moyen</i>

608) <br />

609) Niveau de difficulté : <i>moyen à élevé</i>

610) <br />
611) Mentors supposés : <i>Nick, Roger, Mike</i>

612) <br />

613) Right now, Tor relays measure and report their own bandwidth, and Tor
614) clients choose which relays to use in part based on that bandwidth.
615) This approach is vulnerable to
616) <a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where
617) relays lie about their bandwidth</a>;
618) to address this, Tor currently caps the maximum bandwidth
619) it's willing to believe any relay provides.  This is a limited fix, and
620) a waste of bandwidth capacity to boot.  Instead,
621) Tor should possibly measure bandwidth in a more distributed way, perhaps
622) as described in the
623) <a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
624) Tor"</a> paper
625) by Snader and Borisov. A student could use current testing code to
626) double-check this paper's findings and verify the extent to which they
627) dovetail with Tor as deployed in the wild, and determine good ways to
628) incorporate them into their suggestions Tor network without adding too
629) much communications overhead between relays and directory
630) authorities.

631) </li>

632) 
633) <!--

634) <li>
635) <b>Améliorer le processus qualité de Tor : Intégration continue pour les paquets Windows</b>
636) <br />

637) Priorité: <i>élevé</i>

638) <br />

639) Niveau d'effort : <i>moyen</i>

640) <br />

641) Niveau de difficulté : <i>moyen</i>

642) <br />
643) Mentors supposés : <i>Jacob, Andrew</i>
644) <br />

645) Il serait interessant d'avoir une automatisation des compilation pour Windows et
646) probablement d'autres plateformes. Le but d'avoir une intégration continue
647) des environnements est de s'assurer que Windows n'est pas mis de coté pour aucun
648) des projets logiciels utilisés par le Projet Tor où ses contributions.<br />
649) Buildbot serait un bon choix pour ça puisqu'il semble supporter l'ensemble des 
650) platformes de Tor. Voyez l'
651) <a href="http://en.wikipedia.org/wiki/BuildBot">entrée wikipedia pour
652) buildbot</a>.<br />
653) Il pourrait y'avoir de meilleurs options et la personne prenant en charge cette tâche devrait
654) évaluer d'autres options. Toute personne travaillant sur ce processur de compilation 
655) automatique devrait avoir ou être en mesure d'avoir l'expérience pour apprendre à construire l'ensemble
656) des sources relatives à Tor à partir du début. En outre, la
657) personne devrait avoir l'expérience de la compilation sous un environnement
658) Windows puisqu'il s'agit de l'audience finale dont nous voulons nous assurer que nous ne les laissons
659) pas à la traine. Ça devrait nécessiter un travail proche du code source de Tor mais
660) probablement uniquement sous l'aspect compilation, pas de rédaction de code.<br />
661) De plus, nous avons besoin d'automatiser nos tests de performance pour toutes les plateformes.
662) Nous avons buildbot (excepté sous Windows &mdash; comme dit au dessus) pour automatiser
663) notre intégration régulièrement et tester la compilation déjà,
664) mais nous avons besoin d'avoir notre test de simulation de réseau (comme dans torflow)
665) mis à jour pour des versions plus récentes de Tor, et faites pour lancer un test
666) de réseau à la fois sur une seule machine, et sur plusieurs, afin que nous puissions tester

667) les changements de performance sur des machines de roles différents automatiquement.<br />

668) </li>

669) -->
670) 

671) <li>

672) <b>Amélioration de nos tests unitaires</b>
673) <br />

674) Priorité: <i>moyen</i>

675) <br />

676) Niveau d'effort : <i>moyen</i>

677) <br />

678) Niveau de difficulté : <i>moyen</i>

679) <br />
680) Mentors supposés : <i>Nick</i>

681) <br />
682) Tor doit être bien plus testé.  C'est un effort multi-partie.  Pour commencer,
683) Notre unité de couverture de test devrait augmenter substantiellement, spécialement dans
684) les zones en dehors des fonctions utilitaires. Ceci devra conduire à une refonte
685) significative des certaines parties de Tor, dans le but de dissocier autant de logique

686) que possible de la globalité.
687) <br />

688) De plus, nous avons besoin d'automatiser nos tests de performance pour toutes les plateformes.
689) Nous avons buildbot (excepté sous Windows — comme dit au dessus) pour automatiser
690) notre intégration régulièrement et tester la compilation déjà,
691) mais nous avons besoin d'avoir notre test de simulation de réseau (comme dans torflow)
692) mis à jour pour des versions plus récentes de Tor, et faites pour lancer un test
693) de réseau à la fois sur une seule machine, et sur plusieurs, afin que nous puissions tester
694) les changements de performance sur des machins de roles différents automatiquement.<br />
695) </li>

696) 

697) <li>

698) <b>Aider à ranimer une implémentation indépendante de Tor</b>
699) <br />

700) Priorité: <i>moyen</i>

701) <br />

702) Niveau d'effort : <i>élevé</i>

703) <br />

704) Niveau de difficulté : <i>moyen à élevé</i>

705) <br />
706) Mentors supposés : <i>Karsten, Nick</i>
707) <br />
708) Applications as of 1 Apr 00::00 UTC: <i>4</i>

709) <br />
710) Réanimer l'une des approches d'implématation d'un client Tor en Java,
711) p.e. le <a href="http://onioncoffee.sourceforge.net/">Projet
712) OnionCoffee</a>, et le faire tourner sur <a
713) href="http://code.google.com/android/">Android</a>. La première étape
714) pourrait être de porter le code existant et l'exécuter dans un environnement
715) Android. Ensuite, le code pourrait être mis à jour pour supporter les nouvelles
716) version de protocole comme la <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
717) des protocole d'annuaire</a>. Ensuite, le support pour les requêtes ou même
718) apporter des services cachés serait sympa, mais non requis. L'étudiant
719) devrait être capable de comprendre et écrire du code Java, comprenant
720) une API de cryptographie Java. Capable de lire du code C serait utile,
721) également. L'étudiant devrait être prêt à lire la documentation existante,
722) implémenter du code de celle ci, et, si nécessaire, refaire la documentation
723) si des éléments ne sont pas documentés. Ce projet est principalement du codage et
724) à un degré moindre, de la conception.
725) </li>

726) 

727) <li>

728) <b>Automatic system tests and automatically starting private Tor networks</b>
729) <br />

730) Priorité: <i>moyen</i>

731) <br />

732) Niveau d'effort : <i>moyen</i>

733) <br />

734) Niveau de difficulté : <i>moyen</i>

735) <br />
736) Mentors supposés : <i>Karsten, Nick, Roger</i>
737) <br />

738) Demandes au premier Avril 00:00 UTC: <i>2</i>

739) <br />
740) Écrire un outil qui lance un système de tests automatique en plus

741) des test unitaires existants. Le simulateur Tor en Java <a
742) href="https://svn.torproject.org/svn/puppetor/trunk/">PuppeTor</a>

743) devrait être un bon départ pour commencer un réseau privé Tor, l'utiliser 

744) quelque temps, et vérifier qu'au moins quelques parties fonctionnent. Ce

745) projet nécessite de concevoir un plan pour effectuer les tests système
746) du réseau privé Tor, avant de commencer à coder. Les tests typiques
747) vont de la simple requête dans le réseau privé à la

748) manipulation des messages échangés et voir si les nœuds peuvent 
749) correctement prendre en compte les messages corrompus.
750) <br />
751) L'étudiant devrait pouvoir obtenir une bonne comprehension de comment Tor 
752) fonctionne et quels problèmes ou bugs peuvent survenir pour concevoir de bons

753) bancs de tests. Comprendre le code Tor et la documentation existante est
754) vital. Si PuppeTor est utilisé, l'étudiant devrait aussi être en mesure de comprendre
755) et éventuellement étendre une application Java existante. Ce projet est en partie
756) de la conception et en partie du codage.
757) </li>

758) 

759) <li>
760) <b>Donner vie à moniTor</b>
761) <br />

762) Priorité: <i>moyen</i>

763) <br />

764) Niveau d'effort : <i>moyen</i>

765) <br />

766) Niveau de difficulté : <i>faible à moyen</i>

767) <br />
768) Mentors supposés : <i>Karsten, Jacob</i>
769) <br />
770) Applications as of 1 Apr 00::00 UTC: <i>2</i>
771) <br />

772) Implémenter un outil <a href="http://www.ss64.com/bash/top.html">comme top</a>
773) d'administration pour les relais Tor. Le but de cet outil serait de
774) superviser un relais Tor local via son port de control et inclure des informations
775) système utiles de la machine. Lorsque l'outil tourne, il 

776) devrait dynamiquement se mettre à jour comme top le fait pour les processus Linux.

777) <a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">Ce

778) post sur or-dev</a> devrait être une bonne première base.
779) <br />
780) L'étudiant devra être familier ou prêt à apprendre l'administration 
781) d'un relais Tor et sa configuration à travers son port de contrôle.
782) Du fait qu'un prototype existe en Python quelques connaissances en Python
783)  serait intéressantes. Ce projet porte sur l'identification des nécessités 
784) 	pour un tel outil et sur la conception d'une interface ;

785) et d'un autre coté nécessite beaucoup de codage.
786) </li>

787) 

788) <li>

789) <b>Torbutton improvements</b>

790) <br />

791) Priorité: <i>moyen</i>

792) <br />

793) Niveau d'effort : <i>élevé</i>

794) <br />

795) Niveau de difficulté : <i>élevé</i>

796) <br />

797) Mentors supposés : <i>Mike</i>
798) <br/>
799) Torbutton has a number of improvements that can be made in the post-1.2
800) timeframe. Most of these are documented as feature requests in the <a
801) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5">Torbutton
802) flyspray section</a>. Good examples include: stripping off node.exit on http
803) headers, more fine-grained control over formfill blocking, improved referrer
804) spoofing based on the domain of the site (a-la <a
805) href="https://addons.mozilla.org/en-US/firefox/addon/953">refcontrol extension</a>),
806) tighter integration with Vidalia for reporting Tor status, a New Identity
807) button with Tor integration and multiple identity management, and anything
808) else you might think of.
809) <br />
810) This work would be independent coding in Javascript and the fun world of <a
811) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
812) with not too much involvement in the Tor internals.
813) </li>
814) 
815) <li>
816) <b>Porting Polipo to Windows</b>
817) <br />

818) Priorité: <i>moyen</i>

819) <br />

820) Niveau d'effort : <i>moyen</i>

821) <br />

822) Niveau de difficulté : <i>moyen à élevé</i>

823) <br />
824) Mentors supposés : <i>Andrew, Steven, Roger</i>
825) <br />
826) Help port <a
827) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
828) Windows. Example topics to tackle include:
829) 1) handle spaces in path names and understand the filesystem
830) namespace &mdash; that is, where application data, personal data,
831) and program data typically reside in various versions of Windows. 2) the
832) ability to handle ipv6 communications. 3) the ability to asynchronously
833) query name servers, find the system nameservers, and manage netbios
834) and dns queries. 4) use native regex capabilities of Windows, rather
835) than using 3rd party GNU regex libraries. 5) manage events and buffers
836) natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
837) Windows it's whatever the config specifies). 6) some sort of GUI config
838) and reporting tool, bonus if it has a systray icon with right clickable
839) menu options. Double bonus if it's cross-platform compatible.
840) </li>
841) 
842) <li>
843) <b>Make our diagrams beautiful and automated</b>
844) <br />

845) Priorité: <i>moyen</i>

846) <br />

847) Niveau d'effort : <i>faible</i>

848) <br />

849) Niveau de difficulté : <i>faible</i>

850) <br />
851) Mentors supposés : <i>Andrew</i>
852) <br />
853) We need a way to generate the website diagrams (for example, the "How
854) Tor Works" pictures on the <a href="<page overview>">overview page</a>
855) from source, so we can translate them as UTF-8 text rather than edit
856) them by hand with Gimp. We might want to
857) integrate this as an wml file so translations are easy and images are
858) generated in multiple languages whenever we build the website. See the
859) "Translation Wiki" idea above.
860) </li>
861) 
862) <li>
863) <b>Improve the LiveCD offerings for the Tor community</b>
864) <br />

865) Priorité: <i>faible</i>

866) <br />

867) Niveau d'effort : <i>faible</i>

868) <br />

869) Niveau de difficulté : <i>moyen à élevé</i>

870) <br />
871) Mentors supposés : <i>Anonym, Jacob, Roger</i>
872) <br />
873) How can we make the <a
874) href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
875) easier to maintain, improve, and document?
876) </li>
877) 
878) <li>
879) <b>Rework and extend Blossom</b>
880) <br />

881) Priorité: <i>moyen</i>

882) <br />

883) Niveau d'effort : <i>moyen à élevé</i>

884) <br />

885) Niveau de difficulté : <i>moyen à élevé</i>

886) <br />
887) Mentors supposés : <i>Goodell</i>
888) <br />
889) Rework and extend Blossom (a tool for monitoring and
890) selecting appropriate Tor circuits based upon exit node requirements
891) specified by the user) to gather data in a self-contained way, with
892) parameters easily configurable by the user.  Blossom is presently
893) implemented as a single Python script that interfaces with Tor using the
894) Controller interface and depends upon metadata about Tor nodes obtained
895) via external processes, such as a webpage indicating status of the nodes
896) plus publically available data from DNS, whois, etc.  This project has
897) two parts: (1) Determine which additional metadata may be useful and
898) rework Blossom so that it cleanly obtains the metadata on its own rather
899) than depend upon external scripts (this may, for example, involve
900) additional threads or inter-process communication), and (2) develop a
901) means by which the user can easily configure Blossom, starting with a
902) configuration file and possibly working up to a web configuration engine.
903) Knowledge of Tor and Python are important; knowledge of
904) TCP, interprocess communication, and Perl will also be helpful.  An
905) interest in network neutrality is important as well, since the
906) principles of evaluating and understanding internet inconsistency are at
907) the core of the Blossom effort.
908) </li>
909) 
910) <li>
911) <b>Improve Blossom: Allow users to qualitatively describe exit nodes they desire</b>
912) <br />

913) Priorité: <i>faible</i>

914) <br />

915) Niveau d'effort : <i>moyen</i>

916) <br />

917) Niveau de difficulté : <i>moyen</i>

918) <br />
919) Mentors supposés : <i>Goodell</i>
920) <br />
921) Develop and implement a means of affording Blossom
922) users the ability to qualitatively describe the exit node that they
923) want.  The Internet is an inconsistent place: some Tor exit nodes see
924) the world differently than others.  As presently implemented, Blossom (a
925) tool for monitoring and selecting appropriate Tor circuits based upon
926) exit node requirements specified by the user) lacks a sufficiently rich
927) language to describe how the different vantage points are different.
928) For example, some exit nodes may have an upstream network that filters
929) certain kinds of traffic or certain websites.  Other exit nodes may
930) provide access to special content as a result of their location, perhaps
931) as a result of discrimination on the part of the content providers
932) themselves.  This project has two parts: (1) develop a language for
933) describing characteristics of networks in which exit nodes reside, and
934) (2) incorporate this language into Blossom so that users can select Tor
935) paths based upon the description.
936) Knowledge of Tor and Python are important; knowledge of
937) TCP, interprocess communication, and Perl will also be helpful.  An
938) interest in network neutrality is important as well, since the
939) principles of evaluating and understanding internet inconsistency are at
940) the core of the Blossom effort.
941) </li>
942) 
943) <li>
944) <b>Proposer de nouvelles idées !</b>
945) <br />
946) Don't like any of these? Look at the <a
947) href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development
948) roadmap</a> for more ideas.
949) </li>
950) 
951) </ol>
952) 

953) <h2><a class="anchor" href="#Coding">Conception et Code</a></h2>
954) <ol>

955) <li>Les serveurs de Tor ne fonctionnent pas parfaitement sur Windows XP. Sur
956) Windows, Tor utilise l'appel système standard <tt>select()</tt>, 
957) qui utilise l'espace non paginé dans le pool. Ce qui implique 
958) que les serveurs de taille moyenne vont vider l'espace non paginé, <a

959) href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">provocant 

960) l'instabilité et le plantage du système</a>. Nous devrions probablement utiliser des E/S recouvrables à la place. Une solution pourrait-être d'apprendre à la <a

961) href="http://www.monkey.org/~provos/libevent/">libevent</a> comment utiliser 
962) les E/S recouvrables à la place de select() sous Windows, et alors d'adapter Tor à 

963) la nouvelle interface libevent. Christian King à 

964) <a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">bien

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

966) <li>Nous avons besoin maintenant de commencer l'élaboration de notre <a href="<page
967) documentation>#DesignDoc">conception de résistance au blocage</a>. Ceci implique 
968) une refonte de la conception, une modification de différents aspects de Tor, une adaptation de
969) <a href="http://vidalia-project.net/">Vidalia</a> pour qu'il supporte les nouvelles
970) fonctionnalités, et planifier le deploiement.</li>
971) <li>Nous avons besoin d'un ensemble d'outils flexibles de simulation pour étudier de bout en bout
972) les trafics de confirmation d'attaque. Beaucoups de chercheurs ont conçu des simulateurs ad hoc
973) pour confirmer leurs intuitions comme quoi soit l'attaque marche 
974) vraiment bien ou que les défenses fonctionnent. Pouvons nous construire un simulateur
975) qui soit clairement documenté et suffisament ouvert pour que tout le monde sache qu'il

976) donne une réponse raisonnable ? Ceci stimulera un grand nombre de nouvelles recherches.

977) Voyez l'entrée <a href="#Research">suivante</a> sur les confirmations d'attaque pour les 
978) détails sur le coté recherche de cette tâche &mdash; qui sait, quand ceci sera 

979) fait peut-être pourrez aider en écrivant un rapport ou deux.</li>

980) <li>Tor 0.1.1.x inclut le support d'accélérateurs matériels de chiffrage 

981) via OpenSSL. Cependant, personne ne l'a jamais testé. Est-ce que quelqu'un voudrait se procurer 

982) une carte et nous dire ce qu'il en est ?</li>

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

984) href="http://en.wikipedia.org/wiki/Fuzz_testing">du "fuzz"</a>. Déterminer 

985) s'il existe déjà de bonnes bibliothèques de fuzz pour ce que nous voulons faire. La célébrité pour celui grâce à qui une nouvelle version pourra voir le jour !</li>

986) <li>Tor utilise TCP pour le transport et TLS pour le chiffrage 
987) des liens. C'est simple et efficace, mais cela implique que toutes les unités (cellules) 
988) d'un lien sont mises en attente lorsqu'un seul paquet est perdu, et 
989) cela signifie que seuls des flux TCP peuvent être raisonnablement supportés. Nous avons dressé une <a

990) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP"> liste 

991) de raisons pour lesquelles nous n'avons pas bifurqué vers le transport par UDP</a>, mais ce serait 
992) bien de voir cette liste se raccourcir. Nous avons aussi proposé <a 
993) href="<svnsandbox>tor/doc/100-tor-spec-udp.txt">une spécification pour Tor et 
994) UDP</a> &mdash; lisez-la et faites-nous part de vos remarques et critiques, s'il-vous-plaît.</li>
995) <li>Nous ne sommes plus très loin d'avoir le support pour IPV6 entre les serveurs de sorties 
996) et les adresses finales. Si IPV6 vous tient à cœur, partir de là est sans doute 
997) un premier pas.</li>

998) </ol>
999) 
1000) <a id="Research"></a>
1001) <h2><a class="anchor" href="#Research">Recherche</a></h2>
1002) <ol>

1003) <li>"L'attaque par empreinte de sites": faire une liste de quelques 
1004) centaines de sites populaires, en télécharger les pages, et faire des 
1005) "signatures" pour chaque site. Ensuite, observer le trafic d'un client Tor. 
1006) L'analyse de ses réceptions de données donne rapidement une idée 
1007) des sites qu'il visite. Premièrement, quelle est l'efficacité 

1008) de cette attaque sur le code actuellement utilisé dans Tor ? Ensuite, tester 

1009) les défenses possibles : par exemple, changer la taille des cellules de Tor de 512 
1010) octets à 1024, utiliser des techniques de remplissage comme <a
1011) href="http://freehaven.net/anonbib/#timing-fc2004">le lâcher défensif</a>, 
1012) ou ajouter des délais de trafic. Quel impact ces stratégies de défense ont-elles, 
1013) et, dans les cas où elles sont efficaces en défense, quel impact ont-elles 

1014) en terme de perte d'utilisabilité de Tor (à quantifier) ?</li>

1015) <li>"L'attaque par corrélation des trafics aux extrémités": 
1016) par l'observation des trafics de Alice et Bob, il est possible de <a
1017) href="http://freehaven.net/anonbib/#danezis:pet2004">comparer 
1018) les signatures des trafics et d'en déduire qu'il s'agit du même 
1019) flux</a>. Jusqu'ici, Tor considère ce type d'attaque comme intrinsèque 

1020) et donc inévitable. Tout d'abord, est-ce réellement vrai ? Quelle 

1021) quantité de trafic - et avec quelle distribution - est-elle nécessaire pour que l'adversaire 

1022) soit certain d'avoir gagné ? Est-ce qu'il existe des scénarios (par exemple avoir un trafic faible) 
1023) pour ralentir cette attaque ? Est-ce que certains types de remplissage ou de modelage de trafic
1024) fonctionnent mieux que d'autres ?</li>

1025) <li>A related question is: Does running a relay/bridge provide additional
1026) protection against these timing attacks? Can an external adversary that can't
1027) see inside TLS links still recognize individual streams reliably?
1028) Does the amount of traffic carried degrade this ability any? What if the
1029) client-relay deliberately delayed upstream relayed traffic to create a queue
1030) that could be used to mimic timings of client downstream traffic to make it
1031) look like it was also relayed? This same queue could also be used for masking
1032) timings in client upstream traffic with the techniques from <a
1033) href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptive padding</a>,
1034) but without the need for additional traffic. Would such an interleaving of
1035) client upstream traffic obscure timings for external adversaries? Would the
1036) strategies need to be adjusted for asymmetric links? For example, on
1037) asymmetric links, is it actually possible to differentiate client traffic from
1038) natural bursts due to their asymmetric capacity? Or is it easier than
1039) symmetric links for some other reason?</li>
1040) <li>Repeat Murdoch and Danezis's <a
1041) href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">attack from
1042) Oakland 05</a> on the current Tor network. See if you can learn why it
1043) works well on some nodes and not well on others. (My theory is that the
1044) fast nodes with spare capacity resist the attack better.) If that's true,
1045) then experiment with the RelayBandwidthRate and RelayBandwidthBurst
1046) options to run a relay that is used as a client while relaying the
1047) attacker's traffic: as we crank down the RelayBandwidthRate, does the
1048) attack get harder? What's the right ratio of RelayBandwidthRate to
1049) actually capacity? Or is it a ratio at all? While we're at it, does a
1050) much larger set of candidate relays increase the false positive rate
1051) or other complexity for the attack? (The Tor network is now almost two
1052) orders of magnitude larger than it was when they wrote their paper.) Be
1053) sure to read <a href="http://freehaven.net/anonbib/#clog-the-queue">Don't
1054) Clog the Queue</a> too.</li>

1055) <li>"L'attaque par zones de routage" : la littérature spécialisée considère 

1056) le plus souvent que le chemin réseau entre Alice et son noeud d'entrée 
1057) (et entre le noeud de sortie et Bob) comme un lien unique dans un graphe. 
1058) En pratique, cependant, le chemin passe par de nombreux systèmes autonomes
1059)  (Autonomous Systems : ASes), et <a

1060) href="http://freehaven.net/anonbib/#feamster:wpes2004">il n'est pas inhabituel 
1061) de retrouver le même AS sur les chemins d'entrée et de sortie</a>.
1062) Malheureusement, pour prévoir précisément si le chemin "Alice, entrée, 
1063) sortie, Bob" sera dangereux, nous devrions télécharger une zone de routage 
1064) internet complète et faire dessus des calculs lourds. Est-ce qu'il existe 

1065) des approximations utilisables, comme par exemple d'ignorer les adresses IP d'un réseau /8 ?</li>

1066) <li>D'autres questions de recherche concernant la diversité géographique considèrent 
1067) la différence entre choisir un circuit efficace et en choisir un aléatoire.
1068) Lisez l' <a
1069) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">argumentation

1070) </a> de Stephen Rollyson sur comment éviter les nœuds lents sans trop impacter

1071) l'anonymat. Cet axe de raisonnement nécessite davantage de travail et de 
1072) réflexion, mais semble très prometteur.</li>
1073) <li>Tor ne fonctionne pas très bien lorsque les serveurs ont des bandes passantes 
1074) asymétriques (par exemple câble ou DSL). Comme Tor a des connexions TCP séparées entre 
1075) chaque saut, si les octets arrivent correctement mais que les octets sortants 
1076) sont bloqués sur place, les mécanismes de refoulement de TCP 
1077) ne retransmettent pas vraiment cette information aux flux entrants.
1078) Peut-être Tor devrait-il détecter s'il perd beaucoup de paquets sortants, 

1079) et limiter la vitesse du flux entrant pour réguler cela lui-même ? Je peux concevoir 

1080) un schéma de type augmentation-descente dans lequel on choisit un débit "sûr", 
1081) que l'on augmente jusqu'à perdre des paquets, puis qui redescend, puis qui réaugmente. Nous 

1082) avons besoin de quelq'un de fort en réseau pour simuler ce fonctionnement et aider à concevoir 

1083) des solutions. De manière générale, l'évaluation des pertes de performances 
1084) d'un tel système pourrait peut-être - dans le cas où elles sont grandes - 

1085) servir de motivation pour reconsidérer la question du transport UDP.</li>

1086) <li>Un sujet lié est le contrôle de congestion : notre système 

1087) actuel est-il suffisant pour un usage intensif ? Peut-être 

1088) devrions-nous expérimenter des fenêtres de taille variable 

1089) plutôt qu'à taille fixe ? C'est apparu assez efficace pour cette <a

1090) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">expérience 
1091) sur ssh</a>. Nous aurons à faire des mesures et des réglages, et peut-être 
1092) une révision de Tor si les résulats sont bons.</li>

1093) <li>Our censorship-resistance goals include preventing
1094) an attacker who's looking at Tor traffic on the wire from <a
1095) href="https://www.torproject.org/svn/trunk/doc/design-paper/blocking.html#sec:network-fingerprint">distinguishing
1096) it from normal SSL traffic</a>. Obviously we can't achieve perfect
1097) steganography and still remain usable, but for a first step we'd like to
1098) block any attacks that can win by observing only a few packets. One of
1099) the remaining attacks we haven't examined much is that Tor cells are 512
1100) bytes, so the traffic on the wire may well be a multiple of 512 bytes.
1101) How much does the batching and overhead in TLS records blur this on the
1102) wire? Do different buffer flushing strategies in Tor affect this? Could
1103) a bit of padding help a lot, or is this an attack we must accept?</li>
1104) <li>Tor circuits are built one hop at a time, so in theory we have the
1105) ability to make some streams exit from the second hop, some from the
1106) third, and so on. This seems nice because it breaks up the set of exiting
1107) streams that a given relay can see. But if we want each stream to be safe,
1108) the "shortest" path should be at least 3 hops long by our current logic, so
1109) the rest will be even longer. We need to examine this performance / security
1110) tradeoff.</li>
1111) <li>It's not that hard to DoS Tor relays or directory authorities. Are client
1112) puzzles the right answer? What other practical approaches are there? Bonus
1113) if they're backward-compatible with the current Tor protocol.</li>
1114) <li>Programs like <a
1115) href="https://torbutton.torproject.org/dev/">Torbutton</a> aim to hide
1116) your browser's UserAgent string by replacing it with a uniform answer for
1117) every Tor user. That way the attacker can't splinter Tor's anonymity set
1118) by looking at that header. It tries to pick a string that is commonly used
1119) by non-Tor users too, so it doesn't stand out. Question one: how badly
1120) do we hurt ourselves by periodically updating the version of Firefox
1121) that Torbutton claims to be? If we update it too often, we splinter the
1122) anonymity sets ourselves. If we don't update it often enough, then all the
1123) Tor users stand out because they claim to be running a quite old version
1124) of Firefox. The answer here probably depends on the Firefox versions seen
1125) in the wild. Question two: periodically people ask us to cycle through N
1126) UserAgent strings rather than stick with one. Does this approach help,
1127) hurt, or not matter? Consider: cookies and recognizing Torbutton users
1128) by their rotating UserAgents; malicious websites who only attack certain
1129) browsers; and whether the answers to question one impact this answer.
1130) </li>
1131) <li>Right now Tor clients are willing to reuse a given circuit for ten
1132) minutes after it's first used. The goal is to avoid loading down the
1133) network with too many circuit extend operations, yet to also avoid having
1134) clients use the same circuit for so long that the exit node can build a
1135) useful pseudonymous profile of them. Alas, ten minutes is probably way
1136) too long, especially if connections from multiple protocols (e.g. IM and
1137) web browsing) are put on the same circuit. If we keep fixed the overall
1138) number of circuit extends that the network needs to do, are there more
1139) efficient and/or safer ways for clients to allocate streams to circuits,
1140) or for clients to build preemptive circuits? Perhaps this research item
1141) needs to start with gathering some traces of what connections typical
1142) clients try to launch, so you have something realistic to try to optimize.
1143) </li>
1144) <li>How many bridge relays do you need to know to maintain
1145) reachability? We should measure the churn in our bridges. If there is
1146) lots of churn, are there ways to keep bridge users more likely to stay
1147) connected?
1148) </li>

1149) </ol>
1150) 

1151) <p>

1152) <a href="<page contact>">Contactez-nous</a> si vous avez avancé sur 

1153) ces points !

1154) </p>

1155) 
1156)   </div><!-- #main -->
1157) 

1158) #include <foot.wmi>