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://trac.torproject.org/projects/tor/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://trac.torproject.org/projects/tor/wiki/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
59) href="https://trac.torproject.org/projects/tor/wiki/CommunityLogos">logo
60) communautaire</a> sous licence Creative commons que chacun puisse utiliser
61) et modifier</li>

62) <li>Créer une présentation qui puisse être utilisée lors des nombreux meetings
63) de groupe sur toute la planète.</li>

64) <li>Créer une vidéo sur les utilisations positives de Tor, sur ce qu'est Tor ou
65) comment l'utiliser.  Quelques personnes ont déjà commencé sur <a
66) href="http://media.torproject.org/video/">le serveur Média de Tor</a>, <a

67) href="http://www.howcast.com/videos/90601-How-To-Circumvent-an-Internet-Proxy">Howcast</a>,

68) et <a href="http://www.youtube.com/thetorproject">Youtube</a>.</li> 

69) <li>Créer un poster ou un jeu de posters autour d'un thème tel que "Tor pour la
70) Liberté !"</li>

71) </ol>
72) 

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

75) 

76) <p>

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

88) </p>

89) 

90) <ol>

91) 

92) <li>

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

125) </li>
126) 
127) <li>

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

150) </li>
151) 

152) <li>

153) <b>Réécrire TorDNSEL avec cette fois, une spécification !</b> <br />
154) Priorité: <i>Haute</i> <br /> Effort à fournir: <i>Moyen</i> <br />
155) Compétences requises: <i>Moyennes</i> <br /> Tuteurs potentiels: <i>Mike,
156) Roger, Sebastian, Damian</i> <br /> La <a href="<page tordnsel/index>">Liste
157) de Sortie DNS Tor (ndt: Tor DNS Exit List) est un programme en Haskell non
158) maintenu qui a trois objectifs. Le premier est de fournir une interface DNS
159) rbl pour les personnes qui souhaitent savoir si une adresse IP donnée est
160) (ou a été récemment) un relais de sortie Tor. Le deuxième objectif est de
161) construire activement des circuits dans le réseau Tor pour se reconnecter à
162) lui-même de manière à connaître l'adresse IP réelle de sortie de chaque
163) relais &mdash; certains relais Tor font sortir le trafic à une autre adresse
164) que celle qui est affichée dans leur descripteur. Le troisième objectif
165) consiste à exporter <a
166) href="http://exitlist.torproject.org/exitAddresses">une liste</a> de manière
167) à ce que <a href="https://check.torproject.org/">check.torproject.org</a>
168) puisse deviner si votre navigateur est configuré pour utiliser Tor.  <br />
169) Ce projet utilisera <a
170) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>, un
171) ensemble de scripts Python qui interagissent avec Tor pour déterminer
172) comment notre Vérificateur de Relais de sortie Tor devrait fonctionner et
173) donc, comment le compiler &mdash; probablement en Python car Torflow est en
174) Python. L'objectif principal est de réduire, le plus possible, les faux
175) positifs en étant assuré de connaître les nouveaux relais le plus rapidement
176) possible, de s'assurer de terminer rapidement la phase de tests et que les
177) réponses soient bien transmises au script de vérification. En bonus, il
178) faudrait standardiser (rédiger la spécification) le format du fichier
179) d'adresses de sortie et réécrire le script  <a

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

181) Bulk Exit List</a> de manière à utiliser ce fichier plutôt que  <a
182) href="https://trac.torproject.org/projects/tor/ticket/1019">l'horrible hack
183) DNS</a> qui est actuellement en vigueur. En extra-bonus, il faudrait
184) travailler avec Freenode, OFTC et/ou les autres réseaux IRC pour être
185) certains que les scripts réalisés sont bien ceux qu'ils attendent, en terme
186) d'identification précise des utilisateurs issus du réseau Tor.  <br /> Vous
187) pouvez récupérer <a href="git://git.torproject.org/git/tordnsel">la dernière
188) version de tordnsel</a> via git.

189) </li>
190) 

191) <li>

192) <b>Améliorer les capacités de résistance à la censure de Tor</b> <br />
193) Priorité: <i>Moyenne à Haute</i> <br /> Effort à fournir: <i>Moyen à
194) Important</i> <br /> Compétences requises: <i>Hautes</i> <br /> Tuteurs
195) potentiels: <i>Nick, Roger, Steven</i> <br /> La série 0.2.1.x de Tor a fait
196) l'objet <a href="<svnprojects>design-paper/blocking.html">d'amélioration
197) sensibles</a> dans la résistance aux censures des États et des
198) organisations.  Néanmoins, Tor a toujours besoin de meilleurs mécanismes
199) dans certaines parties de ses fonctionnalités anti-censure.  <br/> Une des
200) catégories sur laquelle il faut centrer les efforts est l'ajout de
201) fonctionnalités à notre service Python <a
202) href="http://gitweb.torproject.org//bridgedb.git?a=tree">bridgedb</a>. Tor a
203) pour objectif de distribuer des <a href="<page bridges>">adresses de
204) passerelles</a> aux personnes qui ne peuvent accéder directement au réseau
205) Tor. Néanmoins, il y a une course à l'échalotte entre les algorithmes de
206) distribution d'adresses et les algorithmes de collecte et de bloquage de ces
207) dernières. Consultez notre <a
208) href="https://blog.torproject.org/blog/bridge-distribution-strategies">article
209) de blog sur le sujet</a> comme introduction et <a
210) href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html">le message de
211) Roger du mois de décembre sur la liste de diffusion or-dev</a> pour plus de
212) détails &mdash; un gros travail de spécification reste à accomplir.  <br />
213) Si vous voulez mettre les mains dans le cambouis de Tor (en C), un problème
214) moins important que nous devons gérer est le fait que Tor ne peut écouter le
215) réseau que sur une seule combinaison adresse/port à la fois. Il existe <a
216) href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">une proposition
217) visant à réduire cette limite</a> et à permettre aux clients de se connecter
218) à n'importe quel noeud Tor sur de multiples adresses et ports mais il y a
219) besoin de plus de travail dessus.  <br /> Ce projet implique un gros travail
220) de recherche et de conception. Un des défis le plus important est
221) d'identifier et de sélectionner des approches résistantes aux attaques y
222) compris lorsque l'attaquant en connaît la conception. Il sera alors possible
223) de conjuguer résistance à la censure avec facilité d'utilisation et
224) robustesse.

225) </li>

226) 

227) <li>

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

259) </li>

260) 

261) <li>

262) <b>Améliorer notre processus de tests unitaires</b> <br /> Priorité:
263) <i>Moyenne</i> <br /> Effort à fournir: <i>Moyen</i> <br /> Compétences
264) requises: <i>Moyennes</i> <br /> Tuteurs potentiels: <i>Nick, Errin</i> <br
265) /> Tor a besoin d'être bien plus testé. Ce travail est composé de plusieurs
266) parties. Pour commencer, notre couverture de tests unitaires devrait être
267) plus large, spécialement du côté des fonctions utilitaires. Cela implique la
268) refonte de certaines parties de Tor dans le but de dissocier le plus
269) possible la logique du reste.  <br /> Ensuite, nous devons automatiser les
270) tests de performance. Nous avons utilisé builbot pour automatiser notre
271) processus d'intégration et de tests de compilation (nous sommes à la
272) recherche de quelqu'un qui pourrait le faire fonctionner sous Windows). Mais
273) nous avons besoin de mettre à jour nos tests de simulation réseau
274) (construits dans <a
275) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>) pour
276) les versions récentes de Tor et de concevoir la mise en place d'un réseau de
277) test soit sur une seule machine soit sur plusieurs de manière à tester
278) automatiquement les changements de performances selon les rôles de chaque
279) machine.

280) </li>

281) 

282) <li>

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

301) </li>

302) <li>

303) <b>Plus de développements spécifiques à Orbot &amp; Androïd</b> <br/> <br />
304) Priorité: <i>Moyenne</i> <br /> Effort à fournir: <i>Important</i> <br />
305) Niveau de compétences: <i>Moyennes à élevées</i> <br /> Tuteurs potentiels:
306) <i>Nathan</i> <br /> <b>Travail sur l'interface graphique Java Androïd:</b>
307) Écran d'accueil amélioré pour miex présenter les statistiques sur les
308) transferts de données (entrée/sortie), nombre de circuits connectés, qualité
309) de la connexion, etc... L'application Androïd "Tether Wifi" est un modèle à
310) suivre car elle montre en temps réel le nombre d'octets transférés ainsi que
311) les notifications lorsque le client wifi se connecte. De plus, il faudrait
312) améliorer l'affichage des messages d'erreur. Enfin, l'ajout d'un assistant
313) ou d'un tutoriel pour les novices qui leur expliquerait ce qu'est vraiment
314) l'anonymat leur permettrait d'utiliser correctement Orbot. <br/><br/>
315) <b>Travail sur le coeur de l'application Java Androïd:</b> Il y a besoin
316) d'un meilleur système d'indication, par la barre de notification, des
317) pop-ups ou tout autre mode que le traffic d'une application circule à
318) travers Orbot/Tor. Par exemple, vous devez consulter un site de vérification
319) pour confirmer que votre navigateur web route bien son traffic à travers
320) Tor. Orbot devrait être capable de notifier que les circuits ont été
321) ouverts, utilisés, etc... Le pisteur de transfert de données mentionné
322) ci-dessus pourrait également indiquer cette information. <br/><br/>
323) <b>Travail de sensibilisation de la communauté sur un bibliothèque Java
324) Android</b> Nous devons mettre en paquet une bibliothèque simplifiée pour
325) permettre de "Torifier" certaines applications sur les périphériques
326) non-root (aka proxy transparent). Cette bibliothèque devrait inclure un
327) wrapper pour la bibliothèque Apache HTTPClient, une classe pour détecter
328) l'état de connexion d'Orbot et d'autres choses utiles pour une application
329) Android qui aurait besoin de se rendre anonyme. Ce travail inclue la
330) création de la bibliothèque, la documentation et un exemple de code. Le
331) travail d'implémentation avec d'autres applications open-source
332) suivra. <br/><br/> <b>Travail sur Android OS/C/Linux:</b> Le portage de Tor
333) sur Androïd est basiquement une compilation croisée sur Linux ARM. Aucun
334) travail d'optimisation avec l'environnement matériel n'a été mené, ni sur le
335) processeur ARM ou le matériel Android ou sur les réseaux mobiles. Malgré ce
336) manque d'optimisation, Tor gère plutot bien l'environnement des réseaux
337) mobiles, détecte automatiquement le changement d'adresse IP, reconnecte les
338) circuits et gère le passage d'un réseau 2G à 3G à Wifi. 

339) </li>

340) 

341) <li>
342) <b>New Torbutton Features</b> <br /> Priority: <i>Medium</i> <br /> Effort
343) Level: <i>High</i> <br /> Skill Level: <i>High</i> <br /> Likely Mentors:
344) <i>Mike</i> <br/> There are several <a
345) href="https://trac.torproject.org/projects/tor/report/14">good feature
346) requests</a> on the Torbutton Trac section. In particular, <a
347) href="https://trac.torproject.org/projects/tor/ticket/523">Integrating 'New
348) Identity' with Vidalia</a>, <a
349) href="https://trac.torproject.org/projects/tor/ticket/940">ways of managing
350) multiple cookie jars/identities</a>, <a
351) href="https://trac.torproject.org/projects/tor/ticket/637">preserving
352) specific cookies</a> when cookies are cleared, <a
353) href="https://trac.torproject.org/projects/tor/ticket/524">better referrer
354) spoofing</a>, <a
355) href="https://trac.torproject.org/projects/tor/ticket/564">correct Tor
356) status reporting</a>, and <a
357) href="https://trac.torproject.org/projects/tor/ticket/462">"tor://" and
358) "tors://" urls</a> are all interesting features that could be added.  <br />

359) This work would be independent coding in Javascript and the fun world of <a
360) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
361) with not too much involvement in the Tor internals.

362) </li>
363) 
364) 
365) 

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

381) <ol>

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

394) </ol>

395) </li> -->

396) <li>

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

414) </li>

415) 

416) <li>

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

438) </li>

439) 

440) <li>

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

449) </li>

450) 

451) <li>

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

472) </li>
473) 
474) <li>

475) <b>Améliorer la mise en paquets de Tor et Vidalia sur Debian/Ubuntu</b> <br
476) /> Priorité: <i>Moyenne</i> <br /> Effort à fournir: <i>Moyen</i> <br />
477) Compétences requises: <i>Moyennes</i> <br /> Tuteurs potentiels: <i>Erinn,
478) Peter</i> <br /> Vidalia ne fonctionne pas correctement avec Tor sur les
479) plateformes Unix et Linux. En fait, sous Debian et Ubuntu, il y a un
480) mécanisme de configuration qui permet à Vidalia d'empêcher Tor de se lancer
481) au boot (en éditant <code>/etc/default/tor.vidalia</code> en indiquant
482) <code>RUN_DAEMON=no</code>). Néanmoins, il y a besoin de d'implémenter
483) complètement un <a
484) href="<gitblob>doc/spec/control-spec.txt">ControlPort</a>. <br/> Une
485) meilleure solution sur les plateformes Linux et Unix serait d'utiliser la
486) directive ControlSocket qui permet à Vidalia de communiquer avec Tor via une
487) socket Unix et cela pourrait être activé par défaut dans les paquets Tor des
488) distributions. Vidalia peut ensuite s'authentifier sur Tor en utilisant
489) l'authentification du système de fichier (cookie) si l'utilisateur qui a
490) lancé Vidalia est également dans le groupe spécifique à tor pour sa
491) distribution.  <br /> Ce projet implique d'abord le support de la directive
492) ControlSocket dans Vidalia. L'étudiant développera et testera alors les
493) paquets Vidalia pour de nombreuses distributions et s'assurera qu'ils
494) fonctionnent correctement. <br /> Le challenge suivant sera de trouver un
495) moyen intuitif et utilisable pour Vidalia de modifier la configuration de
496) Tor (torrc) même s'il est situé dans <code>/etc/tor/torrc</code>. Sous
497) Debian et Ubuntu, nous gérons cela avec le fichier
498) <code>/etc/default/tor.vidalia</code> susmentionné, mais cette
499) fonctionnalité pourrait être moins spécifique à ces distributions. <br /> La
500) meilleure idée que nous avons trouvée jusqu'à présent est de faire passer
501) cette configuration par le ControlSocket lorsque Vidalia démarre mais c'est
502) une méthode discutable car si l'utilisateur n'utilise pas les derniers
503) paquets Debian/Ubuntu de Tor, ils n'ont sans doute pas désactiver la
504) capacité de Tor à se lancer au démarrage et ils récupéreront une
505) configuration différente de ce qu'ils désirent. La deuxième idée consiste à
506) faire écrire à Vidalia un fichier temporaire torrc et demander à
507) l'utilisateur de le déplacer manuellement dans <code>/etc/tor/torrc</code>
508) mais c'est également discutable car les utilisateurs ne devraient pas gérer
509) ces fichiers directement.  <br />Une personne intéressée par ce projet doit
510) disposer d'une certaine connaissance des règles d'empaquetage dans Debian et
511) avoir une expérience en C++. Des compétences en QT seraient un vrai plus.

512) </li>
513) 
514) <li>

515) <b>Usability testing of Tor</b> <br /> Priority: <i>Medium</i> <br /> Effort
516) Level: <i>Medium</i> <br /> Skill Level: <i>Low to Medium</i> <br /> Likely
517) Mentors: <i>Andrew</i> <br /> Especially the browser bundle, ideally amongst
518) our target demographic.  That would help a lot in knowing what needs to be
519) done in terms of bug fixes or new features. We get this informally at the
520) moment, but a more structured process would be better.

521) </li>
522) 
523) <li>

524) <b>Un proxy IRC d'authentification</b> <br /> Priorité: <i>Basse</i> <br />
525) Effort à fournir: <i>Moyen à Important</i> <br /> Compétences requises:
526) <i>Moyennes à Hautes</i> <br /> Tuteurs potentiels: <i>Sebastian, Weasel,
527) Roger</i> <br /> Le monde entier a besoin d'un proxy IRC
528) d'authentification. Comme nous le rappelle régulièrement la bande dessinée
529) web Penny Arcade: "Utilisateur Internet+ anonymat = abruti". Toutefois, Tor
530) n'a pas de problème avec les sites web car ces derniers permettent à leurs
531) utilisateurs de connecter en utilisant des systèmes d'authentification
532) situés à un autre niveau. Mais les serveurs IRC sont bien plus mauvais car
533) pour la majorité d'entre-eux, le code source est écrit de manière médiocre:
534) difficile à maintenir et plus difficile encore à modifier. De nombreux
535) réseaux IRC bloquent maintenant les connexions depuis Tor et nous ne sommes
536) plus acceptés que sur quasiement deux réseaux (OFTC et Freenode). Cet état
537) signifie qu'un grand nombre de personnes dans le monde affirment "je vous
538) l'avais bien dit" lorsqu'ils évoquent l'anonymat en ligne alors que c'est
539) simplement dû à un manque de technologie pour rendre le problème
540) gérable. Nous avons besoin d'un moyen pour les réseaux IRC de distinguer
541) quels sont les utilisateurs qui ont prouvé leur réputation et qui sont les
542) abrutis, de manière à bien séparer les deux. Il existe quels concepts de
543) recherche comme <a href="http://www.cs.dartmouth.edu/~nymble/">Nymble</a>
544) qui permet aux sites web de blacklister les utilisateurs sans avoir besoin
545) de connaître leur identité. Mais Nymble est conçu pour les interactions sur
546) le web. Nous avons besoin de féderer nos efforts sur le protocole IRC afin
547) de monter un projet semblable à Nymble (ou un plus simple pour démarrer en
548) tant que preuve de concept). Un des moyens d'y parvenir serait de construire
549) un proxy IRC sachant comment écouter les clients IRC et comment parler aux
550) serveurs IRC et bien sûr qui disposerait d'une couche permettant aux
551) utilisateurs de s'authentifier.  Quelques travaux sur ce sujet ont été
552) initiés par d'autres contributeurs; vous pouvez consultezr leurs progrès sur
553) <a href="http://github.com/anonirc/orc">http://github.com/anonirc/orc</a>.

554) </li>
555) 
556) <li>

557) <b>Faire fonctionner torsocks/dsocks sur OS X</b> <br /> Priorité:
558) <i>Moyenne</i> <br /> Effort à fournir: <i>Moyen</i> <br /> Compétences
559) requises: <i>Moyennes</i> <br /> Tuteurs potentiels: <i>?</i> <br /> <a
560) href="http://code.google.com/p/torsocks/">Torsocks</a> et <a
561) href="http://code.google.com/p/dsocks/">dsocks</a> sont des wrappers qui
562) fonctionnent avec des applications, en interceptent leurs connexions réseau
563) sortantes et les injectent dans Tor. L'objectif est de gérer les
564) applications qui ne supportent pas les proxy (ou qui ne les supportent pas
565) correctement). Ces wrappers doivent intercepter de nombreux appels
566) systèmes. Ces appels systèmes sous Linux sont complètement différents de
567) ceux de BSD. Ainsi, torsocks fonctionne bien sous Linux, dsocks fonctionne
568) bien sous BSD (bien qu'il soit moins bien maintenu et qu'il puisse rater
569) davantage d'appels systèmes) mais rien ne fonctionne bien sur les deux
570) systèmes. D'abord, il faut patcher dsocks pour qu'il utilise les commandes
571) de <i>mapadress</i> depuis l'interface de contrôle de manière à ne pas
572) perdre trop de temps pendant la résolution qui s'effectue dans Tor avant la
573) connexion. Ensuite, notre script <i>torify</i> doit détecter si tsocks ou
574) dsocks est installé et appelé celui qui est légitime. Cela implique
575) d'unifier l'interface de ces deux wrappers et peut-être de partager du code
576) entre eux ou bien d'en laisser tomber un des deux.

577) </li>
578) 
579) <li>

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

587) </li>
588) 
589) </ol>
590) 

591) <a id="OtherCoding"></a>
592) <h2><a class="anchor" href="#OtherCoding">Autres idées de spécifications et de
593) code</a></h2>

594) <ol>

595) <li>Les relais Tor ne fonctionnent pas parfaitement sur Windows XP. Sous
596) Windows, Tor utilise l'appel système standard <tt>select()</tt>, qui utilise
597) l'espace non paginé dans le pool. Ce qui implique que les serveurs de taille
598) moyenne vont vider l'espace non paginé, <a
599) href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/WindowsBufferProblems">provoquant
600) l'instabilité et le plantage du système</a>. Nous devrions probablement
601) utiliser des E/S recouvrables à la place. Une solution pourrait-être
602) d'apprendre à la <a
603) href="http://www.monkey.org/~provos/libevent/">libevent</a> comment utiliser
604) les E/S recouvrables à la place de select() sous Windows, et alors d'adapter
605) Tor à la nouvelle interface libevent. Christian King à <a
606) href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">bien
607) démarré</a> sur ce point l'été 2007.</li>

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

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

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

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

633) href="http://en.wikipedia.org/wiki/Fuzz_testing">du "fuzz"</a>. Déterminer
634) s'il existe déjà de bonnes bibliothèques de fuzz pour ce que nous voulons
635) faire. La célébrité pour celui grâce à qui une nouvelle version pourra voir
636) le jour !</li>
637) 

638) <li>Tor utilise TCP pour le transport et TLS pour le chiffrage des liens. C'est
639) simple et efficace, mais cela implique que toutes les unités (cellules) d'un
640) lien sont mises en attente lorsqu'un seul paquet est perdu, et cela signifie
641) que seuls des flux TCP peuvent être raisonnablement supportés. Nous avons
642) dressé une <a
643) href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#YoushouldtransportallIPpacketsnotjustTCPpackets.">liste
644) de raisons pour lesquelles nous n'avons pas bifurqué vers le transport par
645) UDP</a>, mais ce serait bien de voir cette liste se raccourcir. Nous avons
646) aussi proposé <a href="<gitblob>tor/doc/100-tor-spec-udp.txt">une
647) spécification pour Tor et UDP</a> &mdash; lisez-la et faites-nous part de
648) vos remarques et critiques, s'il-vous-plaît.</li>

649) 
650) <li>Nous ne sommes plus très loin d'avoir le support pour IPV6 entre les
651) serveurs de sorties et les adresses finales. Si IPV6 vous tient à cœur,
652) partir de là est sans doute un premier pas.</li>
653) 

654) <li>We need a way to generate the website diagrams (for example, the "How Tor
655) Works" pictures on the <a href="<page overview>">overview page</a> from
656) source, so we can translate them as UTF-8 text rather than edit them by hand
657) with image editors. We might want to integrate this as an wml file so
658) translations are easy and images are generated in multiple languages
659) whenever we build the website.</li>
660) 
661) <li>Comment pouvons-nous maintenir, améliorer et documenter plus facilement les
662) différents systèmes LiveCD/USB ? <a href="https://amnesia.boum.org/">Le
663) système Live (Amnesic)</a> est un bon exemple.

664) </li>

665) 
666) <li>

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

678) </li>
679) 

680) </ol>
681) 
682) <a id="Research"></a>
683) <h2><a class="anchor" href="#Research">Recherche</a></h2>
684) <ol>

685) <li>"L'attaque par corrélation des trafics aux extrémités": par l'observation
686) des trafics de Alice et Bob, il est possible de <a
687) href="http://freehaven.net/anonbib/#danezis:pet2004">comparer les signatures
688) des trafics et d'en déduire qu'il s'agit du même flux</a>. Jusqu'ici, Tor
689) considère ce type d'attaque comme intrinsèque et donc inévitable. Tout
690) d'abord, est-ce réellement vrai ? Quelle quantité de trafic - et avec quelle
691) distribution - est-elle nécessaire pour que l'adversaire soit certain
692) d'avoir gagné ? Est-ce qu'il existe des scénarios (par exemple avoir un
693) trafic faible) pour ralentir cette attaque ? Est-ce que certains types de
694) remplissage ou de modelage de trafic fonctionnent mieux que d'autres ?</li>
695) <li>On peut relier la question qui vient: Est-ce-que le fait de faire tourner un
696) relais/passerelle offre une protection supplémentaire contre ces attaques
697) basées sur les timings ? Un attaquant externe qui ne peut voir l'intérieur
698) des flux TLS peut-il reconnaître de manière fiable les flux individuels ?
699) Est-ce-que le volume de trafic transféré dégrade cette possibilité ? Que
700) faire si le relais du client retarde délibérément le trafic montant pour
701) former une queue pouvant être utilisée pour mimer les timings du trafic
702) descendant du client pour le faire passer pour du trafic egalement relayé ?
703) Cette queue identique pourrait être également utilisée pour masquer les
704) temps du trafic montant du client à l'aide des techniques dites <a
705) href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptative
706) padding</a> sans avoir besoin de trafic supplémentaire. Est-ce-qu'un tel
707) entrelacement du trafic montant du client osbcurcit les temps pour des
708) attaquants externes ? Les stratégies doivent-elles être ajustées pour les
709) liens symétriques ? Ou bien est-ce plus évident que pour les liens
710) symétriques ?</li>
711) <li><a href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">L'attaque
712) d'Oakland 05</a> par Repeat Murdoch et Danezi sur le réseau Tor
713) acutel. Essayez de comprendre pourquoi elle fonctionne bien sur certains
714) noeuds et pas sur les autres. (Ma théorie est que les noeuds rapides avec
715) davantage de capacité résistent mieux à l'attaque). On peut expérimenter
716) cette attaque avec la gestion des options RelayBandwithRate et
717) RelayBandwithBurst pour faire tourner un relais utilisé comme client tout en
718) relayant le traffic de l'attaquant: si nous limitons fortement le
719) RelayBandwithRate, est-ce-que l'attaque est plus difficile ? Quel est le
720) ratio correct de RelayBandwithRate par rapport à la capacité ? D'ailleurs,
721) est-ce-que le ratio joue un rôle dans cette attaque ? Pendant qu'on y est,
722) est-ce-qu'un plus grand nombre de relais candidats augmente le taux de faux
723) positifs ou une autre complexité dans l'attaque ? (Le réseau Tor est
724) maintenant deux fois plus étendu qu'il ne l'était au moment de la rédaction
725) de leur papier). Prenez également le temps de consulter le document <a
726) href="http://freehaven.net/anonbib/#clog-the-queue">Don't Clog the
727) Queue</a>.</li>
728) <li>L'attaque "routing zones": la majorité de ce qui est écrit sur Tor modélise
729) le chemin réseau entre Alice et son noeud d'entrée (et entre Bob et le noeud
730) de sortie) comme un simple lien sur un graphe. En pratique, le chemin
731) traverse de nombreux systèmes automomes (SA) et <a
732) href="http://freehaven.net/anonbib/#feamster:wpes2004">il n'est pas rare que
733) le même SA apparaissent à la fois sur le chemin d'entrée comme sur le chemin
734) de retoure</a>.  Malheureusement, pour être sûr de prédire si un quartet
735) Alice, noeud d'entrée, noeud de sortie, Bob sera dangereux, il faut
736) télécharger entièrement une zone de routage Internet et effectuer de
737) couteuses opérations dessus. Existe-t-il des approximations pratiques comme
738) éviter les adresse IP situées dans le même réseau /8 ?</li>
739) <li>D'autres points de recherche se pose la question de savoir, d'un point de
740) vue diversité géographique, s'il est mieux d'avoir un circuit efficace ou de
741) choisir un circuit au hasard. Consultez <a
742) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">les
743) travaux de Stephen Rollyson</a> qui expliquent comment éviter les choix
744) particulièrement inefficaces sans "trop" compromettre l'anonymat. Cet angle
745) d'attaque a besoin d'être creusé et travaillé mais il a l'air très
746) prometteur.</li>
747) <li>Tor ne fonctionne pas bien lorsque les relais disposent d'une bande passante
748) asymétrique (ex: câble ou ADSL). Etant donné que Tor sépare les connexions
749) entre chaque hop, si les octets entrants arrivent trop vite et que du coup,
750) les octets sortants arrivent plus lentement, les mécanismes de push-back de
751) TCP ne retournent pas cette information aux flux entrants.  Peut-être que
752) Tor devrait détecter les rejets de paquets sortants et réguler les flux
753) entrants de lui-même ? J'imagine un schéma d'ouverture/fermeture où l'on
754) récupère un taux de transfert limite donné qu'on incrémente lentement
755) jusqu'à perdre des paquets, moment où l'on diminuerait le taux, etc... Nous
756) avons besoin de quelqu'un disposant de sérieuses compétences réseau pour
757) simuler cela et apporter son aide pour la mise en place de ces
758) fonctionnalités. Nous avons besoin de comprendre l'importance de la
759) dégradation des performances et de l'utiliser comme élément moteur en vue de
760) reconsidérer le transport par UDP.</li>
761) <li>Le contrôle de la congestion est un sujet proche. Est-ce-que notre
762) spécification permet de gérer les fortes charges ? Peut-être devrions-nous
763) expérimenter des fenêtres de tailles variables plutôt que des fenêtres fixes
764) ? Cela semble prometteur dans <a
765) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">cette
766) expérimentation autour de ssh</a>. Nous avons besoin de mesurer, de corriger
767) et peut-être de refondre quelquechose si les résultats s'avèrent bons.</li>

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

782) <li>Les circuits Tor sont construit pas à pas. Ainsi, il est théoriquement
783) possible de faire sortir des flux à partir du second pas, d'autres à partir
784) du troisième et ainsi de suite. Cela semble une alternative séduisante car
785) elle permet de passer outre la limite en sortie de chaque relais. Mais si
786) nous voulons que chaque flux soit sécurisé, le chemin "le plus court" doit
787) obligatoirement avoir au moins 3 pas selon notre logique actuelle. Nous
788) devons examiner cette alternative sur l'aspect performance en balance de la
789) sécurité</li>
790) <li>Il n'est pas si difficile de faire du dénis de service sur les relais Tor ou
791) les autorités d'annuaire. Les clients forment-ils la meilleure réponse ?
792) Quelles sont les autres approches possibles ? Il serait bien qu'elles soient
793) compatibles avec le protocole Tor actuel.</li>
794) <li>Les programmes tels que <a href="<page torbutton/index>">Torbutton</a> ont
795) pour objectif de masquer le champ UserAgent de votre navigateur web en le
796) replaçant par une réponse uniforme pour tous les utilisateurs Tor. Ainsi, un
797) attaquant ne peut rien déduire de vous en regardant cet en-tête. Il essaye
798) de récupérer une chaîne communément utilisée par les utilisateurs
799) non-Tor. Première question: comment révélons-nous l'utilisation de Tor en
800) mettant à jour régulièrement ce champ ? Si nous le mettons à jour trop
801) souvent, nous supprimons nous-même de l'anonymat. Si nous ne le mettons pas
802) à jour souvent alors tous les utilisateurs de Tor se dévoileront car leur
803) navigateur web indiquera qu'ils utilisent tous une assez vieille version de
804) Firefox. La réponse à la question dépend certainement des versions de
805) Firefox utilisés dans la nature. Deuxième question: régulièrement, les gens
806) nous demande de modifier le champ UserAgent selon un cycle de N chaînes de
807) caractères différentes plutôt que de mettre toujours la même. Est-ce-que
808) cette approche est vraiment utile, malfaisante ou neutre ? A prendre en
809) considération: les cookies et le fait de reconnaître les utilisateurs de
810) Torbutton par leur rotation de UserAgents; les sites webs malicieux qui
811) n'attaque qu'un seul type de navigateur web; la réponse à la question un
812) impact la réponse à la question deux.
813) </li>
814) <li>Actuellement, les clients Tor réutilisent un circuit donné pendant les dix
815) minutes qui suivent sa première utilisation. L'objectif est d'éviter de
816) surcharger le réseau avec des opérations de circuits étendus et également
817) pour éviter que les clients utilisent le même circuit pendant trop longtemps
818) ce qui permettrait au noeud de sortie de les profiler. Hélas, dix minutes
819) est une période de temps sans doute trop longue, spécialement si des
820) connexions vers des protocoles différents (ex messagerie instantanée et
821) navigation internet) utilisent le même circuit. Si nous continuons à fixer
822) le nombre global de la taille des circuits que le réseau a besoin d'établir,
823) existe-t-il de meilleurs et/ou de plus sûrs moyens pour les clients
824) d'affecter des flux aux circuits ou bien pour que les clients construisent
825) des circuits préemptifs ? Peut-être que cet élément de recherche doit
826) commencer par récupérer des traces sur les connexions typiques que les
827) clients initient afin de disposer de données réalistes ?
828) </li>
829) <li>De combien de passerelles avez-vous besoin pour maintenir un bon niveau
830) d'accessibilité ? Nous devrions mesurer le contenu de nos passerelles. Si ce
831) contenu est bien fourni, existe-t-il des moyens de faire en sorte que les
832) utilisateurs de passerelles restent connectés plus longtemps ?

833) </li>

834) </ol>
835) 

836) <p>

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

839) </p>

840) 

841)   </div>

842) 

843)