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: Speed Up Tor Hidden Services" CHARSET="UTF-8"

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

14) 
15) <!-- PUT CONTENT AFTER THIS TAG -->
16) <h2>Projet NLnet: accélérer les Services Cachés Tor</h2>

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

20) Les services cachés Tor permettent aux utilisateurs de mettre en place des
21) services d'information anonymes tels que des sites web qui peuvent
22) uniquement être accédés à travers le réseau Tor et qui sont protégés contre
23) l'identification des machines qui font tourner le service.  Les limites les
24) plus critiquées des services cachés Tor sont le temps nécessaire à
25) l'enregistrement du service dans le réseau et le temps de latence lorsque le
26) client accède au service.  En raison de problèmes de conception dans le
27) protocole Tor d'origine, la connexion vers un nouveau service caché peut
28) prendre plusieurs minutes ce qui conduit la majorité des utilisateurs à
29) abandonner avant que la connexion ne se fasse.  A cause de cette grande
30) latence dans le circuit des services cachés, il est pratiquement impossible

31) de réaliser des communications interactives d'utilisateur à utilisateur (ex:

32) messagerie instantanée) à l'aide de ces services.

33) </p>
34) 
35) <p>

36) Ce projet a pour but d'accélérer d'une part les services cachés Tor en
37) améliorant la manière dont les circuits Tor sont construits entre
38) l'utilisateur et le service et d'autre part, leurs enregistrements dans le
39) réseau Tor.  Dans un premier temps, des diagnostics précis sur le
40) comportement des services cachés en conditions de laboratoire ou en
41) conditions réelles seront menés afin de découvrir les causes principales de
42) ces lenteurs.  Des stratégies d'optimisation, basées sur ces diagnostics,
43) seront élaborées de manière à éviter les risques de sécurité et d'anonymat
44) dans le réseau Tor.  Les optimisations les plus prometteuses seront alors

45) implémentées de manière à améliorer sensiblement les performances pour les

46) utilisateurs. Des mesures précises seront mises en place lors de la phase de
47) diagnostic, une fois que la lumière sera faîte sur les causes de lenteur et
48) sur les améliorations réalistes.  L'objectif principal est de réaliser le
49) changement du protocole des services cachés en production et propagé à
50) l'ensemble des utilisateurs Tor dans un pas de temps de moins de 12 mois.

51) </p>
52) 
53) <p>

54) Ce projet est généreusement financé par:

55) </p>
56) 
57) <p>

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

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

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

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

72)     <b>Livrable A:</b> Analyse, mesures et exposé des problèmes<br />
73) <small><em>Etant donné qu'il y a eu peu de développement sur les services
74) cachés Tor au cours des dernières années, certains aspects des problèmes
75) sont sous-diagnostiqués. Il est nécessaire d'effectuer une analyse complète
76) des causes de latence et de perte de temps. Le livrable A nécessite environ
77) un mois de travail. Les résultats de l'analyse influenceront les décisions
78) de conception à prendre pour le livrable B.</em></small>

79)   </td>
80)   <td>

81)     15 juin 2008

82)   </td>
83) </tr>
84) 
85) <tr>
86)   <td>

87)     <b>Livrable B:</b> Conception et évaluation des changements nécessaires<br
88) /> <small><em>Les changements dans les services cachés Tor affecteront les
89) fonctionnalités au coeur du protocole et imposent une évaluation prudente
90) des possibles répercussion en matière de sécurité et d'anonymat. Une période
91) de deux mois est planifiée pour la phase de conception et d'évaluation qui
92) se conclura par des tests utilisateurs.</em></small>

93)   </td>
94)   <td>

95)     15 août 2008

96)   </td>
97) </tr>
98) 
99) <tr bgcolor="#e5e5e5">
100)   <td>

101)     <b>Livrable C:</b> Implémentation<br /> <small><em>Après la conception,
102) l'évaluation et le test utilisateur, les modifications doivent être
103) implémentées et intégrées dans la base actuelle du code source de Tor. Cette
104) implémentation prendra approximativement deux mois.  </em></small>

105)   </td>
106)   <td>

107)     15 octobre 2008

108)   </td>
109) </tr>
110) 
111) <tr>
112)   <td>

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

121)   </td>
122)   <td>

123)     15 janvier 2009

124)   </td>
125) </tr>
126) 
127) <tr bgcolor="#e5e5e5">
128)   <td>

129)     <b>Livrable E:</b> Déploiement<br /> <small><em>Le déploiement vers le
130) serveur Tor sur le réseau sera mené en lien avec le calendrier des versions
131) régulières de Tor. Étant donné que ce calendrier dépend d'un certain nombre
132) de facteurs externes tels que l'état des autres projets logiciels devant

133) être incorporés dans la version, la date de livraison de la version actuelle

134) et celle où les modifications auront été complètement acceptées et
135) installées par la majorité des opérateurs de serveurs Tor peuvent
136) varier. D'expérience, on peut s'attendre à une période de trois à quatre
137) mois.</em></small>

138)   </td>
139)   <td>

140)     15 mars 2009

141)   </td>
142) </tr>
143) </table>
144) 

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

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

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

151) </p>
152) 
153) <table width="100%" border="0" cellspacing="0" cellpadding="3">
154) <thead>
155) <tr>
156) <th><big>Mois,</big></th>

157) <th><big>Rapport d'avancement</big></th>

158) </tr>
159) </thead>
160) 
161) <tr bgcolor="#e5e5e5">
162)   <td>

163)     <a id="Jun08"></a> <a class="anchor" href="#Jun08">Juin 2008</a>

164)   </td>
165)   <td>

166)     <small><em>L'objectif d'origine de l'analyse de la lenteur des services
167) cachés Tor a été atteint. Une partie de cette analyse a été de mesurer le
168) temps pour mettre en place ou accéder à un service caché. De plus, on peut
169) maintenant tirer parti des données de mesure d'avril 2008 en vue d'explorer
170) les temps intermédiaires pendant la mise en place d'une connexion vers un
171) service caché. Les résultats sont disponibles dans <a
172) href="http://freehaven.net/~karsten/hidserv/perfanalysis-2008-06-15.pdf">un
173) rapport de 22 pages</a> qui a été rendu public sur <a
174) href="http://archives.seul.org/or/dev/Jun-2008/msg00019.html">la liste de

175) diffusion des développeurs Tor</a>.</em></small> <br/> <small><em> L'analyse
176) a également révélé quelques bugs responsables des délais importants avant
177) qu'un service caché soit accessible. Quelques-uns de ces bugs ont été
178) corrigés, les autres le seront bientôt. L'évaluation a amené plusieurs
179) approches pour améliorer la performance des services cachés. Quelques-unes
180) de ces idées peuvent-être appliquées tout de suite alors que d'autres
181) nécessitent davantage d'analyse ainsi que de nouvelles mesures. Finalement,
182) au cours de l'analyse, nous avons découvert que certaines améliorations
183) imposent de profonds changements à Tor qui ne sont pas forcément liés aux
184) services cachés. Ces changement ne pourront intervenir dans le pas de temps
185) prévu pour ce projet.</em></small>

186)   </td>
187) </tr>
188) 
189) <tr>
190)   <td>

191)     <a id="Jul08"></a> <a class="anchor" href="#Jul08">Juillet 2008</a>

192)   </td>
193)   <td>

194)     <small><em>Tous les bugs trouvés dans l'analyse ont été corrigés. Cela
195) inclut les 2 bugs corrigés pendant l'analyse et 4 autres corrigés dans les
196) 30 derniers jours. Alors que la correction des bugs a supprimé les goulets
197) d'étranglement des performances dûs aux erreurs de programmation,

198) quelques-uns des changements de conception mis en avant au cours de la

199) précédente analyse ont des effets sur l'anonymat ou sur la charge réseau et
200) doivent être expertisés pour vérifier si les gains qu'ils permettent sont
201) valables compte-tenu de leur impact. Un <a
202) href="http://freehaven.net/~karsten/hidserv/discussion-2008-07-15.pdf">rapport</a>
203) a été publié sur <a
204) href="http://archives.seul.org/or/dev/Jul-2008/msg00034.html">la liste de
205) diffusion des développeurs</a> et inclue potentiellement 7 changements de
206) conception devant être débattus. Certaines évaluations (les mesures de
207) faible bande passante et le plan de grande échelle) nécessitent plus de
208) temps que prévu et doivent être planifiées après le livrable B. Le plan
209) actuel consiste à réaliser ces évaluations avant le 15 janvier et à
210) travailler avec des hypothèses avant la publication du résultat
211) final.</em></small>

212)   </td>
213) </tr>
214) 
215) <tr bgcolor="#e5e5e5">
216)   <td>

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

218)   </td>
219)   <td>

220)     <small><em>Durant les 30 derniers jours, les 7 propositions de conception
221) ont été mieux évaluées et débattues. Quatre d'entre-elles se sont montrées
222) réalisables en terme de changement de code et de respect de l'anonymat. Une
223) a été classée comme bug plutôt que comme changement de conception. Deux ont
224) dû être exclues car elles menaient à des problèmes de sécurité ou à des
225) incertitudes dans l'amélioration des performances.</em></small> <br/>
226) <small><em> Selon les résultats du 15 juillet, la phase de conception est
227) terminée. Les tâches à venir pour la phase d'implémentation sont maintenant
228) clairement définies: un bug doit être corrigé et quatre changements de
229) conception doivent être implémentés. De plus, il faudra réaliser des
230) évaluations des changements de conception afin de vérifier leur utilité. Un
231) <a
232) href="http://freehaven.net/~karsten/hidserv/design-2008-08-15.pdf">rapport</a>
233) contenant les résultats de la phase de conception a été publié sur <a
234) href="http://archives.seul.org/or/dev/Aug-2008/msg00025.html">la liste de
235) diffusion des développeurs</a>.</em></small>

236)   </td>
237) </tr>
238) 
239) <tr>
240)   <td>

241)     <a id="Sep08"></a> <a class="anchor" href="#Sep08">Septembre 2008</a>

242)   </td>
243)   <td>

244)     <small><em>During the first half of the implementation phase two bugs could
245) be fixed that were related to hidden services: the <a
246) href="https://trac.torproject.org/projects/tor/ticket/767">first bug</a> has
247) already been identified in the design phase and was responsible for an
248) unusual high failure rate when making a hidden service available in the
249) system; the <a
250) href="https://trac.torproject.org/projects/tor/ticket/814">second bug</a>
251) was found during the implementation phase and was responsible for failure to
252) connect to a working hidden service. Both bugfixes will be included in the
253) next unstable version and likely be backported to one of the next stable
254) releases.</em></small> <br/> <small><em>The four design changes that were
255) proposed as result of the design phase have been implemented in an <a
256) href="https://tor-svn.freehaven.net/svn/tor/branches/hidserv-design-changes/">experimental
257) branch</a> of the unstable development tree. Early function tests have shown
258) that these changes work and provide better (perceived)  performance. This
259) needs to be confirmed throughout the next four weeks in internal tests. The
260) next goal is to prepare a release of this experimental branch that can be
261) given out to beta testers at the beginning of the upcoming testing
262) phase.</em></small>

263)   </td>
264) </tr>
265) 
266) <tr bgcolor="#e5e5e5">
267)   <td>

268)     <a id="Oct08"></a> <a class="anchor" href="#Oct08">Octobre 2008</a>

269)   </td>
270)   <td>

271)     <small><em>La phase d'implémentation est terminée. Les corrections de bugs
272) trouvés lors des 30 derniers jours ont été ajoutées dans la version de
273) développement <a
274) href="http://archives.seul.org/or/talk/Oct-2008/msg00093.html">0.2.1.6-alpha</a>.

275) Les quatre changements de conception qui ont été identifiés lors de la phase

276) de conception ont été décrits dans <a
277) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/155-four-hidden-service-improvements.txt">la
278) proposition 155</a>.  Trois changements de conception ont été ajoutés au
279) code de développement et seront automatiquement injectés dans la prochaine
280) version de développement. Les deux premiers améliorent l'établissement de la
281) connexion à un service caché en réduisant le temps nécessaire à cette
282) opération de 60 à 30 secondes tout en lançant un deuxième essai en parallèle
283) après 15 secondes. Le troisième changement concerne la publication d'un

284) service caché dans le réseau en annonçant le service à 5 au lieu de 3 points

285) dans le réseau en parallèle et en considérant la publication valide dès que
286) les 3 points sont atteints. Maintenant, il n'y a  plus de bugs ni de
287) nouveaux concepts. Tous les changements sont dans le code source et peuvent
288) être testés dans la prochaine phase.</em></small>

289)   </td>
290) </tr>
291) 
292) <tr>
293)   <td>

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

295)   </td>
296)   <td>

297)     <small><em>The performance improvements that were implemented in the last
298) phase have been released in Tor version 0.2.1.7-alpha. Users can download
299) this development version from the Tor homepage and test the improvements
300) with minimal effort. Further, two bugfixes (<a
301) href="https://trac.torproject.org/projects/tor/ticket/767">1</a>, <a
302) href="https://trac.torproject.org/projects/tor/ticket/814">2</a>)  that were
303) found in the course of this project have been backported to the stable
304) branch and will be included with the next stable version
305) 0.2.0.32.</em></small> <br/> <small><em>The main focus of the past 31 days
306) was to perform new measurements to see whether the improvements are
307) effective or not.  Measurements were conducted for two days in the time of
308) November 6th to 8th. Unfortunately, the Tor network suffered a serious
309) problem in this time: An expired directory authority certificate produced
310) huge amounts of traffic within the Tor network which <a
311) href="http://archives.seul.org/or/talk/Nov-2008/msg00053.html">forced many
312) operators to shut down their relays</a>. A second measurement was performed
313) between 13th and 15th. The raw data are available <a
314) href="http://freehaven.net/~karsten/hidserv/perfdata-2008-11-13.tar.gz">here</a>
315) (40 MB). But results show that the overall network performance is still
316) worse than in June 2008 when the first hidden service measurements have been
317) performed. This becomes visible when comparing requests to the Tor
318) directories which have not been affected by the performance improvements and
319) which exhibit significantly worse performance than before. The effects of
320) performance improvements are visible, but absolute values are not comparable
321) at this time. New measurements will be conducted in December in the hope
322) that the effects of this problem have mitigated.</em></small> <br/>
323) <small><em>Further, there might be a <a
324) href="https://trac.torproject.org/projects/tor/ticket/847">bug</a> in the
325) way how Tor downloads directory information during bootstrapping. Even
326) though this is not related to hidden services, an improvement would benefit
327) hidden service publication, too. Part of the work during the upcoming 30
328) days will be to investigate this bug.  </em></small>

329)   </td>
330) </tr>
331) 
332) <tr bgcolor="#e5e5e5">
333)   <td>

334)     <a id="Dec08"></a> <a class="anchor" href="#Dec08">Décembre 2008</a>

335)   </td>
336)   <td>

337)     <small><em>Part of the last 30 days has been used to fix bugs that have
338) influenced the previous hidden service measurements. The first <a
339) href="http://archives.seul.org/or/cvs/Nov-2008/msg00100.html">bugfix</a>
340) corrects a possible segmentation fault that was very likely responsible for
341) a number of failed measurement runs. Another <a
342) href="https://trac.torproject.org/projects/tor/ticket/847">bug</a> could be
343) explained that lead to significant delays in bootstrapping: Very slow
344) directory authorities occupied bootstrapping clients for a long time before
345) clients finally gave up and bootstrapped using another authority. As a
346) result, the slowest two directory authorities have dedicated more bandwidth
347) to their nodes, so that the effect is mitigated. A third <a
348) href="https://trac.torproject.org/projects/tor/ticket/874">bug</a> has been
349) introduced with the hidden service performance improvements in November; the
350) effect was that Tor processes running hidden services would stop advertising
351) their service upon reloading their configuration. Further, this bug has
352) uncovered that Tor has re-established its introduction points upon
353) reloading, which might have affected hidden service stability. This bug has
354) been fixed and will be included in the upcoming version
355) 0.2.1.9-alpha.</em></small> <br/> <small><em>Apart from fixing bugs, new
356) measurements have been performed between December 8 and 10. These will very
357) likely be the final measurements to compare hidden service performance now
358) with the beginning of the project. The data have not been completely
359) evaluated, so it is difficult to make a statement about improvements at this
360) point. However, a <a
361) href="http://freehaven.net/~karsten/hidserv/prelimreport-2008-12-15.pdf">preliminary
362) evaluation</a> shows that service publication times have improved
363) significantly. This is a result of Tor clients bootstrapping faster and of
364) the performance improvements added in November. In contrast to this, the
365) results for establishing a connection to a hidden service are less
366) promising. While the improvements added in November seem to have a positive
367) effect on performance, some substeps exhibit significantly worse
368) performance. One example is fetching hidden service descriptors in order to
369) contact a hidden service. A possible explanation is that the sudden increase
370) in the number of hidden service directory nodes in September has had a
371) negative effect on performance. Part of the work in the final 31 days will
372) be to evaluate these data in more detail and make a final conclusion on the
373) achievements of this project.</em></small>

374)   </td>
375) </tr>
376) 
377) <tr>
378)   <td>

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

380)   </td>
381)   <td>

382)     <small><em>La phase de test est terminée. Ces tests ont été menés en tant
383) que phase de beta-test publique incluant tout les changements concernant les
384) service cachés dans la série 0.2.1.x-alpha. Suite à ces tests, deux bugs ont
385) été identifiés, il peuvent d'ores et déjà être corrigés.</em></small> <br/>
386) <small><em>Les autres tests ont servi de mesures et ont été menés en
387) décembre. Une <a
388) href="http://freehaven.net/~karsten/hidserv/comparison-2009-01-15.pdf">comparaison</a>
389) des mesures effectuées successivement en juin et en décembre a montré que
390) les changements dûs à ce projet sont efficaces. En moyenne, le temps de
391) publication du service est passé de 2 minutes 12 à 58 secondes. Cette
392) amélioration dépasse les attentes. Grâce à cette amélioration, il est
393) également envisageable de réduire le temps de stabilisation de 30 secondes à

394) une valeur plus faible dans le futur. Toutefois, l'établissement de la

395) connexion reste aux alentours de 56 secondes entre la requête et la
396) connexion au serveur caché.  La principale cause de ce problème est le
397) passage d'un stockage centralisé des descripteurs de services cachés à une
398) forme décentralisée.  Cet effet de détérioration de la distribution de
399) l'annuaire des services cachés n'avait pas été envisagé jusqu'à présent. Un
400) travail futur devrait se focaliser sur l'amélioration du téléchargement de
401) l'annuaire distribué des services cachés par exemple, en parallélisant les
402) requêtes.</em></small> <br/> <small><em>Ce rapport est le dernier de la

403) série.  Le déploiement de la série 0.2.1.x qui inclue les améliorations des

404) services cachés devrait se dérouler dans les prochaines semaines ou
405) prochains mois.</em></small>

406)   </td>
407) </tr>
408) </table>
409) 
410) <!-- Do we want a people section? If so, would it make sense to write what
411) these people will be doing? And what exactly are these people going to
412) do? :)

413) <a id="People">
414) </a>

415) <h2><a class="anchor" href="#People">People</a></h2>
416) <ul>
417) <li><a href="<page people>#Core">Karsten Loesing</a></li>
418) <li><a href="<page people>#Core">Steven Murdoch</a></li>
419) </ul>
420) -->

421) <br /> <a id="Links"></a>

422) <h2><a class="anchor" href="#Links">Liens</a></h2>
423) <ul>

424) <li>Papier de recherche sur <b>Mesures de performance et de statistiques sur les
425) services cachés Tor</b> (<a
426) href="http://www.uni-bamberg.de/fileadmin/uni/fakultaeten/wiai_lehrstuehle/praktische_informatik/Dateien/Publikationen/loesing2008performance.pdf">PDF</a>)
427) par Karsten Loesing, Werner Sandmann, Christian Wilms, and Guido Wirtz. Dans
428) the Proceedings of the 2008 International Symposium on Applications and the
429) Internet (SAINT), Turku, Finlande juillet 2008.</li>
430) 

431) 
432) 

433) <!-- In the future, put links to proposal, preliminary results, etc. here -->

434) </ul>
435) 

436) </div>
437) 

438) 
439)