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>Tor Browser Bundle for Mac OS X</b> <br /> Priority: <i>High</i> <br />
93) Effort Level: <i>High</i> <br /> Skill Level: <i>Medium</i> <br /> Likely
94) Mentors: <i>Steven, Erinn, Jacob, Andrew</i> <br /> The Tor Browser Bundle
95) incorporates Tor, Firefox, Polipo, and the Vidalia user interface (and
96) optionally the <a href="http://pidgin.im/">Pidgin</a> Instant Messaging
97) client). Components are pre-configured to operate in a secure way, and it
98) has very few dependencies on the installed operating system. It has
99) therefore become one of the most easy to use, and popular, ways to use Tor
100) on Windows.  <br /> However, there is currently no released package for Mac
101) OS X, so this project would be to implement Tor Browser Bundle for OS
102) X. This will involve modifications to Vidalia (C++), possibly Firefox (C)
103) then creating and testing the launcher on a range of operating system
104) versions and configurations to verify portability.  Some work on this was
105) completed as part of the Google Summer of Code 2009. Another part of this
106) project is to identify all of the traces left behind by using a Tor Browser
107) Bundle on Mac OS X or Linux.  Developing ways to stop, counter, or remove
108) these traces is a final step.  <br /> Students should be familiar with
109) application development on one or preferably both of Linux and Mac OS X, and
110) be comfortable with C/C++ and shell scripting.  <br /> Part of this project
111) could be usability testing of Tor Browser Bundle, ideally amongst our target
112) demographic.  That would help a lot in knowing what needs to be done in
113) terms of bug fixes or new features. We get this informally at the moment,
114) but a more structured process would be better.  <br /> A beta version of the
115) Tor Browser Bundle has been released for GNU/Linux, but work is still
116) required for the Tor IM Browser bundle. Work is currently being done on the
117) Mac OS X version as well. If you would like to help extend or do security
118) auditing for either (or both) of these, please contact Erinn.

119) </li>
120) 
121) <li>

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

144) </li>
145) 

146) <li>

147) <b>Rewrite TorDNSEL, this time with a spec!</b> <br /> Priority: <i>High</i>
148) <br /> Effort Level: <i>Medium</i> <br /> Skill Level: <i>Medium</i> <br />
149) Likely Mentors: <i>Mike, Roger, Sebastian, Damian</i> <br /> The <a
150) href="<page tordnsel/index>">Tor DNS Exit List</a> is an unmaintained
151) Haskell program that serves three purposes. First, it provides an rbl-style
152) DNS interface for people to look up whether a given IP address is (or has
153) recently been) a Tor exit relay. Second, it actively builds circuits over
154) the Tor network and connects back to itself, to learn the actual exit IP
155) address of each relay &mdash; some Tor relays exit from a different address
156) than they advertise in their descriptor. Third, it exports a <a
157) href="http://exitlist.torproject.org/exitAddresses">set of conclusions</a>
158) so that <a href="https://check.torproject.org/">check.torproject.org</a> can
159) guess for you whether your browser is configured to point to Tor.  <br />
160) This project would make use of <a
161) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>, a
162) set of Python scripts to interact with Tor, to figure out how our Tor Exit
163) Checker should actually work, and then build it &mdash; probably in Python
164) since Torflow is in Python. The main goal is to reduce false positives as
165) much as possible, by making sure that it learns about new relays as soon as
166) possible, making sure that the testing phase concludes quickly, and making
167) sure the answers get passed to the Check script quickly. As a bonus, we
168) should standardize (specify) the format of the exitAddresses file, and
169) rewrite the <a

170) href="https://svn.torproject.org/svn/check/trunk/cgi-bin/TorBulkExitList.py">Tor

171) Bulk Exit List</a> script to use that file rather than its current <a
172) href="https://bugs.torproject.org/flyspray/index.php?do=details&id=1019">horrible
173) DNS hacks</a>. As an extra bonus, we should work with Freenode, OFTC, and/or
174) other IRC networks to make sure that the scripts we offer are actually the
175) scripts they want, in terms of accurately identifying which of their users
176) are coming from the Tor network.  <br /> You can fetch the <a
177) href="git://git.torproject.org/git/tordnsel">latest tordnsel</a> via git.

178) </li>
179) 

180) <li>

181) <b>Improving Tor's ability to resist censorship</b> <br /> Priority:
182) <i>Medium to High</i> <br /> Effort Level: <i>Medium to High</i> <br />
183) Skill Level: <i>High</i> <br /> Likely Mentors: <i>Roger, Nick, Steven</i>
184) <br /> The Tor 0.2.1.x series makes <a
185) href="<svnprojects>design-paper/blocking.html">significant improvements</a>
186) in resisting national and organizational censorship.  But Tor still needs
187) better mechanisms for some parts of its anti-censorship design.  <br /> One
188) huge category of work is adding features to our <a
189) href="http://gitweb.torproject.org//bridgedb.git?a=tree">bridgedb</a>
190) service (Python). Tor aims to give out <a href="<page bridges>">bridge relay
191) addresses</a> to users that can't reach the Tor network directly, but
192) there's an arms race between algorithms for distributing addresses and
193) algorithms for gathering and blocking them. See <a
194) href="https://blog.torproject.org/blog/bridge-distribution-strategies">our
195) blog post on the topic</a> as an overview, and then look at <a
196) href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html">Roger's or-dev
197) post</a> from December for more recent thoughts &mdash; lots of design work
198) remains.  <br /> If you want to get more into the guts of Tor itself (C), a
199) more minor problem we should address is that current Tors can only listen on
200) a single address/port combination at a time. There's <a
201) href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">a proposal to
202) address this limitation</a> and allow clients to connect to any given Tor on
203) multiple addresses and ports, but it needs more work.  <br /> This project
204) could involve a lot of research and design. One of the big challenges will
205) be identifying and crafting approaches that can still resist an adversary
206) even after the adversary knows the design, and then trading off censorship
207) resistance with usability and robustness.

208) </li>

209) 
210) 

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

243) <li>

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

263) </li>

264) 

265) <li>

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

297) </li>

298) 

299) <li>

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

318) </li>

319) 

320) <li>

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

339) </li>

340) <li>
341) <b>More on Orbot &amp; Android OS-specific development</b> <br/> <br />
342) Priority: <i>Medium</i> <br /> Effort Level: <i>High</i> <br /> Skill Level:
343) <i>Medium to High</i> <br /> Likely Mentors: <i>Nathan</i> <br /> <b>Android
344) Java UI work:</b> Improved home screen to show better statistics about data
345) transferred (up/down), number of circuits connected, quality of connection
346) and so on. The "Tether Wifi" Android application is a good model to follow
347) in how it shows a realtime count of bytes transferred as well as
348) notifications when wifi client connect. In addition, better display/handling
349) of Tor system/error messages would also be very helpful. Finally, the
350) addition of a wizard or tutorial walkthrough for novice users to explain to
351) them exactly what or what is not anonymized or protected would greatly
352) improve the likelihood they will use Orbot correctly.  <br/><br/> <b>Android
353) Java OS/Core app work:</b> Better system-wide indicator either via the
354) notification bar, "Toast" pop-up dialogs or some other indicator that an
355) application's traffic is indeed moving through Orbot/Tor. For instance,
356) right now you need to first go to a torcheck web service to ensure your
357) browser is routing via Tor. Orbot should be able to notify you that circuits
358) are being opened, used, etc. The aforementioned data transfer tracker might
359) provide this type of awareness as well.  <br/><br/> <b>Android Java
360) Library/Community Outreach work:</b> We need to package a simple library for
361) use with third-party application to easily enable them to support
362) "Torification" on non-root devices (aka w/o transparent proxying). This
363) library should include a wrapper for the Apache HTTPClient library, a
364) utility class for detecting the state of Orbot connectivity, and other
365) relevant/useful things an Android app might need to anonymize itself. This
366) work would include the creation of the library, documentation, and sample
367) code. Outreach or effort to implement the library within other open-source
368) apps would follow.  <br/><br/> <b>Android OS/C/Linux work:</b> The port of
369) Tor to Android is basically a straight cross-compile to Linux ARM. There has
370) been no work done in looking the optimization of Tor within a mobile
371) hardware environment, on the ARM processor or other Android hardware, or on
372) mobile networks. It should be noted, that even without optimization, Tor is
373) handling the mobile network environment very well, automatically detecting
374) change in IP addresses, reconnecting circuits, etc across switching from 2G
375) to 3G to Wifi, and so forth. 
376) </li>

377) 
378) 

379) 
380) 

381) 
382) <!--<li>
383) 
384) <b>New Torbutton Features</b>
385) <br />
386) Priority: <i>Medium</i>
387) <br />
388) Effort Level: <i>High</i>
389) <br />
390) Skill Level: <i>High</i>
391) <br />
392) Likely Mentors: <i>Mike</i>
393) <br/>
394) There are several <a
395) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5&amp;type=2">good
396) feature requests</a> on the Torbutton Flyspray section. In particular, <a
397) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=523">Integrating
398) 'New Identity' with Vidalia</a>,
399) <a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=940">ways of
400) managing multiple cookie jars/identities</a>, <a
401) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=637">preserving
402) specific cookies</a> when cookies are cleared,
403) <a
404) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=524">better
405) referrer spoofing</a>, <a
406) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=564">correct
407) Tor status reporting</a>, and <a
408) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=462">"tor://"
409) and "tors://" urls</a> are all interesting
410) features that could be added.
411) <br />
412) This work would be independent coding in Javascript and the fun world of <a
413) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
414) with not too much involvement in the Tor internals.
415) </li>-->

416) <!-- <li>
417) 
418) <b>New Thandy Features</b>
419) <br />
420) Priority: <i>Medium</i>
421) <br />
422) Effort Level: <i>Medium</i>
423) <br />
424) Skill Level: <i>Medium to High</i>
425) <br />
426) Likely Mentors: <i>Martin</i>
427) <br />
428) Additional capabilities are needed for assisted updates of all the Tor
429) related software for Windows and other operating systems. Some of the
430) features to consider include:

431) <ol>

432) <li> Integration of the <a
433) href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto
434) Python library</a>
435) for authenticated HTTPS downloads.</li>
436) <li> Adding a level of indirection
437) between the timestamp signatures and the package files included in an
438) update. See the "Thandy attacks / suggestions" thread on or-dev.</li>
439) <li> Support locale specific installation and configuration of assisted
440) updates based on preference, host, or user account language settings.
441) Familiarity with Windows codepages, unicode, and other character sets
442) is helpful in addition to general win32 and posix API experience and
443) Python proficiency.</li>

444) </ol>

445) </li> -->

446) <li>

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

464) </li>

465) 

466) <li>

467) <b>Une meilleure et plus utile carte du réseau dans Vidalia</b> <br />
468) Priorité: <i>Faible à Moyenne</i> <br /> Effort à fournir: <i>Moyen</i> <br
469) /> Compétences requises: <i>Moyennes</i> <br /> Tuteurs potentiels:
470) <i>Matt</i> <br /> Une des fonctionnalités courantes de Vidalia est la carte
471) du réseau qui montre à l'utilisateur l'emplacement approximatif des relais
472) du réseau Tor et qui trace les chemins empruntés par le trafic qui y est
473) injecté. La carte n'est pas très interactive pour le moment et est de
474) médiocre qualité graphique. A la place, nous avons implémenté le widget KDE
475) Marble pour nous donner une carte de meilleure qualité et nous permettre une
476) meilleure interactivité tel que l'affichage des informations d'un relais ou
477) d'un chemin lorsqu'on clique dessus. Nous voulons ajouter la possibilité
478) pour les utilisateurs de cliquer sur un relais ou un pays contenant un ou
479) plusieurs relais de sortie Tor et dire "Je veux que mes connexions de sortie
480) se fasse à partir d'ici.". <br /> Ce projet implique d'abord d'être
481) familiarisé avec Vidalia et l'API du widget Marble. On pourra ensuite
482) intégrer le widget dans Vidalia et adapter Marble à notre application, comme
483) rendre les circuits cliquables, l'enregistrement du cache des données de la
484) carte dans le répertoire de Vidalia et l'adaptation de certaines des
485) interfaces du widget.  <br /> Une personne intéressée par ce projet devrait
486) disposer d'une bonne expérience de développement en C++. Une expérience avec
487) Qt et Cmake serait un vrai plus.

488) </li>

489) 

490) <li>

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

499) </li>

500) 
501) 

502) 
503) <!--<li>
504) 
505) <b>Intermediate Level Network Device Driver</b>
506) <br />
507) Priority: <i>Low</i>
508) <br />
509) Effort Level: <i>High</i>
510) <br />
511) Skill Level: <i>High</i>
512) <br />
513) Likely Mentors: <i>Martin</i>
514) <br />
515) The WinPCAP device driver used by Tor VM for bridged networking does
516) not support a number of wireless and non-Ethernet network adapters.
517) Implementation of a intermediate level network device driver for win32
518) and 64bit would provide a way to intercept and route traffic over such
519) networks. This project will require knowledge of and experience with
520) Windows kernel device driver development and testing. Familiarity with
521) Winsock and Qemu would also be helpful.
522) </li>-->

523) <li>

524) <b>Improve Tor Weather</b> <br /> Priority: <i>Medium</i> <br /> Effort
525) Level: <i>Medium</i> <br /> Skill Level: <i>Medium</i> <br /> Likely
526) Mentors: <i>Christian, Roger, Damian</i> <br /> <a
527) href="https://weather.torproject.org/">Tor weather</a> is a tool that allows
528) signing up to receive notifications via email when the tracked Tor relay is
529) down. Currently, it isn't really useful for people who use the hibernation
530) feature of Tor, or for those who have to shut down their relay
531) regularly. During the project, Tor weather could be extended to allow more
532) flexible configurations.  Other enhancements are also possible: Weather
533) could send out warnings when your relay runs an out-of-date version of Tor,
534) or when its observed bandwith drops below a certain value. It might also be
535) a nice tool that allows for checking whether your relay has earned you a <a
536) href="<page tshirt>">T-Shirt</a>, or sending reminders to directory
537) authorities that their keys are about to expire. Be creative, and consider
538) how the above project to track overall network status can help you get your
539) job done more quickly! See also its <a
540) href="https://svn.torproject.org/svn/weather/trunk/README">README</a> and <a

541) href="https://svn.torproject.org/svn/weather/trunk/TODO">TODO</a>.

542) </li>
543) 
544) <li>

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

586) </li>
587) 
588) 

589) 
590) <!--<li>
591) 
592) <b>Tor/Polipo/Vidalia Auto-Update Framework</b>
593) <br />
594) We're in need of a good authenticated-update framework.
595) Vidalia already has the ability to notice when the user is running an
596) outdated or unrecommended version of Tor, using signed statements inside
597) the Tor directory information. Currently, Vidalia simply pops
598) up a little message box that lets the user know they should manually
599) upgrade. The goal of this project would be to extend Vidalia with the
600) ability to also fetch and install the updated Tor software for the
601) user. We should do the fetches via Tor when possible, but also fall back
602) to direct fetches in a smart way. Time permitting, we would also like
603) to be able to update other
604) applications included in the bundled installers, such as Polipo and
605) Vidalia itself.
606) <br />
607) To complete this project, the student will first need to first investigate
608) the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
609) their strengths, weaknesses, security properties, and ability to be
610) integrated into Vidalia. If none are found to be suitable, the student
611) will design their own auto-update framework, document the design, and
612) then discuss the design with other developers to assess any security
613) issues. The student will then implement their framework (or integrate
614) an existing one) and test it.
615) <br />
616) A person undertaking this project should have good C++ development
617) experience. Previous experience with Qt is helpful, but not required. One
618) should also have a good understanding of common security
619) practices, such as package signature verification. Good writing ability
620) is also important for this project, since a vital step of the project
621) will be producing a design document to review and discuss
622) with others prior to implementation.
623) </li>-->

624) <li>

625) <b>Améliorer le processus qualité de Tor: Intégration continue de
626) compilation</b> <br /> Priorité: <i>Moyenne</i> <br /> Effort à fournir:
627) <i>Moyen</i> <br /> Compétences requises: <i>Moyennes</i> <br /> Tuteurs
628) potentiels: <i>Erinn</i> <br /> Il serait très utile d'avoir un processus de
629) compilation automatisée pour Windows et pour les autres plateformes. Le but
630) d'avoir un tel environnement est de s'assurer que Windows ne reste pas à la
631) traîne sur aucun des logiciels employés dans le projet Tor. <br />Buildbot
632) semble être un bon choix car il supporte toutes les plateformes
633) surlesquelles Tor fonctionne. Consultez <a
634) href="http://en.wikipedia.org/wiki/BuildBot">l'article Wikipedia sur
635) buildbot</a>.<br /> Il y a sans doute de meilleures options que la personne
636) désirant gérer cette tâche doit évaluer. Toute personne travaillant sur ce
637) processus de compilation automatique doit avoir de l'expérience ou le désir
638) d'apprendre comment compiler l'ensemble du code source en lien avec Tor à
639) partir de rien. De plus, cette personne doit disposer d'une expérience dans
640) la compilation de logiciels sous l'environnement Windows car c'est le coeur
641) de cible à ne pas rater de ce projet. Ce travail impose d'utiliser le code
642) source de Tor mais uniquement du point de vue compilation et non
643) d'écriture.<br /> Ensuite, nous avons besoin d'automatiser nos tests de
644) performance pour toutes les plateformes. Nous disposons là encore de builbot
645) (sauf sur Windows &mdash; comme indiqué ci-dessus) pour automatiser nos
646) intégrations régulières de code et nos tests de compilation mais nous avons
647) besoin de mettre à jour nos tests de simulation réseau pour les versions les
648) plus récente de Tor. Enfin, nous avons besoin de lancer des tests réseau à
649) la fois sur une seule machine et également à travers plusieurs autres de
650) manière à tester automatiquement les changement de performance avec des
651) rôles différents.

652) </li>
653) 
654) 

655) 
656) <!--<li>
657) 
658) <b>Usability testing of Tor</b>
659) <br />
660) Priority: <i>Medium</i>
661) <br />
662) Effort Level: <i>Medium</i>
663) <br />
664) Skill Level: <i>Low to Medium</i>
665) <br />
666) Likely Mentors: <i>Andrew</i>
667) <br />
668) Especially the browser bundle, ideally amongst our target demographic.
669) That would help a lot in knowing what needs to be done in terms of bug
670) fixes or new features. We get this informally at the moment, but a more
671) structured process would be better.
672) </li>-->

673) <li>

674) <b>An authenticating IRC proxy</b> <br /> Priority: <i>Low</i> <br /> Effort
675) Level: <i>Medium to High</i> <br /> Skill Level: <i>Medium to High</i> <br
676) /> Likely Mentors: <i>Sebastian, Weasel, Roger</i> <br /> The world needs an
677) authenticating irc proxy. As we're periodically reminded from the Penny
678) Arcade web comic, "Internet user + anonymity = jerk". With respect to
679) websites we're actually doing ok, since websites can make their users log in
680) and use other application-level authentication approaches. But IRC servers
681) are much worse off, because most IRC server code is poorly written: hard to
682) maintain, and harder to modify. Many IRC networks now block connections from
683) Tor, and we're basically down to two holdouts (OFTC and Freenode). This
684) state of affairs means that a lot of people around the world are thinking "I
685) told you so" about anonymity online, when in fact the problem is simply lack
686) of technology to make the problem manageable. We need some way to let the
687) IRC networks distinguish which users have developed a reputation as not
688) being jerks, so they can treat the two groups separately. There are some
689) really cool research designs like <a
690) href="http://www.cs.dartmouth.edu/~nymble/">Nymble</a>, which aim to let
691) websites blacklist users without needing to learn who they are.  But Nymble
692) is designed around web interactions. We need to build the glue around the
693) IRC protocol that would let us plug in a project like Nymble (or a simpler
694) one to start, as a proof-of-concept). One way to do that would be to build
695) an IRC proxy that knows how to hear from IRC clients, knows how to talk to
696) IRC servers, and has an additional layer that requires the users to
697) authenticate.  Some work on this has begun by other volunteers, see their
698) progress at <a
699) href="http://github.com/anonirc/orc">http://github.com/anonirc/orc</a>.

700) </li>
701) 
702) <li>

703) <b>Faire fonctionner torsocks/dsocks sur OS X</b> <br /> Priorité:
704) <i>Moyenne</i> <br /> Effort à fournir: <i>Moyen</i> <br /> Compétences
705) requises: <i>Moyennes</i> <br /> Tuteurs potentiels: <i>?</i> <br /> <a
706) href="http://code.google.com/p/torsocks/">Torsocks</a> et <a
707) href="http://code.google.com/p/dsocks/">dsocks</a> sont des wrappers qui
708) fonctionnent avec des applications, en interceptent leurs connexions réseau
709) sortantes et les injectent dans Tor. L'objectif est de gérer les
710) applications qui ne supportent pas les proxy (ou qui ne les supportent pas
711) correctement). Ces wrappers doivent intercepter de nombreux appels
712) systèmes. Ces appels systèmes sous Linux sont complètement différents de
713) ceux de BSD. Ainsi, torsocks fonctionne bien sous Linux, dsocks fonctionne
714) bien sous BSD (bien qu'il soit moins bien maintenu et qu'il puisse rater
715) davantage d'appels systèmes) mais rien ne fonctionne bien sur les deux
716) systèmes. D'abord, il faut patcher dsocks pour qu'il utilise les commandes
717) de <i>mapadress</i> depuis l'interface de contrôle de manière à ne pas
718) perdre trop de temps pendant la résolution qui s'effectue dans Tor avant la
719) connexion. Ensuite, notre script <i>torify</i> doit détecter si tsocks ou
720) dsocks est installé et appelé celui qui est légitime. Cela implique
721) d'unifier l'interface de ces deux wrappers et peut-être de partager du code
722) entre eux ou bien d'en laisser tomber un des deux.

723) </li>
724) 
725) <li>

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

733) </li>
734) 
735) </ol>
736) 

737) <a id="OtherCoding"></a>
738) <h2><a class="anchor" href="#OtherCoding">Autres idées de spécifications et de
739) code</a></h2>

740) <ol>

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

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

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

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

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

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

779) href="http://en.wikipedia.org/wiki/Fuzz_testing">du "fuzz"</a>. Déterminer
780) s'il existe déjà de bonnes bibliothèques de fuzz pour ce que nous voulons
781) faire. La célébrité pour celui grâce à qui une nouvelle version pourra voir
782) le jour !</li>
783) 
784) <li>Tor utilise TCP pour le transport et TLS pour le chiffrage des liens. C'est
785) simple et efficace, mais cela implique que toutes les unités (cellules) d'un
786) lien sont mises en attente lorsqu'un seul paquet est perdu, et cela signifie
787) que seuls des flux TCP peuvent être raisonnablement supportés. Nous avons
788) dressé une <a
789) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">
790) liste de raisons pour lesquelles nous n'avons pas bifurqué vers le transport
791) par UDP</a>, mais ce serait bien de voir cette liste se raccourcir. Nous
792) avons aussi proposé <a href="<gitblob>tor/doc/100-tor-spec-udp.txt">une
793) spécification pour Tor et UDP</a> &mdash; lisez-la et faites-nous part de
794) vos remarques et critiques, s'il-vous-plaît.</li>
795) 
796) <li>Nous ne sommes plus très loin d'avoir le support pour IPV6 entre les
797) serveurs de sorties et les adresses finales. Si IPV6 vous tient à cœur,
798) partir de là est sans doute un premier pas.</li>
799) 
800) <li>Nous avons besoin de générer les diagrammes du site web (par exemple les
801) images de "Comment fonctionne Tor ?" sur <a href="<page overview>">la page
802) d'aperçu</a> à partir d'une source de manière à pouvoir les traduire comme
803) du texte UTF-8 plutôt que de les éditer à la main avec Gimp. Nous voudrions
804) intégrer ce processus dans un fichier wml pour faciliter les traductions et
805) regénérer les images en plusieurs langues lorsque nous construisons le site
806) web.</li>
807) 
808) <li>Comment pouvons-nous maintenir, améliorer et documenter plus facilement les
809) différents systèmes LiveCD/USB ? <a href="http://amnesia.boum.org/">Le
810) LiveCD/USB amnesia</a>et <a
811) href="http://anonymityanywhere.com/incognito/">le LiveCD Incognito</a> sont
812) quelques exemples.
813) </li>

814) 
815) <li>

816) Un autre projet anti-censure est de rendre Tor plus résistant au scans
817) réseaux.  Pour le moment, un attaquant peut identifier <a
818) href="<gitblob>doc/spec/proposals/125-bridges.txt">les passerelles Tor</a>
819) en essayant simplement de se connecter à elles en utilisant le protocole Tor
820) pour vérifier si elles répondent.  Pour régler ce problème, les passerelles
821) pourraient <a href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">agir
822) comme des serveurs webs</a> (HTTP ou HTTPS) lorsqu'elles sont contactées par
823) des outils de scan de port et agir comme des passerelles uniquement lorsque
824) l'utilisateur aura amené une clef spécifique.  Pour commencer, consultez <a
825) href="http://dl.dropbox.com/u/37735/index.html">la thèse et le prototype</a>
826) de Shane Pope.

827) </li>
828) 

829) </ol>
830) 
831) <a id="Research"></a>
832) <h2><a class="anchor" href="#Research">Recherche</a></h2>
833) <ol>

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

929) <li>Nos objectifs de résistance à la censure incluent l'impossibilité pour un
930) attaquant qui observe le trafic Tor de <a
931) href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">le
932) distinguer d'un trafic SSL normal</a>. Néanmoins, nous ne pouvons pas
933) recréer une stéganographie parfaite tout en restant utilisable mais, dans un
934) premier temps, nous aimerions pouvoir bloquer toute attaque qui pourrait
935) réussir en observant quelques paquets seulement. Une des attaques qu'il nous
936) reste à examiner est basée sur le fait que les paquets Tor font 512 octets
937) et que par conséquence, les paquets du trafic réseau sont également des
938) multiples de 512 octets.  En quoi le fait de modifier les enregistrements
939) TLS et leur en-tête pourrait brouiller ce trafic ? Différentes stratégies de
940) fermeture de tampon dans Tor peuvent-elles avoir un impact sur ce sujet ?
941) Est-ce-qu'un peu de remplissage ferait l'affaire ou bien est-ce-une attaque
942) que nous pouvons accepter ?</li>

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

994) </li>

995) </ol>
996) 

997) <p>

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

1000) </p>

1001) 

1002)   </div>

1003) 

1004)