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="NLnet Project: Tor for Low Bandwidth Clients" CHARSET="UTF-8"

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

14) 
15) <!-- PUT CONTENT AFTER THIS TAG -->
16) <h2>Projet NLNet: Tor pour les clients à faible bande passante:</h2>

17) <hr />
18) 
19) <p>

20) Le système d'anonymat Tor est pour l'instant utilisable uniquement pour les
21) utilisateurs Internet qui disposent d'une connexion avec une bande passante
22) large. Dès le démarrage du client Tor, un fichier volumineux contenant la
23) description de tous les serveurs Tor est téléchargé. Ce fichier est celui
24) qui est appelé l'Annuaire Tor et permet au client de choisir parmi la
25) multitude de serveurs disponibles dans le réseau Tor. Le téléchargement de
26) l'intégralité de l'Annuaire Tor est indispensable dans le protocole Tor
27) actuellement employé. Ce fichier est trop volumineux pour les utilisateurs
28) de lignes modem ou pour les réseaux mobiles de données comme le GPRS car le
29) chargement initial qui est lancé à chaque fois que l'utilisateur se connecte
30) prend de 10 à 30 minutes sur une ligne lente. En conséquence, Tor n'est pas
31) utilisable sur les personnes utilisant une ligne modem ou une ligne
32) mobile. L'un des objectifs majeurs du projet Tor est de fournir un accès
33) Internet anonyme et sécurisé aux utilisateurs vivants dans les états
34) répréssifs et dictatoriaux. Ces lieux ont souvent des connexion à Internet
35) lentes, soit par modem soit à cause de la faiblesse des liens vers le reste
36) du monde. En permettant à ces utilisateurs d'utiliser le réseaux Tor, un
37) progrès significatif sera réalisé dans la libre information dans ces pays.

38) </p>
39) 
40) <p>

41) Pour rendre Tor utilisable également par les utilisateurs ayant une
42) connexion à faible bande passante, une évolution du protocole Tor est
43) indispensable en vue de réduire la taille du téléchargement initial. Cette
44) nouvelle version du protocole devrait modifier le moyen pour le client de
45) recevoir l'information nécéssaire à l'établissement d'un circuit Tor de
46) manière à ce qu'elle puisse être récupérée en environ trois minutes par une
47) ligne modem à 14,4Kbps. Le travail à fournir à partir de cette proposition a
48) l'objectif final de rendre le changement de protocole en production et
49) propagé à l'ensemble des utilisateurs Tor dans pas de temps de moins de 12
50) mois. Le logiciel résultant sera publié sous licence BSD 3-Clause comme le
51) reste du code source de Tor. Tous les livrables seront entièrement publics.

52) </p>
53) 
54) <p>
55) Ce projet est généreusement financé par:
56) </p>
57) 
58) <p>

59) <a href="http://www.nlnet.nl/news/2008/20080514-awards.html"> <img
60) src="$(IMGROOT)/nlnet-160x60.png" alt="La fondation NLnet" /></a>

61) </p>
62) 
63) <table width="100%" border="0" cellspacing="0" cellpadding="3">
64) <thead>
65) <tr>
66) <th><big>Projet</big></th>

67) <th><big>Date de rendu</big></th>

68) </tr>
69) </thead>
70) 
71) <tr bgcolor="#e5e5e5">
72)   <td>

73)     <b>Livrable A:</b> Fonctionnalités et évaluation du changement de
74) protocole<br /><small><em>Ce livrable couvre le design détaillé et
75) l'évaluation basée sur une simulation des changements nécessaires et des
76) modifications de fonctionnalités du protocole Tor actuel.  Les changements
77) dans le protocole seront relativement substantiels, ils nécessitent donc une
78) évaluation prudente sur les possibles répercussions en terme de sécurité et
79) d'anonymat sur le réseau Tor. Une période de deux mois est planifiée pour
80) cette phase de design et d'évaluation qui conclura à une évaluation
81) intensive par les utilisateurs. Une partie du livrable A sera une définition
82) d'objectif de performance pour la phase d'implémentation. L'objectif de
83) design est de réduire la taille de l'annuaire Tor qu'il faut télécharger aux
84) environ de 300Ko ce qui permettra à un utilisateur sur une ligne à 14,4kbps
85) de le télécharger en environ trois minutes. Il y aura peut-être des écarts
86) par rapport à cet objectif pour des raisons de maintien d'anonymat et de
87) sécurité, mais ce chiffre est bien celui à atteindre.  </em></small>

88)   </td>
89)   <td>
90)     15 juillet 2008
91)   </td>
92) </tr>
93) 
94) <tr>
95)   <td>

96)     <b>Livrable B:</b>Implémentation du changement de protocole<br />
97) <small><em>Après le design, l'évaluation et le test utilisateur, les
98) modifications doivent être implémentées et intégrées dans la base actuelle
99) du code source de Tor. Cette implémentation prendra approximativement trois
100) mois.  </em></small>

101)   </td>
102)   <td>
103)     15 octobre 2008
104)   </td>
105) </tr>
106) 
107) <tr bgcolor="#e5e5e5">
108)   <td>

109)     <b>Livrable C:</b>Tests<br /> <small><em>Étant donné que la modification est
110) hautement critique en terme de sécurité et de maintient d'anonymat pour le
111) réseau Tor, elle requière des tests et du debugging en conditions de
112) laboratoire et en conditions réelles. Une période de trois mois est
113) planifiée pour ces opérations où le développeur responsable est dévolu à ce
114) travail à 1/3 de son temps. Une partie de la phase de tests sera une période
115) de version beta publique.  </em></small>

116)   </td>
117)   <td>

118)     15 janvier 2009

119)   </td>
120) </tr>
121) 
122) <tr>
123)   <td>

124)     <b>Livrable D:</b> Déploiement<br /> <small><em>Le déploiement vers le
125) serveur Tor sur le réseau sera mené en lien avec le calendrier des versions
126) régulières de Tor. Étant donné que ce calendrier dépend d'un certain nombre
127) de facteurs externes tels que l'état des autres projets logiciels devant
128) être incorporé dans la version, la date de livraison de la version actuelle
129) et celle où les modifications auront été complètement acceptées et
130) installées par la majorité des opérateurs de serveurs Tor peuvent
131) varier. D'expérience, on peut s'attendre à une période de trois à quatre
132) mois. Le déploiement sera intégré au processus de versions régulières de Tor
133) qui est une activité continue réalisée par des volontaires et du personnel
134) payés grâce aux dons au projet Tor.  </em></small>

135)   </td>
136)   <td>

137)     15 avril 2009

138)   </td>
139) </tr>
140) </table>
141) 

142) <br /> <a id="Reports"></a>

143) <h2><a class="anchor" href="#Reports">Rapports mensuels d'avancement</a></h2>

144) <p>

145) Il y aura au total huit rapports mensuels d'état qui commenceront avec le
146) premier livrable aux alentours du 15 juillet 2008 et se termineront avec la
147) fin de l'implémentation et des tests aux alentours du 15 janvier 2009.

148) </p>
149) 
150) <table width="100%" border="0" cellspacing="0" cellpadding="3">
151) <thead>
152) <tr>
153) <th><big>Mois,</big></th>
154) <th><big>Rapport d'avancement</big></th>
155) </tr>
156) </thead>
157) 
158) <tr bgcolor="#e5e5e5">
159)   <td>

160)     <a id="Jun08"></a> <a class="anchor" href="#Jun08">Juin 2008</a>
161)   </td>
162)   <td>
163)     <small><em>Nous avons effectué les premières mesures sur l'amorçage des
164) clients Tor. Les résultats ne sont pas très surprenants: un client récupère
165) environ 10ko de certificats, un document de consensus pour 140Ko (maintenant
166) 90Ko voir le paragraphe suivant) et environ 1,5Mo de descripteurs de serveur
167) (la construction des circuits démarre dès la moitié de ce
168) téléchargement).</em></small> <br /> <small><em><a
169) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">La
170) proposition 138</a> réduit la taille des documents de consensus de 30 à 40%
171) et a déjà été implémentée et intégrée dans la
172) spécification. L'implémentation fait partie de la branche 0.2.1.x-alpha et
173) le code source prendra effet une fois que plus des deux-tiers des autorités
174) d'annuaire (soit 5 sur 6) auront été mises à jour.</em></small> <br />
175) <small><em><a
176) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">La
177) proposition 140</a> n'est pas directement liée à la réduction du volume à
178) télécharger au démarrage mais essaye au contraire de rendre le
179) téléchargement des nouveaux documents de consensus moins volumineux. Elle a
180) été rédigée et <a
181) href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">envoyée sur la
182) liste de diffusion or-dev</a>. Il y a quelques questions qui doivent d'abord
183) être réglées par les autres développeurs Tor mais le reste me semble correct
184) et pourrait-être implémenté.</em></small> <br /> <small><em>Le gros du
185) projet est de faire en sorte que les clients ne doivent plus télécharger
186) 1,5Mo de descripteurs de serveurs. <a
187) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">La
188) proposition 141</a> a été <a
189) href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">envoyée sur la
190) liste de diffusion or-dev</a>. Pour le moment, j'y vois 3 choses à faire:
191) déplacer l'information sur l'équilibrage de charge dans le consensus (pas
192) trop complexe), mettre en place un dispositif pour que les clients Tor
193) puissent récupérer des descripteurs de serveurs à la demande depuis les
194) routeurs lorsqu'ils élaborent leur circuit (décrit dans le brouillon) et
195) enfin, gérer la sélection des sorties. Nous sommes toujours en cours de
196) réflexion concernant la dernière partie; quelques possibilités sont
197) mentionnées dans le brouillon.</em></small>

198)   </td>
199) </tr>
200) 
201) <tr>
202)   <td>

203)     <a id="Jul08"></a> <a class="anchor" href="#Jul08">Juillet 2008</a>
204)   </td>
205)   <td>
206)     <small><em>Le travail sur <a
207) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">la
208) proposition 141</a> avance: Il y a deux idées simples pour déplacer
209) l'information de répartition de charge dans le consensus: l'une est basée
210) sur les autorités générant les poids que les clients peuvent utiliser et
211) mettre dans le consensus, l'autre approche consiste à y insérer directement
212) l'information de bande passante depuis le descripteur de serveur.  La
213) dernière option est probablement la plus abordable lorsqu'on étudie
214) également <a
215) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">la
216) proposition 140</a>. Cette dernière évite d'avoir trop d'éléments fluctuants
217) dans le consensus.</em></small> <br /> <small><em>Pour la gestion de la
218) politique de sortie, <a
219) href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">un post de la
220) liste de diffusion or-dev</a> suggère l'ajout d'un hash d'identification de
221) la politique de sortie du noeud soit ajouté au document de consensus.
222) L'ajout dans le consensus de 160 bits à haute entropie par noeud est risqué
223) mais nous pensons que puisque les politiques de sortie sont souvent
224) identiques, le document de consensus devrait se compresser correctement.
225) Nous attendons les mesures sur ce sujet.</em></small>

226)   </td>
227) </tr>
228) 
229) <tr bgcolor="#e5e5e5">
230)   <td>

231)     <a id="Aug08"></a> <a class="anchor" href="#Aug08">Août 2008</a>

232)   </td>
233)   <td>

234)     <small><em>Les documents de vote des autorités d'annuaire et l'algorithme de
235) création de leur consensus ont été modifiés de manière à inclure
236) l'information sur la bande passante et les résumés des politiques de sorties
237) tels qu'indiqués dans la proposition 141.  Une fois que cinq des six
238) autorités en fonctionnement auront mis à jour leur base à la révision 16554,
239) le consensus commencera à inclure cette information.</em></small>

240)   </td>
241) </tr>
242) 
243) <tr>
244)   <td>

245)     <a id="Sep08"></a> <a class="anchor" href="#Sep08">Septembre 08</a>

246)   </td>
247)   <td>

248) <small><em>Pas de mises à jour pour Septembre.</em></small>

249)   </td>
250) </tr>
251) 
252) <tr bgcolor="#e5e5e5">
253)   <td>

254)     <a id="Oct08"></a> <a class="anchor" href="#Oct08">Octobre 08</a>

255)   </td>

256)   <td><p>
257) <small><em>Nous n'avons pas réussi à atteindre notre jalon "terminer
258) l'implémentation" ce mois-ci car le développeur principal du projet avait
259) trop de travail à mener. La bonne nouvelle est que nous avons réalisé une
260) grande partie du travail d'implémentation et il est en cours depuis
261) plusieurs mois maintenant (depuis le jalon d'août) et a donc déjà bénéficié
262) de nombreux tests. Les étapes restantes sont: faire en sorte que les relais
263) sachent comment récupérer les requêtes de demande de descripteurs à partir
264) de l'intérieur du circuit (nous allons probablement utiliser un nouveau type
265) de celulle pour ça de manière à éviter un aller-retour); puis de faire en
266) sorte que les clients puissent effectuer ces requêtes dès lors qu'ils sont
267) dans une version suffisamment récente. Ces deux étapes sont rédigées de
268) manière détaillée dans <a
269) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">la
270) Section 3.2 de la proposition 141</a>.</em></small></p>
271) 
272) <p><small><em>Noter nouveau plan est de disposer de ces deux morceaux courant
273) novembre, et si cela se présente moins bien, alors nous procéderons à une
274) refonte plus radical de notre planning et peut-être également sur le
275) design.</em></small></p>
276) 
277) <p><small><em>Il y a d'autres composants que nous aimerions créer après
278) celui-ci: le premier auquel nous pensons consiste à télécharger des "diffs"
279) du dernier consensus: <a
280) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">140-consensus-diffs.txt</a>.
281) D'abord, cela pourrait consommer moins de bande passante ce qui est toujours
282) appréciable lorsque multiplié par le nombre total de clients, mais aussi,
283) cela signifie que nous pouvons utiliser cette bande passante pour récupérer
284) les diffs plus souvent que l'actuel "toutes les 3 ou 4 heures". Si les
285) clients récupère plus souvent les informations à jour des annuaires, ils
286) peuvent alors construire des chemins plus rapides car ils disposent
287) d'information plus fraîche sur la bande passante de chaque relais (ce qui
288) est lié avec le premier projet NLnet ci-dessus). La nouvelle idée importante
289) est que cela signifie également que nous gérons mieux les relais
290) transitoires: actuellement, un relais doit tourner depuis au moins 3 à 4
291) heures avant de voir des utilisateurs et cela met de côté un grand nombre de
292) volontaires qui désirent faire tourner un relais seulement quelques
293) heures.</em></small></p>
294) <p><small><em>La prochaine étape est de terminer l'implémentation de la
295) proposition 114 de manière à ce que nous puissions la faire tester par les
296) utilisateurs. Espérons que ce sera pour bientôt !</em></small></p>

297)   </td>
298) </tr>
299) 
300) <tr>
301)   <td>

302)     <a id="Nov08"></a> <a class="anchor" href="#Nov08">Novembre 2008</a>

303)   </td>
304)   <td>

305) <p><small><em>Il semble que le plan original que nous avions mis en place pour
306) la dernière partie de développement était à la fois a) beaucoup plus
307) compliqué que prévu et b) heureusement très efficace comparé à ce dont nous
308) avions besoin.</em></small></p>
309) 
310) <p><small><em> Roger a relancé la discussion sur le design sur la liste de
311) diffusion or-dev: <a
312) href="http://archives.seul.org/or/dev/Nov-2008/threads.html">http://archives.seul.org/or/dev/Nov-2008/threads.html</a>.</em></small></p>
313) 
314) <p><small><em>Je pense que nous avons maintenant une meilleure vision des
315) options et des arbitrages: <a
316) href="http://archives.seul.org/or/dev/Nov-2008/msg00007.html">http://archives.seul.org/or/dev/Nov-2008/msg00007.html</a>.</em></small></p>
317) 
318) <p><small><em>Nick a été enterré par d'autres projets de développement
319) (heureusement, ça devrait aller mieux pour le mois à venir) et je veux avoir
320) son opinion sur comment procéder. J'espère que nous retiendrons l'approche
321) la plus simple.</em></small></p>
322) 
323) <p><small><em>Hélas, les approches très simples permettent moins
324) d'évolutivité. Néanmoins, je pense qu'elles feront des bouches-trous
325) corrects pour plus tard -- et comme on ne sait pas quand 'plus tard' arrive,
326) qui sait ce qui aura changé.</em></small></p>

327)   </td>
328) </tr>
329) 
330) <tr bgcolor="#e5e5e5">
331)   <td>

332)     <a id="Jan09"></a> <a class="anchor" href="#Jan09">Janvier 2009</a>

333)   </td>
334)   <td>

335) <p><small><em> J'ai rédigé une version plus détaillée de notre nouvelle idée de
336) design, sous la <a
337) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/158-microdescriptors.txt">proposition
338) Tor #158</a>, et la discussion a commencé ici: <a
339) href="http://archives.seul.org/or/dev/Jan-2009/msg00010.html">http://archives.seul.org/or/dev/Jan-2009/msg00010.html</a>.</em></small></p>

340) 

341) <p><small><em> Je pense que nous en avons terminé ! (En fait, une fois que
342) j'aurais tenu compte de tous les commentaires.)  </em></small></p>
343) 
344) <p><small><em> La raison principale du fait que le projet ne tienne pas le
345) calendrier prévu tient à la conclusion du <a href="<page
346) projects/hidserv>">projet de Karsten de la NLnet sur la performance des
347) services cachés</a>: le principal responsable est l'extension de
348) circuit. Pour le moment, ce projet a proposé d'ajouter davantage
349) d'aller-retours et de complexité sur ce sujet. Ainsi, il nous faut élaborer
350) un meilleur plan pour atteindre l'objectif final sans sacrifier encore plus
351) de performance.  </em></small></p>
352) 
353) <p><small><em>Nous avons modifié la proposition de conception au cours des
354) semaines passées et je pense que nous serons bientôt prêts pour
355) l'implémentation. A noter qu'étant donné notre charge de travail en cours
356) sur le développement qui devrait s'étaler jusqu'à mi-février, il est
357) probable que cette implémentation ne sera mise en oeuvre qu'à partir de la
358) fin février ou pour mars. Cette fois, pour de bon !</em></small></p>

359)   </td>
360) </tr>
361) </table>
362) 
363) <br />
364) 

365) </div>

366) 
367) 
368)