tor-webwml.git

1) 
2) 

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

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

13) 

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

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

16) <ol>

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

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

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

32) </ol>
33) 

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

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

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

39) <ol>

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

46) <ul>

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

55) </ul>

56) </li>

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

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

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

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

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

114) </ol>
115) 

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

118) 

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

123) 

124) <ol>

125) 

126) <li>

127) <b>Tor Browser Bundle for Linux/Mac OS X</b> <br /> Priority: <i>High</i>
128) <br /> Effort Level: <i>High</i> <br /> Skill Level: <i>Medium</i> <br />
129) Likely Mentors: <i>Steven, Erinn, Jacob, Andrew</i> <br /> The Tor Browser
130) Bundle incorporates Tor, Firefox, Polipo, and the Vidalia user interface
131) (and optionally the <a href="http://pidgin.im/">Pidgin</a> Instant Messaging
132) client). Components are pre-configured to operate in a secure way, and it
133) has very few dependencies on the installed operating system. It has
134) therefore become one of the most easy to use, and popular, ways to use Tor
135) on Windows.  <br /> However, there is currently no released package for
136) Linux and Mac OS X, so this project would be to implement Tor Browser Bundle
137) for OS X and continue work on the Tor Browser Bundle for Linux. This will
138) involve modifications to Vidalia (C++), possibly Firefox (C) then creating
139) and testing the launcher on a range of operating system versions and
140) configurations to verify portability.  Some work on this was completed as
141) part of the Google Summer of Code 2009. Another part of this project is to
142) identify all of the traces left behind by using a Tor Browser Bundle on Mac
143) OS X or Linux.  Developing ways to stop, counter, or remove these traces is
144) a final step.  <br /> Students should be familiar with application
145) development on one or preferably both of Linux and Mac OS X, and be
146) comfortable with C/C++ and shell scripting.  <br /> Part of this project
147) could be usability testing of Tor Browser Bundle, ideally amongst our target
148) demographic.  That would help a lot in knowing what needs to be done in
149) terms of bug fixes or new features. We get this informally at the moment,
150) but a more structured process would be better.

151) </li>
152) 
153) <li>

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

176) </li>
177) 
178) <li>

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

206) </li>

207) 
208) 

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

241) <li>

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

261) </li>

262) 

263) <li>

264) <b>Tor Controller Status Event Interface for Vidalia</b> <br /> Priority:
265) <i>Medium</i> <br /> Effort Level: <i>Medium</i> <br /> Skill Level: <i>Low
266) to Medium</i> <br /> Likely Mentors: <i>Matt</i> <br /> There are a number
267) of status changes inside Tor of which the user may need to be informed. For
268) example, if the user is trying to set up his Tor as a relay and Tor decides
269) that its ports are not reachable from outside the user's network, we should
270) alert the user. Currently, all the user gets is a couple log messages in
271) Vidalia's 'message log' window, which they likely never see since they don't
272) receive a notification that something has gone wrong. Even if the user does
273) actually look at the message log, most of the messages make little sense to
274) the novice user.  <br /> Tor has the ability to inform Vidalia of many such
275) status changes, and we recently implemented support for a couple of these
276) events. Still, there are many more status events the user should be informed
277) of and we need a better UI for actually displaying them to the user.  <br />
278) The goal of this project then is to design and implement a UI for displaying
279) Tor status events to the user. For example, we might put a little badge on
280) Vidalia's tray icon that alerts the user to new status events they should
281) look at. Double-clicking the icon could bring up a dialog that summarizes
282) recent status events in simple terms and maybe suggests a remedy for any
283) negative events if they can be corrected by the user. Of course, this is
284) just an example and one is free to suggest another approach.  <br /> A
285) person undertaking this project should have good UI design and layout and
286) some C++ development experience. Previous experience with Qt and Qt's
287) Designer will be very helpful, but are not required. Some English writing
288) ability will also be useful, since this project will likely involve writing
289) small amounts of help documentation that should be understandable by
290) non-technical users. Bonus points for some graphic design/Photoshop fu,
291) since we might want/need some shiny new icons too.

292) </li>

293) 

294) <li>

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

313) </li>

314) 

315) <li>

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

334) </li>

335) 

336) <li>

337) <b>Nouvelles fonctionnalités dans Torbutton<b> <br /> Priorité:
338) <i>Moyenne</i> <br /> Effort à fournir: <i>Important</i> <br /> Compétences
339) requises: <i>Hautes</i> <br /> Tuteurs potentiels: <i>Mike</i> <br /> Il
340) existe plusieurs <a

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

359) </li>

360) 

361) 
362) 
363) <!-- <li>
364) 
365) <b>New Thandy Features</b>
366) <br />
367) Priority: <i>Medium</i>
368) <br />
369) Effort Level: <i>Medium</i>
370) <br />
371) Skill Level: <i>Medium to High</i>
372) <br />
373) Likely Mentors: <i>Martin</i>
374) <br />
375) Additional capabilities are needed for assisted updates of all the Tor
376) related software for Windows and other operating systems. Some of the
377) features to consider include:

378) <ol>

379) <li> Integration of the <a
380) href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto
381) Python library</a>
382) for authenticated HTTPS downloads.</li>
383) <li> Adding a level of indirection
384) between the timestamp signatures and the package files included in an
385) update. See the "Thandy attacks / suggestions" thread on or-dev.</li>
386) <li> Support locale specific installation and configuration of assisted
387) updates based on preference, host, or user account language settings.
388) Familiarity with Windows codepages, unicode, and other character sets
389) is helpful in addition to general win32 and posix API experience and
390) Python proficiency.</li>

391) </ol>

392) </li> -->

393) <li>

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

411) </li>

412) 

413) <li>

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

435) </li>

436) 

437) <li>

438) <b>Torbutton equivalent for Thunderbird</b> <br /> Priority: <i>Medium</i>
439) <br /> Effort Level: <i>High</i> <br /> Skill Level: <i>High</i> <br />
440) Likely Mentors: <i>Mike</i> <br /> We're hearing from an increasing number
441) of users that they want to use Thunderbird with Tor. However, there are
442) plenty of application-level concerns, for example, by default Thunderbird
443) will put your hostname in the outgoing mail that it sends. At some point we
444) should start a new push to build a Thunderbird extension similar to
445) Torbutton.

446) </li>

447) 
448) 

449) 
450) <!--<li>
451) 
452) <b>Intermediate Level Network Device Driver</b>
453) <br />
454) Priority: <i>Low</i>
455) <br />
456) Effort Level: <i>High</i>
457) <br />
458) Skill Level: <i>High</i>
459) <br />
460) Likely Mentors: <i>Martin</i>
461) <br />
462) The WinPCAP device driver used by Tor VM for bridged networking does
463) not support a number of wireless and non-Ethernet network adapters.
464) Implementation of a intermediate level network device driver for win32
465) and 64bit would provide a way to intercept and route traffic over such
466) networks. This project will require knowledge of and experience with
467) Windows kernel device driver development and testing. Familiarity with
468) Winsock and Qemu would also be helpful.
469) </li>-->

470) <li>

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

491) </li>
492) 
493) <li>

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

533) </li>
534) 
535) 

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

571) <li>

572) <b>Améliorer le processus qualité de Tor: Intégration continue de
573) compilation</b> <br /> Il serait très utile d'avoir un processus de
574) compilation automatisé pour Windows et pour les autres plateformes. Le but
575) d'avoir un tel environnement est de s'assurer que Windows ne reste pas à la
576) traîne sur aucun des logiciels employés dans le projet Tor. <br />Buildbot
577) semble être un bon choix car il supporte toutes les plateformes
578) surlesquelles Tor fonctionne. Consultez <a
579) href="http://en.wikipedia.org/wiki/BuildBot">l'article Wikipedia sur
580) buildbot</a>.<br /> Il y a sans doute de meilleures options que la personne
581) désirant gérer cette tâche doit évaluer. Toute personne travaillant sur ce
582) processus de compilation automatique doit avoir de l'expérience ou le désir
583) d'apprendre comment compiler l'ensemble du code source en lien avec Tor à
584) partir de rien. De plus, cette personne doit disposer d'une expérience dans
585) la compilation de logiciels sous l'environnement Windows car c'est le coeur
586) de cible à ne pas rater de ce projet. Ce travail impose d'utiliser le code
587) source de Tor mais uniquement du point de vue compilation et non
588) d'écriture.<br />Ensuite, nous avons besoin d'automatiser nos tests de
589) performance pour toutes les plateformes. Nous disposons là encore de builbot
590) (sauf sur Windows &mdash; comme indiqué ci-dessus) pour automatiser nos
591) intégrations régulières de code et nos tests de compilation mais nous avons
592) besoin de mettre à jour nos tests de simulation réseau pour les versions les
593) plus récente de Tor. Enfin, nous avons besoin de lancer des tests réseau à
594) la fois sur une seule machine et également à travers plusieurs autres de
595) manière à tester automatiquement les changement de performance avec des
596) rôles différents.

597) </li>
598) 
599) 

600) 
601) <!--<li>
602) 
603) <b>Usability testing of Tor</b>
604) <br />
605) Priority: <i>Medium</i>
606) <br />
607) Effort Level: <i>Medium</i>
608) <br />
609) Skill Level: <i>Low to Medium</i>
610) <br />
611) Likely Mentors: <i>Andrew</i>
612) <br />
613) Especially the browser bundle, ideally amongst our target demographic.
614) That would help a lot in knowing what needs to be done in terms of bug
615) fixes or new features. We get this informally at the moment, but a more
616) structured process would be better.
617) </li>-->

618) <li>

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

647) </li>
648) 
649) <li>

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

656) </li>
657) 
658) </ol>
659) 

660) <a id="OtherCoding"></a>
661) <h2><a class="anchor" href="#OtherCoding">Autres idées de spécifications et de
662) code</a></h2>

663) <ol>

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

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

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

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

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

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

702) href="http://en.wikipedia.org/wiki/Fuzz_testing">du "fuzz"</a>. Déterminer
703) s'il existe déjà de bonnes bibliothèques de fuzz pour ce que nous voulons
704) faire. La célébrité pour celui grâce à qui une nouvelle version pourra voir
705) le jour !</li>
706) 
707) <li>Tor utilise TCP pour le transport et TLS pour le chiffrage des liens. C'est
708) simple et efficace, mais cela implique que toutes les unités (cellules) d'un
709) lien sont mises en attente lorsqu'un seul paquet est perdu, et cela signifie
710) que seuls des flux TCP peuvent être raisonnablement supportés. Nous avons
711) dressé une <a
712) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">
713) liste de raisons pour lesquelles nous n'avons pas bifurqué vers le transport
714) par UDP</a>, mais ce serait bien de voir cette liste se raccourcir. Nous
715) avons aussi proposé <a href="<gitblob>tor/doc/100-tor-spec-udp.txt">une
716) spécification pour Tor et UDP</a> &mdash; lisez-la et faites-nous part de
717) vos remarques et critiques, s'il-vous-plaît.</li>
718) 
719) <li>Nous ne sommes plus très loin d'avoir le support pour IPV6 entre les
720) serveurs de sorties et les adresses finales. Si IPV6 vous tient à cœur,
721) partir de là est sans doute un premier pas.</li>
722) 
723) <li>Nous avons besoin de générer les diagrammes du site web (par exemple les
724) images de "Comment fonctionne Tor ?" sur <a href="<page overview>">la page
725) d'aperçu</a> à partir d'une source de manière à pouvoir les traduire comme
726) du texte UTF-8 plutôt que de les éditer à la main avec Gimp. Nous voudrions
727) intégrer ce processus dans un fichier wml pour faciliter les traductions et
728) regénérer les images en plusieurs langues lorsque nous construisons le site
729) web.</li>
730) 
731) <li>Comment pouvons-nous maintenir, améliorer et documenter plus facilement les
732) différents systèmes LiveCD/USB ? <a href="http://amnesia.boum.org/">Le
733) LiveCD/USB amnesia</a>et <a
734) href="http://anonymityanywhere.com/incognito/">le LiveCD Incognito</a> sont
735) quelques exemples.
736) </li>

737) </ol>
738) 
739) <a id="Research"></a>
740) <h2><a class="anchor" href="#Research">Recherche</a></h2>
741) <ol>

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

902) </li>

903) </ol>
904) 

905) <p>

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

908) </p>

909) 

910)   </div>

911) 

912)