tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 13933

3) # Last-Translator: ygrekheretix/gmail/com
4) 

5) #include "head.wmi" TITLE="Tor: Добровольцы" CHARSET="UTF-8"

6) 
7) <div class="main-column">
8) 
9) <h2>Три вещи которые можно сделать прямо сейчас:</h2>
10) <ol>
11) <li> Пожалуйста задумайтесь над возможностью

12) <a href="https://svn.torproject.org/svn/tor/trunk/doc/tor-doc-relay.html">запустить сервер</a>,

13) чтобы увеличить сеть Tor.</li>
14) <li> Расскажите друзьям! Пусть они тоже запустят сервер Tor. Пусть
15) запустят скрытый сервис. Пусть они расскажут своим друзьям!</li>
16) <li> Мы ищем финансирование и спонсоров. Если вам по душе цели Tor,
17) пожалуйста <a href="<page donate>">
18) помогите проекту деньгами, чтобы поддержать дальнейшую разработку</a>.
19) И если вы знаете какие-либо компании, негосударственные организации,
20) или другие организации, которым нужна безопасная связь в Сети, расскажите им о нас.</li>
21) </ol>
22) 
23) <a id="Usability"></a>
24) <h2><a class="anchor" href="#Usability">Поддержка приложений</a></h2>
25) <ol>

26) <li>Нам нужно больше хороших способов перехвата DNS запросов, чтобы они не давали

27) дополнительной информации локальному наблюдателю когда мы пытаемся оставаться
28) анонимными. (Это происходит потому что приложения самостоятельно посылают
29) DNS запросы перед обращением к SOCKS прокси.)</li>
30) <li>По tsocks/dsocks:
31) <ul>
32) <li>Нужно

33) <a href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">применить

34) все наши патчи к tsocks</a> и форкнуться. Мы предоставим хостинг для
35) этого проекта если требуется.</li>
36) <li>Мы должны пропатчить программу "dsocks" (автор Dug Song), чтобы использовать
37) Tor'овскую команду <i>mapaddress</i> из интерфейса контроллера, таким образом мы
38) не будем терять время в Tor на DNS разрешение перед соединением.</li>
39) <li>Мы должны исправить наш скрипт <i>torify</i> так, чтобы он определял
40) установленный tsocks или dsocks и правильно вызывал их. Пожалуй для этого
41) потребуется унифицировать их интерфейсы, и может быть использовать общий код,
42) или вообще отбросить поддержку одного из них.</li>
43) </ul>
44) </li>
45) <li>Операторы серверов хотят иметь возможность указывать разные значения BandwidthRate
46) в зависимости от времени дня. Вместо того, чтобы кодить это внутрь самого Tor, лучше
47) написать скрипт который будет использовать <a href="<page gui/index>">
48) Интерфейс Tor Controller</a>, и посылать setconf для изменения ограничений трафика.

49) У нас уже есть такой скрипт для Unix и Mac (он использует bash и cron), но ещё требуется
50) аналогичное решение для пользователей Windows.

51) </li>
52) <li>Tor может <a

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

54) выходить из сети Tor через указанный узел</a>, но у нас должна быть возможность
55) указать только страну и остальное должно работать автоматически. Лучший способ это
56) добыть директорию Blossom, запустить локально клиент Blossom, который безопасно
57) (через Tor и проверяя подписи) получает эту директорию,  перехватывает имена вида
58) <tt>.country.blossom</tt>, и делает как раз то что нужно.</li>
59) <li>Касательно геолокации, кто-то должен нарисовать карту Земли с отмеченными
60) серверами Tor. Лучше если эта карта будет обновляться со временем. К сожалению,
61) простой способ сделать это - посылать все данные к Google чтобы они нарисовали карту
62) за нас. Как это скажется на безопасности, и нет ли у нас других вариантов?</li>
63) </ol>
64) 
65) <a id="Documentation"></a>
66) <h2><a class="anchor" href="#Documentation">Документация</a></h2>
67) <ol>
68) <li>Пожалуйста помогите Matt Edman с документацией и примерами к его контроллеру
69) Tor, <a href="http://vidalia-project.net/">Vidalia</a>.</li>
70) <li>Проверьте

71) <a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">список

72) программ</a> которые можно использовать через Tor.</li>
73) <li>Нам нужно больше документации по динамическому перехвату
74) соединений и перенаправлению их в Tor. Кандидаты - tsocks (Linux), dsocks (BSD),
75) и freecap (Windows), т.к. будут лучше использовать нашу новую фичу TransPort.</li>
76) <li>У нас есть большой список

77) <a href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">

78) программ которые могут быть полезны в качестве интерфейса к Tor</a>.
79) Какие из них в каких конкретно ситуациях могут пригодиться? Пожалуйста помогите их
80) проверить и задокументировать результаты.</li>
81) <li>Помогите перевести веб-страницы и документацию на другие языки.
82) Смотрите <a href="<page translation>">инструкции для переводчиков</a>

83) если вы хотите помочь. Нам особенно нужен перевод на арабский или фарси,
84) для пользователей Tor в странах с сильной цензурой.

85) </ol>
86) 
87) <a id="Coding"></a>

88) <a id="Summer"></a>
89) <a id="Projects"></a>
90) <h2><a class="anchor" href="#Projects">Good Coding Projects</a></h2>

91) 
92) <p> 
93) You may find some of these projects to be good <a href="<page gsoc>">Google
94) Summer of Code 2008</a> ideas. We have labelled each idea with how useful it
95) would be to the overall Tor project (priority), how much work we expect it would
96) be (effort level), how much clue you should start with (skill level), and which
97) of our <a href="<page people>#Core">core developers</a> would be good mentors.
98) </p>
99) 

100) <ol>
101) 
102) <li>
103) Tor/Polipo/Vidalia Auto-Update Framework
104) <br />
105) Vidalia already has the ability to notice when the user is running an
106) outdated or unrecommended version of Tor. Currently, Vidalia simply pops
107) up a little message box that lets the user know they should manually
108) upgrade. The goal of this project would be to extend Vidalia with the
109) ability to also fetch and install the updated Tor software for the
110) user. Time permitting, we would also like to be able to update other
111) applications included in the bundled installers, such as Polipo and
112) Vidalia itself.
113) <br />
114) To complete this project, the student will first need to first investigate
115) the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
116) their strengths, weaknesses, security properties, and ability to be
117) integrated into Vidalia. If none are found to be suitable, the student
118) will design their own auto-update framework, document the design, and
119) then discuss the design with other developers to assess any security
120) issues. The student will then implement their framework (or integrate
121) an existing one) and test it.
122) <br />
123) A student undertaking this project should have good C++ development
124) experience. Previous experience with Qt is helpful, but not required. The
125) student should also have a basic understanding of common security
126) practices, such as package signature verification. Good writing ability
127) is also important for this project, since a vital step of the project
128) will be producing a design document for others to review and discuss
129) with the student prior to implementation.
130) </li>
131) 
132) <li>
133) An Improved and More Usable Network Map
134) <br />
135) One of Vidalia's existing features is a network map that shows the user
136) the approximate geographic location of relays in the Tor network and
137) plots the paths the user's traffic takes as it is tunneled through the
138) Tor network. The map is currently not very interactive and has rather
139) poor graphics. Instead, we would like to leverage KDE's Marble widget
140) that gives us a better quality map and enables improved interactivity,
141) such as allowing the user to click on individual relays or circuits to
142) display additional information. We might also consider adding the ability
143) for users to click on a particular relay or a country containing one or
144) more Tor exit relays and say, ``I want my connections to foo.com to exit
145) from here.''
146) <br />
147) This project will first involve the student getting familiar with Vidalia
148) and the Marble widget's API. The student will then integrate the widget
149) into Vidalia and customize Marble to be better suited for our application,
150) such as making circuits clickable, storing cached map data in Vidalia's
151) own data directory, and customizing some of the widget's dialogs.
152) <br />
153) A student undertaking this project should have good C++ development
154) experience. Previous experience with Qt and CMake is helpful, but not
155) required.
156) </li>
157) 
158) <li>
159) Better Debian Support &amp; Packaging
160) <br />
161) Vidalia currently doesn't play nicely on Debian and Ubuntu with the
162) default Tor packages. The current Tor packages automatically start Tor
163) as a daemon running as the debian-tor user and (sensibly) do not have a
164) CntrolPort defined in the default torrc. Consequently, Vidalia will try
165) to start its own Tor process since it could not connect to the existing
166) Tor, and then Vidalia's Tor process will then exit with an error message
167) the user likely doesn't understand since Tor cannot bind its listening
168) ports--they're already in use by the original Tor daemon.
169) <br />
170) The current solution involves either telling the user to stop the
171) existing Tor daemon and let Vidalia start its own Tor process, or
172) explaining to the user how to set a control port and password in their
173) torrc. A better solution on Debian would be to use Tor's ControlSocket,
174) which allows Vidalia to talk to Tor via a Unix domain socket, and could
175) possibly be enabled by default in Tor's Debian packages. Vidalia can
176) then authenticate to Tor using cookie authentication if the user running
177) Vidalia is also in the debian-tor group.
178) <br />
179) This project will first involve adding support for Tor's ControlSocket
180) to Vidalia. The student will then develop and test Debian and Ubuntu
181) packages for Vidalia that conform to Debian's packaging standards and
182) making sure it works well with the existing Tor packages. We can also
183) set up an apt repository to host the new Vidalia packages.
184) <br />
185) A student undertaking this project should have prior knowledge of
186) Debian package management and some C++ development experience. Previous
187) experience with Qt is helpful, but not required.
188) </li>
189) 
190) <li>
191) Tor Status Event Interface
192) <br />
193) There may are a number of status changes of which the user may need
194) to be informed. For example, if the user is trying to set up a Tor
195) relay and Tor decides the user's relay is not reachable from outside
196) the user's network, we should alert the user. Currently, all the user
197) gets is a couple log messages in Vidalia's 'message log', which they
198) likely never see since they don't receive a notification that something
199) has gone wrong. Even if the user does actually look at the message log,
200) most of the messages make little sense to the novice user.
201) <br />
202) Tor has the ability to inform Vidalia of many such status changes, and
203) we recently implemented support for a couple of these events. Still,
204) there are many more status events the user should be informed of and we
205) need a better UI for actually displaying them to the user.
206) <br />
207) The goal of this project then is to design and implement a UI for
208) displaying Tor status events to the user. For example, we might put a
209) little badge on Vidalia's tray icon that alerts the user to new status
210) events they should look at. Double-clicking the icon could bring up a
211) dialog that summarizes recent status events in simple terms and maybe
212) suggests a remedy for any negative statuses if they can be corrected by
213) the user. Of course, this is just an example and the student is free to
214) suggest another approach.
215) <br />
216) A student undertaking this project should have good UI design and layout
217) experience and some C++ development experience. Previous experience
218) with Qt and Qt's Designer will be very helpful, but not required. Some
219) English writing ability will also be useful, since this project will
220) likely involve writing small amounts of help documentation that should
221) be understandable by non-technical users. Bonus points for some graphic
222) design/Photoshop fu, since we might want/need some shiny new icons too.
223) </li>
224) 
225) <li>
226) A translation wiki
227) <br />
228) We require a way to edit and translate sections of the website &mdash;
229) possibly resulting in a patch for the official svn tree. The current
230) "cost" of publication of website changes is quite high even for English
231) language users. They need to check out our template files, translate them
232) and send us the translation. For a single word change or any type of
233) minor change, the page may never be corrected or translated.  It would
234) be nice to have a wiki that was specifically geared towards translation
235) and would somehow track the upstream (English) versions to indicate when
236) a fresh translation is needed. This seems mostly like a job for a wiki
237) integrator or wiki software author. Certainly the person would need to
238) be interested in human languages and translation. They should at least
239) be minimally familiar with what Tor is but would not have to interact
240) with the software, only the documentation on the website.
241) </li>
242) 
243) <li>
244) https://check.torproject.org
245) <br />
246) We currently have a functional web page to detect if Tor is working. It
247) is has a few places where it falls short. It requires improvements with
248) regard to default languages and functionality. It currently only responds
249) in English. In addition, it is a hack of a perl script that should have
250) never seen the light of day. It should probably be rewritten in python
251) with multi-lingual support in mind. It currently uses the Tor DNS exit
252) list and should continue to do so in the future. It may result in certain
253) false positives and these should be discovered, documented, and fixed
254) where possible. Anyone working on this project should be interested in
255) DNS, basic perl or preferably python programming skills and will have
256) to interact minimally with Tor to test their code.
257) </li>
258) 
259) <li>
260) exitlist.torproject.org
261) <br />
262) The exitlist software is written by our fabulous anonymous

263) contributer Tup. It's a DNS server written in Haskell that supports part of our <a

264) href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt">exitlist
265) design document</a>. Currently, it's functional and it is used by
266) check.torproject.org and other users. The issues that are outstanding
267) are mostly aesthetic. This wonderful service could use a much better
268) website using the common Tor theme. It would be best served with better
269) documentation for common services that use an RBL. It could use more
270) publicity. A person working on this project should be interested in DNS,
271) basic RBL configuration for popular services, and writing documentation.
272) The person would require minimal Tor interaction &mdash; testing their
273) own documentation at the very least. Furthermore, it would be useful

274) if they were interested in Haskell and wanted to implement more of the

275) torel-design.txt suggestions.
276) </li>
277) 
278) <li>
279) Testing Tor for end users
280) <br />
281) The Tor project currently lacks a solid test to ensure that a
282) user has a properly configured web browser. It should test for as
283) many known issues as possible. It should attempt to decloak the
284) user in any way possible.  Two current webpages that track these
285) kinds of issues are run by Greg and HD Moore. Greg keeps a nice <a
286) href="http://pseudo-flaw.net/tor/torbutton/">list of issues along
287) with their proof of concept code, bug issues, etc</a>. HD Moore runs
288) the <a href="http://metasploit.com/research/misc/decloak/">metasploit
289) decloak website</a>. A person interested in attacking Tor could start
290) by collecting as many workable and known methods for decloaking a
291) Tor user. The person should be familiar with the common pitfalls but
292) possibly have new methods in mind for implementing decloaking issues. The
293) website should ensure that it tells a user what their problem is. It
294) should help them to fix the problem or direct them to the proper support
295) channels. The person should be closely familiar with using Tor and how
296) to prevent Tor leakage.
297) </li>
298) 
299) <li>
300) Tor needs even better censorship resistance mechanisms.  There are
301) several mechanisms that can help.  Tor should be able listen on multiple
302) addresses and ports, and allow clients to connect to all of them.
303) Tor should be able to appear like a webserver (HTTP or HTTPS) when
304) contacted by port-scanning tools.
305) </li>
306) 
307) <li>
308) Tor should make better use of the more recent features of Niels Provos's
309) Libevent library.  Libevent already provides HTTP and socket buffers;
310) Tor's code for those could be replaced.  We'll need to improve libevent's
311) code as needed; particularly, to add good openssl support on top of
312) libevent's buffer abstraction.
313) </li>
314) 
315) <li>
316) Tor should possibly measure bandwidth in a distributed way, as in the
317) <a href="http://freehaven.net/anonbib/">"A Tuneup for Tor"</a> paper
318) by Snader and Borisov.  A student could use current testing code to
319) double-check this paper's findings and verify the extent to which they
320) dovetail with Tor in the wild, and determine good ways to incorporate them
321) into the Tor network without adding undesirable n^2 traffic properties
322) at the directory authorities.
323) </li>
324) 
325) <li>
326) It would be useful to have automated build processes for Windows and
327) probably other platforms. The purpose of having a continuous integration
328) build environment is to ensure that Windows isn't left behind for any of
329) the software projects used in the Tor project or its accompanying.<br />
330) Buildbot may be a good choice for this as it appears to support all of
331) the platforms Tor does. See the 
332) <a href="http://en.wikipedia.org/wiki/BuildBot">wikipedia entry for 
333) buildbot</a>.<br />
334) There may be better options and the person undertaking this task should
335) evaluate other options. Any person working on this automatic build
336) process should have experience or be willing to learn how to build all
337) of the respective Tor related code bases from scratch. Furthermore, the
338) person should have some experience building software in Windows
339) environments as this is the target audience we want to ensure we do not
340) leave behind. It would require close work with the Tor source code but
341) probably only in the form of building, not authoring.
342) </li>
343) 
344) <li>
345) Tor needs to be far more tested.  This is a multi-part effort.  To start
346) with, our unit test coverage should rise substantially, especially in
347) the areas outside the utility functions.  This will require significant
348) refactoring of some parts of Tor, in order to dissociate as much logic
349) as possible from globals.<br />
350) Additionally, we need to automate our performance testing.  We've got
351) buildbot (except on Windows &mdash; see above) to automate our regular 
352) integration and compile testing already,
353) but we need to get our network simulation tests (as built in torflow)
354) updated for more recent versions of Tor, and designed to launch a test
355) network either on a single machine, or across several, so we can test
356) changes in performance on machines in different roles automatically.<br />
357) </li>
358) 
359) <li>
360) Reanimate one of the approaches to implement a Tor client in Java,
361) e.g. the <a href="http://onioncoffee.sourceforge.net/">OnionCoffee
362) project</a>, and make it run on <a
363) href="http://code.google.com/android/">Android</a>. The first step
364) would be to port the existing code and execute it in an Android
365) environment. Next, the code should be updated to support the newer Tor
366) protocol versions like the <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
367) directory protocol</a>. Further, support for requesting or even
368) providing Tor hidden services would be neat, but not required. The
369) student should be able to understand and write new Java code, including
370) a Java cryptography API. Being able to read C code would be helping,
371) too. The student should be willing to read the existing documentation,
372) implement code based on it, and, if required, refine the documentation
373) if things are underdocumented. This project is mostly about coding and
374) to a small degree about design.
375) </li>
376) 
377) <li>
378) Write a tool that runs automatic system tests in addition
379) to the existing unit tests. The Java-based Tor simulator <a
380) href="https://tor-svn.freehaven.net/svn/puppetor/trunk/">PuppeTor</a>
381) might be a good start for starting up a private Tor network, using it
382) for a while, and verifying that at least parts of it are working. This
383) project requires to conceive a blueprint for performing system tests
384) of private Tor networks, before starting to code. Typical types of
385) tests range from performing single requests over the private network to
386) manipulating exchanged messages and see if nodes handle corrupt messages
387) appropriately. The student should be able to obtain a good understanding
388) of how Tor works and what problems and bugs could arise to design good
389) test cases. Understanding the existing Tor code and documentation is
390) vital. If PuppeTor is used, the student should also be able to understand
391) and possibly extend an existing Java application. This project is partly
392) about design and partly about coding.
393) </li>
394) 
395) <li>
396) Implement a <a href="http://www.ss64.com/bash/top.html">top-like</a>
397) management tool for Tor relays. The purpose of such a tool would be
398) to monitor a local Tor relay via its control port and include useful
399) system information of the underlying machine. When running this tool, it
400) would dynamically update its content like top does for Linux processes.
401) <a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">This
402) or-dev post</a> might be a good first read. The student should be familiar
403) with or willing to learn about administering a Tor relay and configuring
404) it via its control port. As an initial prototype is written in Python,
405) some knowledge about writing Python code would be helpful, too. This
406) project is for the one part about identifying requirements to such a
407) tool and designing its interface; but on the other part, the project
408) also requires a lot of coding.
409) </li>
410) 
411) <li>Help Mike Perry on his <a
412) href="https://www.torproject.org/svn/torflow/">TorFlow</a>
413) library (<a href="https://www.torproject.org/svn/torflow/TODO">TODO</a>):
414) it's a python library that uses the <a
415) href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor controller
416) protocol</a> to instruct Tor to build circuits in a variety of ways,
417) and then it measures performance and tries to detect anomalies.</li>
418) <li>Torflow / soat to detect bad relays and automatically get that
419) info to the directory authorities for realtime blacklisting</li>
420) <li>Torstatus. Set up an automated system for tracking network health
421) over time, graphing it, etc. Better metrics for assessing network
422) health and growth.</li>
423) <li>vidalia and upnp</li>
424) <li>nymble</li>
425) 
426) <li>
427) Help port <a
428) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
429) Windows. 1) handle spaces in path names and understand the filesystem
430) namespace &mdash; namespace meaning where application data, personal data,
431) and program data typically reside in various versions of Windows. 2) the
432) ability to handle ipv6 communications. 3) the ability to asynchronously
433) query name servers, find the system nameservers, and manage netbios
434) and dns queries. 4) use native regex capabilities of Windows, rather
435) than using 3rd party GNU regex libraries. 5) manage events and buffers
436) natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
437) Windows it's whatever the config specifies). 6) some sort of GUI config
438) and reporting tool, bonus if it has a systray icon with right clickable
439) menu options. Double bonus if it's cross-platform compatible.
440) </li>
441) 
442) <li>
443) a way to generate the website diagrams from source, so we can translate
444) them as utf-8 text rather than with gimp. (svg? or imagemagick?)
445) integrate this with a wml file so translations are easy and images are
446) generated in multiple languages at web publish
447) </li>
448) 
449) <li>How can we make the <a
450) href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
451) easier to maintain, improve, and document?</li>
452) <li>We need a distributed testing framework. We have unit tests,
453) but it would be great to have a script that starts up a Tor network, uses
454) it for a while, and verifies that at least parts of it are working.</li>
455) 
456) <li>Don't like any of these? Look at the <a
457) href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development
458) roadmap</a> for more ideas.</li>
459) <li>Don't see your idea here? We probably need it anyway! Contact
460) us and find out.</li>
461) </ol>
462) 

463) <h2><a class="anchor" href="#Coding">Кодирование и проектирование</a></h2>
464) <ol>
465) <li>Серверы Tor под Windows XP работают не очень стабильно. Под Windows,
466) Tor использует стандартный системный вызов <tt>select()</tt>, который потребляет
467) память из non-page pool. Это значит что средний Tor сервер исчерпает весь
468) non-page pool,

469) <a href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">

470) вызовет ошибку и аварийный останов системы</a>. Наверное лучше было бы
471) использовать overlapped IO. Т.е. надо научить
472) <a href="http://www.monkey.org/~provos/libevent/">libevent</a> для Windows использовать

473) overlapped IO вместо select(), а потом адаптировать Tor к новому интерфейсу
474) libevent. Прошлым летом (2007) Christian King начал 
475) <a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">работу в этом
476) направлении</a>.</li>

477) <li>Пора уже начинать вводить наш
478) <a href="<page documentation>#DesignDoc">дизайн для противодействия
479) блокированию</a>. Это включает отшлифовывание дизайна, исправления кода во
480) многих местах, адаптирование <a href="http://vidalia-project.net/">Vidalia</a>
481) так чтобы поддерживались новые возможности, и планирование внедрения.</li>
482) <li>Нам требуется гибкая система симулирования для изучения атак на опознание
483) трафика с оконечным шифрованием. Many researchers have whipped up ad hoc
484) simulators to support their intuition either that the attacks work
485) really well or that some defense works great. Можем ли мы создать хорошо
486) документированный и открытый симулятор так чтобы все могли доверять полученным
487) результатам? Это вызовет много новых исследований. Смотрите раздел <a
488) href="#Research">ниже</a> о атаках на распознавание &mdash; кто знает, может
489) быть когда это будет сделано вы сможете помочь в написании работы.</li>
490) <li>Tor версии 0.1.1.x и выше поддерживают аппаратные ускорители криптографических операций
491) с помощью OpenSSL. Впрочем, никто никогда это не проверял. Если у вас есть такая
492) возможность, проверьте Tor на своей карточке и сообщите нам результаты.</li>
493) <li>Выполнить анализ безопасности Tor с помощью
494) <a href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Определить,
495) существуют ли подходящие библиотеки.</li>
496) <li>Tor использует TCP на транспортном уровне и TLS для шифрования
497) соединений. Это просто и красиво, но это значит что все ячейки (cell)
498) задерживаются, если один пакет потеряется, и это значит что мы можем
499) поддерживать только TCP потоки. У нас есть

500) <a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">

501) список причин по которым мы не используем UDP транспорт</a>, но хотелось
502) бы сократить этот список. У нас также есть предлагаемая
503) <a href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">спецификация для Tor и UDP</a>
504)  &mdash; пожалуйста сообщите если с ней что не так.</li>
505) <li>Мы уже близки к поддержке IPv6 для адресов назначения (на выходящих
506) узлах). Если вас интересует IPv6, пожалуй стоит начать с этого пункта.</li>
507) </ol>
508) 
509) 
510) <a id="Research"></a>
511) <h2><a class="anchor" href="#Research">Исследования</a></h2>
512) <ol>
513) <li>"Атака по сигнатуре сайта": создать список нескольких сотен
514) популярных сайтов, скачать их страницы, и сохранить набор "сигнатур"
515) этих страниц. Наблюдая трафик клиента Tor, по входящим данным,
516) путём сопоставления сигнатур можно попытаться отгадать с каким из
517) этих сайтов сейчас установлено соединение. Во-первых, насколько эффективна
518) эта атака против Tor? После ответа на этот вопрос, начните проверять защиту:
519) например можно увеличить размер ячейки с 512 до 1024 байт, можно реализовать
520) техники дополнения (padding), такие как
521) <a href="http://freehaven.net/anonbib/#timing-fc2004">defensive dropping</a>,
522) или можно ввести задержки трафика. Как это повлияет на атаку, и как это скажется
523) на юзабилити?
524) <li>Атака по "корреляции оконечного трафика": наблюдая трафик Алисы и Боба,
525) мы можем <a href="http://freehaven.net/anonbib/#danezis:pet2004">сравнить
526) сигнатуры трафика и убедиться что мы наблюдаем один поток</a>.
527) На данном этапе Tor принимает этот факт как данность и считается, что
528) атака тривиально реализуется в любом случае. Во-первых, правдиво ли это
529) допущение. Сколько трафика с каким распределением надо наблюдать чтобы
530) атакующая сторона могла быть уверена в результате? Есть ли способы
531) замедлить атаку (может быть уменьшить кол-во передаваемой информации)?
532) Может быть некоторые схемы дополнения или изменения профиля трафика
533) при такой атаке работают лучше чем другие?</li>
534) <li>Атака "по зоне маршрута": в большинстве литературы предполагается что
535) путь от Алисы к входному узла (и от выходного узла к Бобу) это одно ребро
536) на некотором графе. На практике-же, путь проходит через несколько "автономных
537) систем" (AS), и
538) <a href="http://freehaven.net/anonbib/#feamster:wpes2004">
539) не факт что одна и та же AS не будет включать и входящий и выходящий путь</a>.
540) К несчастью, чтобы определить безопасность каждой конкретной четвёрки (Алиса,
541) входящий узел, выходящий, и Боб), мы должны загрузить полную маршрутную таблицу
542) Интернета и выполнить на ней ресурсоёмкие операции. Существуют ли какие-нибудь
543) практические приближения, например избегание IP адреса в той же /8 сети?</li>
544) <li>Другие исследования географического разнообразия рассматривают компромисс
545) между выбором эффективной цепочки и случайной. Смотрите
546) <a
547) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">работу</a>
548) Stephen Rollyson'на о том как отбросить особенно медленные варианты "не сильно"
549) ухудшая анонимность. Это направление исследований требует больше работы и размышлений,
550) но выглядит многообещающе.</li>
551) <li>Tor не работает очень хорошо на серверах с ассиметричной пропускной
552) способностью (например кабель или DSL). Tor устанавливает отдельные TCP
553) соединения между каждым прыжком, и если входящие байты прибывают нормально а
554) исходящие теряются, механизм TCP push-back не передаёт эту информацию входящему
555) потоку. Пожалуй Tor должен определять когда он теряет слишком много исходящих
556) пакетов, и устанавливать ограничение на входящий поток чтобы регулировать
557) самостоятельно? Можно представить такую схему - сначала выбирается
558) консервативное ограничение трафика, которое медленно увеличивается до тех пор
559) пока мы начинаем терять пакеты, откатываемся назад, повторяем. Нам требуется
560) кто-нибудь хорошо разбирающийся в сетях чтобы симулировать это поведение и
561) помочь спроектировать решение, и/или надо понять насколько упадёт
562) производительность, и использовать это как мотивацию для пересмотра решения по
563) использованию UDP транспорта.</li>
564) <li>A related topic is congestion control. Is our
565) current design sufficient once we have heavy use? Maybe
566) we should experiment with variable-sized windows rather
567) than fixed-size windows? That seemed to go well in an <a
568) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">ssh
569) throughput experiment</a>. We'll need to measure and tweak, and maybe
570) overhaul if the results are good.</li>
571) <li>Для того чтобы диссиденты в разных странах могли использовать Tor избегая
572) блокирования на уровне брандмауэра страны, требуется не несоклько сотен
573) серверов, а несколько десятков тысяч. Надо придумать способ получить такое
574) число серверов. Например можно представить GUI для Tor с кнопкой "Tor для
575) Свободы" запускающей небольшой сервер (несколько КБ/сек и политика выхода
576) non-exit не должны доставлять много хлопот). Но как нам автоматическим образом
577) доставить список всех этих добровольных клиентов-серверов диссидентам так чтобы
578) брандмауэры на уровне страны не могли перехватить эти списки? Возможно придётся
579) разработать сеть доверия пользователей. Смотрите наши
580) <a href="<page documentation>#DesignDoc">ранние работы по проектированию
581) архитектуры устойчивой к блокированию</a> и соответствующий

582) <a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance">раздел FAQ</a>,