tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 13843

3) # Last-Translator: fredzupy@gmail.com

4) 

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

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

10) <h2>Trois choses que vous pouvez faire :</h2>

11) <ol>

12) <li> Pensez à <a href="<page docs/tor-doc-relay>">héberger 
13) un relais</a> pour aider à la croissance du réseau Tor.</li>

14) <li> Informez vos ami-e-s ! Faites-leur héberger des serveurs. Faites-leur utiliser les services 

15) cachés. Encouragez-les à informer leurs propres ami-e-s.</li>
16) <li> Nous recherchons des fonds et des mécènes. Si vous adhérez aux objectifs de Tor, prenez s'il-vous-plaît un moment 
17)   <a href="<page donate>">pour faire un don et aider aux développements 
18)   futurs de Tor</a>. De même, si vous connaissez des 
19)   entreprises, des ONGs, ou d'autres organisations qui souhaitent utiliser des communications 
20)   sécurisées, parlez-leur de nous.</li>

21) </ol>
22) 
23) <a id="Usability"></a>
24) <h2><a class="anchor" href="#Usability">Support d'applications</a></h2>
25) <ol>

26) <li>Nous avons besoin de méthodes efficaces d'interception des requêtes DNS, pour qu'elles ne laissent pas filtrer 
27) d'informations à un observateur local pendant que nous tentons d'être anonymes. (Ce qui 
28) arrive lorsque l'application fait sa résolution DNS avant de passer par 
29) le proxy SOCKS.)</li>

30) <li>Élements tsocks/dsocks :

31) <ul>

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

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

43) </ul>

44) </li>

45) <li>Les gens qui hébergent des serveurs nous signalent qu'ils aimeraient avoir une passante allouée 
46) durant une partie de la journée, et une autre bande passante à un autre moment. 
47) Plutôt que de coder ceci dans Tor, nous aimerions utiliser un petit 
48) script qui communique avec <a href="<page gui/index>">l'interface de contrôle de Tor</a>, 
49) et ferait un setconf pour changer la valeur de la bande passante. Éventuellement, ce pourrait être un script lancé 
50) par cron, ou qui se lancerait à certaines heures (
51) ce qui est certainement plus portable). Quelqu'un pourrait-il écrire cela pour nous, 
52) nous l'ajouterons à <a href="<svnsandbox>tor/contrib/">tor/contrib/</a> ? 
53) C'est une bonne entrée pour la <a href="<page gui/index>"> compétition pour l'interface 
54) graphique de Tor</a>.

55)   <!-- Nous avons un bon script pour ça maintenant, n est-ce pas ? -NM -->

56) </li>
57) <li>Tor peut <a 

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

59) le réseau Tor par un noeud de sortie particulier</a>, mais il serait pratique 
60) de n'avoir qu'à spécifier un pays, et que le serveur de sortie soit choisi automatiquement. Le 
61) meilleur moyen est probablement de récupérer le répertoire de Blossom, et d'utiliser en local un client 
62) qui récupère ce répertoire de manière sûre (via Tor et en vérifiant sa 
63) signature), lise les noms des machines <tt>.country.blossom</tt> et se charge ensuite
64) de choisir le serveur.</li>
65) <li>En parlant de géolocalisation, quelqu'un devrait faire une carte de la Terre 
66) indiquant chaque serveur Tor par un point. La cerise sur le gâteau serait la mise à jour dynamique 
67) de la carte à mesure que le réseau Tor évolue et grandit. Malheureusement, les moyens aisés de faire cela 
68) passent par l'envoi de toutes les données à Google pour qu'il trace cette carte pour vous. Dans quelle mesure 

69) cela jouerait-il sur la confidentialité, et par ailleurs, existe-t-il des solutions de remplacement valables ?</li>

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

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

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

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

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

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

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

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

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

92) </ol>
93) 
94) <a id="Coding"></a>
95) <h2><a class="anchor" href="#Coding">Conception et Code</a></h2>
96) <ol>

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

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

102) l'instabilité et le plantage du système</a>. Nous devrions probablement utiliser des E/S recouvrables 
103) à la place. Une solution pourrait-être d'apprendre à la <a
104) href="http://www.monkey.org/~provos/libevent/">libevent</a> comment utiliser 
105) les E/S recouvrables à la place de select() sous Windows, et alors d'adapter Tor à 

106) la nouvelle interface libevent.</li> Christian King à 
107) <a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">bien
108) démarré</a> sur ce point l'été dernier.</li>
109) <li>Comment pouvons nous faire en sorte que <a
110) href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
111) soit plus simple à maintenir, étendre, et à documenter ?</li>

112) <li>Notre interface graphique préférée pour Tor, nommée
113) <a href="http://vidalia-project.net/">Vidalia</a>, nécessite toutes sortes 
114) de dévelopments.</li>
115) <li>Nous avons besoin maintenant de commencer l'élaboration de notre <a href="<page
116) documentation>#DesignDoc">conception de résistance au blocage</a>. Ceci implique 
117) une refonte de la conception, une modification de différents aspects de Tor, une adaptation de
118) <a href="http://vidalia-project.net/">Vidalia</a> pour qu'il supporte les nouvelles
119) fonctionnalités, et planifier le deploiement.</li>
120) <li>Nous avons besoin d'un ensemble d'outils flexibles de simulation pour étudier de bout en bout
121) les trafics de confirmation d'attaque. Beaucoups de chercheurs ont conçu des simulateurs ad hoc
122) pour confirmer leurs intuitions comme quoi soit l'attaque marche 
123) vraiment bien ou que les défenses fonctionnent. Pouvons nous construire un simulateur
124) qui soit clairement documenté et suffisament ouvert pour que tout le monde sache qu'il

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

126) Voyez l'entrée <a href="#Research">suivante</a> sur les confirmations d'attaque pour les 
127) détails sur le coté recherche de cette tâche &mdash; qui sait, quand ceci sera 
128) fait peut-être pouvez aider en écrivant un papier ou deux.</li>
129) <li>Nous avons besoin d'un banc de test distribué. Nous avons des unités de tests,
130) mais il serait sympa d'avoir un script qui lance un réseau Tor, 
131) l'utilise quelque temps, et vérifie que, au moins, quelques aspects fonctionnent.</li>
132) <li>Aidez Mike Perry sur sa bibliothèque <a

133) href="https://www.torproject.org/svn/torflow/">TorFlow</a> (<a href="https://www.torproject.org/svn/torflow/TODO">TODO</a>):

134) c'est une bibliothèque python qui utilise le <a

135) href="https://www.torproject.org/svn/torctl/doc/howto.txt">protocole du contrôleur Tor

136) </a> pour apprendre à Tor à construire des circuits de différentes manières,
137) et ensuite mesure les performances et essaye de détecter les anomalies.</li>
138) <li>Tor 0.1.1.x inclut le support d'accélérateurs matériels de chiffrage 

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

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

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

142) href="http://en.wikipedia.org/wiki/Fuzz_testing">du "fuzz"</a>. Déterminer 
143) s'il existe déjà de bonnes bibliothèques de fuzz pour ce que nous voulons faire. La célébrité pour celui-lle 

144) grâce à qui une nouvelle version pourra voir le jour !</li>

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

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

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

157) <li>Quelque chose vous déplait ? Regardez la <a

158) href="<svnsandbox>doc/design-paper/roadmap-future.pdf">planification du développement

159) de Tor</a> pour plus d'idées.</li>

160) <li>Vous ne voyez pas vos idées ici ? Nous en avons peut-être besoin ! Contactez

161) nous et aidez.</li>

162) </ol>
163) 
164) <a id="Research"></a>
165) <h2><a class="anchor" href="#Research">Recherche</a></h2>
166) <ol>

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

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

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

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

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

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

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

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

189) <li>"L'attaque par zones de routage" : la littérature spécialisée considère 
190) le plus souvent que le chemin réseau entre Alice et son noeud d'entrée (et entre le noeud de sortie 
191) et Bob) comme un lien unique dans un graphe. En pratique, 
192) cependant, le chemin passe par de nombreux systèmes autonomes (Autonomous Systems : ASes), et <a
193) href="http://freehaven.net/anonbib/#feamster:wpes2004">il n'est pas inhabituel 
194) de retrouver le même AS sur les chemins d'entrée et de sortie</a>.
195) Malheureusement, pour prévoir précisément si le chemin "Alice, entrée, 
196) sortie, Bob" sera dangereux, nous devrions télécharger une zone de routage 
197) internet complète et faire dessus des calculs lourds. Est-ce qu'il existe 

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

199) <li>D'autres questions de recherche concernant la diversité géographique considèrent 
200) la différence entre choisir un circuit efficace et en choisir un aléatoire.
201) Lisez l' <a
202) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">argumentation
203) </a> de Stephen Rollyson sur comment eviter les nœuds lents sans trop impacter
204) l'anonymat. Cet axe de raisonnement nécessite davantage de travail et de 
205) réflexion, mais semble très prometteur.</li>
206) <li>Tor ne fonctionne pas très bien lorsque les serveurs ont des bandes passantes 
207) asymétriques (par exemple câble ou DSL). Comme Tor a des connexions TCP séparées entre 
208) chaque saut, si les octets arrivent correctement mais que les octets sortants 
209) sont bloqués sur place, les mécanismes de refoulement de TCP 
210) ne retransmettent pas vraiment cette information aux flux entrants.
211) Peut-être Tor devrait-il détecter s'il perd beaucoup de paquets sortants, 

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

213) un schéma de type augmentation-descente dans lequel on choisit un débit "sûr", 
214) que l'on augmente jusqu'à perdre des paquets, puis qui redescend, puis qui réaugmente. Nous 
215) avons besoin de quelq'un-e de fort-e en réseau pour simuler ce fonctionnement et aider à concevoir 
216) des solutions. De manière générale, l'évaluation des pertes de performances 
217) d'un tel système pourrait peut-être - dans le cas où elles sont grandes - 
218) servir de motivation pour reconsidérer la question du transport UDP.
219) <li>Un sujet lié est le contrôle de congestion : notre système 

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

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

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

223) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">expérience 
224) sur ssh</a>. Nous aurons à faire des mesures et des réglages, et peut-être 
225) une révision de Tor si les résulats sont bons.</li>
226) <li>Pour permettre à des dissident-e-s de se connecter sans être bloqué-e-s 
227) par les pare-feu de leur pays, nous avons besoin de dizaines de milliers de 
228) relais et pas seulement de quelques centaines. Nous pourrions imaginer un client Tor graphique qui 

229) aurait un bouton "Tor pour la liberté" pour activer l'ouverture d'un port et le relais 

230) de quelques KB/s de trafic pour le réseau Tor. (Quelques KB/s ne devraient pas être trop 
231) pénibles et il y a peu de risque d'abus puisqu'il ne s'agirait pas de noeuds de 
232) sortie.) Mais comment distribuer la liste de ces clients volontaires aux 
233) bons dissidents de manière automatique, tout en ne permettant pas aux 

234) pare-feux au niveau national de l'intercepter et de lister ces clients ? Probablement, il faut faire 

235) intervenir la confiance, au niveau humain. Voir notre <a href="<page documentation>#DesignDoc">document 
236) préliminaire sur la résistance au blocage</a> et notre 
237) <a

238) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance">entrée 

239) dans la FAQ</a> à ce sujet, puis lire <a 
240) href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">la section 
241) sur la résistance à la censure de anonbib</a>.</li>
242) <li>Les circuits Tor sont construits saut par saut, donc en théorie nous pouvons 
243) faire sortir des flux au second saut, au 
244) troisième, etc. Cela paraît bien car cassant l'ensemble des flux sortants 
245) qu'un serveur peut voir. Mais si nous voulons que chaque flux soit sûr, 
246) le chemin "le plus court" devrait comporter au moins 3 sauts dans notre logique actuelle, et 
247) les sorties suivantes seraient encore plus lointaines. Nous devons évaluer ce rapport 
248) performance/sûreté.</li>
249) <li>Il n'est pas difficile de provoquer un DoS sur les serveurs et les serveurs de répertoires Tor. Est-ce 

250) que les puzzles de clients sont la bonne réponse ? Existe-t-il d'autres approches réalisables ? Il y a un bonus 

251) si elles sont rétro-compatibles avec le protocol actuel de Tor.</li>

252) </ol>
253) 

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

255) ces points !

256) 
257)   </div><!-- #main -->
258)