tor-webwml.git

@@ -1,604 +0,0 @@

-## translation metadata

-# Based-On-Revision: 13933

-# Last-Translator: ygrekheretix/gmail/com

-

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

-

-<div class="main-column">

-

-<h2>Три вещи которые можно сделать прямо сейчас:</h2>

-<ol>

-<li> Пожалуйста задумайтесь над возможностью

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

-чтобы увеличить сеть Tor.</li>

-<li> Расскажите друзьям! Пусть они тоже запустят сервер Tor. Пусть

-запустят скрытый сервис. Пусть они расскажут своим друзьям!</li>

-<li> Мы ищем финансирование и спонсоров. Если вам по душе цели Tor,

-пожалуйста <a href="<page donate>">

-помогите проекту деньгами, чтобы поддержать дальнейшую разработку</a>.

-И если вы знаете какие-либо компании, негосударственные организации,

-или другие организации, которым нужна безопасная связь в Сети, расскажите им о нас.</li>

-</ol>

-

-<a id="Usability"></a>

-<h2><a class="anchor" href="#Usability">Поддержка приложений</a></h2>

-<ol>

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

-дополнительной информации локальному наблюдателю когда мы пытаемся оставаться

-анонимными. (Это происходит потому что приложения самостоятельно посылают

-DNS запросы перед обращением к SOCKS прокси.)</li>

-<li>По tsocks/dsocks:

-<ul>

-<li>Нужно

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

-все наши патчи к tsocks</a> и форкнуться. Мы предоставим хостинг для

-этого проекта если требуется.</li>

-<li>Мы должны пропатчить программу "dsocks" (автор Dug Song), чтобы использовать

-Tor'овскую команду <i>mapaddress</i> из интерфейса контроллера, таким образом мы

-не будем терять время в Tor на DNS разрешение перед соединением.</li>

-<li>Мы должны исправить наш скрипт <i>torify</i> так, чтобы он определял

-установленный tsocks или dsocks и правильно вызывал их. Пожалуй для этого

-потребуется унифицировать их интерфейсы, и может быть использовать общий код,

-или вообще отбросить поддержку одного из них.</li>

-</ul>

-</li>

-<li>Операторы серверов хотят иметь возможность указывать разные значения BandwidthRate

-в зависимости от времени дня. Вместо того, чтобы кодить это внутрь самого Tor, лучше

-написать скрипт который будет использовать <a href="<page gui/index>">

-Интерфейс Tor Controller</a>, и посылать setconf для изменения ограничений трафика.

-У нас уже есть такой скрипт для Unix и Mac (он использует bash и cron), но ещё требуется

-аналогичное решение для пользователей Windows.

-</li>

-<li>Tor может <a

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

-выходить из сети Tor через указанный узел</a>, но у нас должна быть возможность

-указать только страну и остальное должно работать автоматически. Лучший способ это

-добыть директорию Blossom, запустить локально клиент Blossom, который безопасно

-(через Tor и проверяя подписи) получает эту директорию,  перехватывает имена вида

-<tt>.country.blossom</tt>, и делает как раз то что нужно.</li>

-<li>Касательно геолокации, кто-то должен нарисовать карту Земли с отмеченными

-серверами Tor. Лучше если эта карта будет обновляться со временем. К сожалению,

-простой способ сделать это - посылать все данные к Google чтобы они нарисовали карту

-за нас. Как это скажется на безопасности, и нет ли у нас других вариантов?</li>

-</ol>

-

-<a id="Documentation"></a>

-<h2><a class="anchor" href="#Documentation">Документация</a></h2>

-<ol>

-<li>Пожалуйста помогите Matt Edman с документацией и примерами к его контроллеру

-Tor, <a href="http://vidalia-project.net/">Vidalia</a>.</li>

-<li>Проверьте

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

-программ</a> которые можно использовать через Tor.</li>

-<li>Нам нужно больше документации по динамическому перехвату

-соединений и перенаправлению их в Tor. Кандидаты - tsocks (Linux), dsocks (BSD),

-и freecap (Windows), т.к. будут лучше использовать нашу новую фичу TransPort.</li>

-<li>У нас есть большой список

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

-программ которые могут быть полезны в качестве интерфейса к Tor</a>.

-Какие из них в каких конкретно ситуациях могут пригодиться? Пожалуйста помогите их

-проверить и задокументировать результаты.</li>

-<li>Помогите перевести веб-страницы и документацию на другие языки.

-Смотрите <a href="<page translation>">инструкции для переводчиков</a>

-если вы хотите помочь. Нам особенно нужен перевод на арабский или фарси,

-для пользователей Tor в странах с сильной цензурой.

-</ol>

-

-<a id="Coding"></a>

-<a id="Summer"></a>

-<a id="Projects"></a>

-<h2><a class="anchor" href="#Projects">Good Coding Projects</a></h2>

-

-<p> 

-You may find some of these projects to be good <a href="<page gsoc>">Google

-Summer of Code 2008</a> ideas. We have labelled each idea with how useful it

-would be to the overall Tor project (priority), how much work we expect it would

-be (effort level), how much clue you should start with (skill level), and which

-of our <a href="<page people>#Core">core developers</a> would be good mentors.

-</p>

-

-<ol>

-

-<li>

-Tor/Polipo/Vidalia Auto-Update Framework

-<br />

-Vidalia already has the ability to notice when the user is running an

-outdated or unrecommended version of Tor. Currently, Vidalia simply pops

-up a little message box that lets the user know they should manually

-upgrade. The goal of this project would be to extend Vidalia with the

-ability to also fetch and install the updated Tor software for the

-user. Time permitting, we would also like to be able to update other

-applications included in the bundled installers, such as Polipo and

-Vidalia itself.

-<br />

-To complete this project, the student will first need to first investigate

-the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate

-their strengths, weaknesses, security properties, and ability to be

-integrated into Vidalia. If none are found to be suitable, the student

-will design their own auto-update framework, document the design, and

-then discuss the design with other developers to assess any security

-issues. The student will then implement their framework (or integrate

-an existing one) and test it.

-<br />

-A student undertaking this project should have good C++ development

-experience. Previous experience with Qt is helpful, but not required. The

-student should also have a basic understanding of common security

-practices, such as package signature verification. Good writing ability

-is also important for this project, since a vital step of the project

-will be producing a design document for others to review and discuss

-with the student prior to implementation.

-</li>

-

-<li>

-An Improved and More Usable Network Map

-<br />

-One of Vidalia's existing features is a network map that shows the user

-the approximate geographic location of relays in the Tor network and

-plots the paths the user's traffic takes as it is tunneled through the

-Tor network. The map is currently not very interactive and has rather

-poor graphics. Instead, we would like to leverage KDE's Marble widget

-that gives us a better quality map and enables improved interactivity,

-such as allowing the user to click on individual relays or circuits to

-display additional information. We might also consider adding the ability

-for users to click on a particular relay or a country containing one or

-more Tor exit relays and say, ``I want my connections to foo.com to exit

-from here.''

-<br />

-This project will first involve the student getting familiar with Vidalia

-and the Marble widget's API. The student will then integrate the widget

-into Vidalia and customize Marble to be better suited for our application,

-such as making circuits clickable, storing cached map data in Vidalia's

-own data directory, and customizing some of the widget's dialogs.

-<br />

-A student undertaking this project should have good C++ development

-experience. Previous experience with Qt and CMake is helpful, but not

-required.

-</li>

-

-<li>

-Better Debian Support & Packaging

-<br />

-Vidalia currently doesn't play nicely on Debian and Ubuntu with the

-default Tor packages. The current Tor packages automatically start Tor

-as a daemon running as the debian-tor user and (sensibly) do not have a

-CntrolPort defined in the default torrc. Consequently, Vidalia will try

-to start its own Tor process since it could not connect to the existing

-Tor, and then Vidalia's Tor process will then exit with an error message

-the user likely doesn't understand since Tor cannot bind its listening

-ports--they're already in use by the original Tor daemon.

-<br />

-The current solution involves either telling the user to stop the

-existing Tor daemon and let Vidalia start its own Tor process, or

-explaining to the user how to set a control port and password in their

-torrc. A better solution on Debian would be to use Tor's ControlSocket,

-which allows Vidalia to talk to Tor via a Unix domain socket, and could

-possibly be enabled by default in Tor's Debian packages. Vidalia can

-then authenticate to Tor using cookie authentication if the user running

-Vidalia is also in the debian-tor group.

-<br />

-This project will first involve adding support for Tor's ControlSocket

-to Vidalia. The student will then develop and test Debian and Ubuntu

-packages for Vidalia that conform to Debian's packaging standards and

-making sure it works well with the existing Tor packages. We can also

-set up an apt repository to host the new Vidalia packages.

-<br />

-A student undertaking this project should have prior knowledge of

-Debian package management and some C++ development experience. Previous

-experience with Qt is helpful, but not required.

-</li>

-

-<li>

-Tor Status Event Interface

-<br />

-There may are a number of status changes of which the user may need

-to be informed. For example, if the user is trying to set up a Tor

-relay and Tor decides the user's relay is not reachable from outside

-the user's network, we should alert the user. Currently, all the user

-gets is a couple log messages in Vidalia's 'message log', which they

-likely never see since they don't receive a notification that something

-has gone wrong. Even if the user does actually look at the message log,

-most of the messages make little sense to the novice user.

-<br />

-Tor has the ability to inform Vidalia of many such status changes, and

-we recently implemented support for a couple of these events. Still,

-there are many more status events the user should be informed of and we

-need a better UI for actually displaying them to the user.

-<br />

-The goal of this project then is to design and implement a UI for

-displaying Tor status events to the user. For example, we might put a

-little badge on Vidalia's tray icon that alerts the user to new status

-events they should look at. Double-clicking the icon could bring up a

-dialog that summarizes recent status events in simple terms and maybe

-suggests a remedy for any negative statuses if they can be corrected by

-the user. Of course, this is just an example and the student is free to

-suggest another approach.

-<br />

-A student undertaking this project should have good UI design and layout

-experience and some C++ development experience. Previous experience

-with Qt and Qt's Designer will be very helpful, but not required. Some

-English writing ability will also be useful, since this project will

-likely involve writing small amounts of help documentation that should

-be understandable by non-technical users. Bonus points for some graphic

-design/Photoshop fu, since we might want/need some shiny new icons too.

-</li>

-

-<li>

-A translation wiki

-<br />

-We require a way to edit and translate sections of the website —

-possibly resulting in a patch for the official svn tree. The current

-"cost" of publication of website changes is quite high even for English

-language users. They need to check out our template files, translate them

-and send us the translation. For a single word change or any type of

-minor change, the page may never be corrected or translated.  It would

-be nice to have a wiki that was specifically geared towards translation

-and would somehow track the upstream (English) versions to indicate when

-a fresh translation is needed. This seems mostly like a job for a wiki

-integrator or wiki software author. Certainly the person would need to

-be interested in human languages and translation. They should at least

-be minimally familiar with what Tor is but would not have to interact

-with the software, only the documentation on the website.

-</li>

-

-<li>

-https://check.torproject.org

-<br />

-We currently have a functional web page to detect if Tor is working. It

-is has a few places where it falls short. It requires improvements with

-regard to default languages and functionality. It currently only responds

-in English. In addition, it is a hack of a perl script that should have

-never seen the light of day. It should probably be rewritten in python

-with multi-lingual support in mind. It currently uses the Tor DNS exit

-list and should continue to do so in the future. It may result in certain

-false positives and these should be discovered, documented, and fixed

-where possible. Anyone working on this project should be interested in

-DNS, basic perl or preferably python programming skills and will have

-to interact minimally with Tor to test their code.

-</li>

-

-<li>

-exitlist.torproject.org

-<br />

-The exitlist software is written by our fabulous anonymous

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

-href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt">exitlist

-design document</a>. Currently, it's functional and it is used by

-check.torproject.org and other users. The issues that are outstanding

-are mostly aesthetic. This wonderful service could use a much better

-website using the common Tor theme. It would be best served with better

-documentation for common services that use an RBL. It could use more

-publicity. A person working on this project should be interested in DNS,

-basic RBL configuration for popular services, and writing documentation.

-The person would require minimal Tor interaction — testing their

-own documentation at the very least. Furthermore, it would be useful

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

-torel-design.txt suggestions.

-</li>

-

-<li>

-Testing Tor for end users

-<br />

-The Tor project currently lacks a solid test to ensure that a

-user has a properly configured web browser. It should test for as

-many known issues as possible. It should attempt to decloak the

-user in any way possible.  Two current webpages that track these

-kinds of issues are run by Greg and HD Moore. Greg keeps a nice <a

-href="http://pseudo-flaw.net/tor/torbutton/">list of issues along

-with their proof of concept code, bug issues, etc</a>. HD Moore runs

-the <a href="http://metasploit.com/research/misc/decloak/">metasploit

-decloak website</a>. A person interested in attacking Tor could start

-by collecting as many workable and known methods for decloaking a

-Tor user. The person should be familiar with the common pitfalls but

-possibly have new methods in mind for implementing decloaking issues. The

-website should ensure that it tells a user what their problem is. It

-should help them to fix the problem or direct them to the proper support

-channels. The person should be closely familiar with using Tor and how

-to prevent Tor leakage.

-</li>

-

-<li>

-Tor needs even better censorship resistance mechanisms.  There are

-several mechanisms that can help.  Tor should be able listen on multiple

-addresses and ports, and allow clients to connect to all of them.

-Tor should be able to appear like a webserver (HTTP or HTTPS) when

-contacted by port-scanning tools.

-</li>

-

-<li>

-Tor should make better use of the more recent features of Niels Provos's

-Libevent library.  Libevent already provides HTTP and socket buffers;

-Tor's code for those could be replaced.  We'll need to improve libevent's

-code as needed; particularly, to add good openssl support on top of

-libevent's buffer abstraction.

-</li>

-

-<li>

-Tor should possibly measure bandwidth in a distributed way, as in the

-<a href="http://freehaven.net/anonbib/">"A Tuneup for Tor"</a> paper

-by Snader and Borisov.  A student could use current testing code to

-double-check this paper's findings and verify the extent to which they

-dovetail with Tor in the wild, and determine good ways to incorporate them

-into the Tor network without adding undesirable n^2 traffic properties

-at the directory authorities.

-</li>

-

-<li>

-It would be useful to have automated build processes for Windows and

-probably other platforms. The purpose of having a continuous integration

-build environment is to ensure that Windows isn't left behind for any of

-the software projects used in the Tor project or its accompanying.<br />

-Buildbot may be a good choice for this as it appears to support all of

-the platforms Tor does. See the 

-<a href="http://en.wikipedia.org/wiki/BuildBot">wikipedia entry for 

-buildbot</a>.<br />

-There may be better options and the person undertaking this task should

-evaluate other options. Any person working on this automatic build

-process should have experience or be willing to learn how to build all

-of the respective Tor related code bases from scratch. Furthermore, the

-person should have some experience building software in Windows

-environments as this is the target audience we want to ensure we do not

-leave behind. It would require close work with the Tor source code but

-probably only in the form of building, not authoring.

-</li>

-

-<li>

-Tor needs to be far more tested.  This is a multi-part effort.  To start

-with, our unit test coverage should rise substantially, especially in

-the areas outside the utility functions.  This will require significant

-refactoring of some parts of Tor, in order to dissociate as much logic

-as possible from globals.<br />

-Additionally, we need to automate our performance testing.  We've got

-buildbot (except on Windows — see above) to automate our regular 

-integration and compile testing already,

-but we need to get our network simulation tests (as built in torflow)

-updated for more recent versions of Tor, and designed to launch a test

-network either on a single machine, or across several, so we can test

-changes in performance on machines in different roles automatically.<br />

-</li>

-

-<li>

-Reanimate one of the approaches to implement a Tor client in Java,

-e.g. the <a href="http://onioncoffee.sourceforge.net/">OnionCoffee

-project</a>, and make it run on <a

-href="http://code.google.com/android/">Android</a>. The first step

-would be to port the existing code and execute it in an Android

-environment. Next, the code should be updated to support the newer Tor

-protocol versions like the <a href="<svnsandbox>doc/spec/dir-spec.txt">v3

-directory protocol</a>. Further, support for requesting or even

-providing Tor hidden services would be neat, but not required. The

-student should be able to understand and write new Java code, including

-a Java cryptography API. Being able to read C code would be helping,

-too. The student should be willing to read the existing documentation,

-implement code based on it, and, if required, refine the documentation

-if things are underdocumented. This project is mostly about coding and

-to a small degree about design.

-</li>

-

-<li>

-Write a tool that runs automatic system tests in addition

-to the existing unit tests. The Java-based Tor simulator <a

-href="https://tor-svn.freehaven.net/svn/puppetor/trunk/">PuppeTor</a>

-might be a good start for starting up a private Tor network, using it

-for a while, and verifying that at least parts of it are working. This

-project requires to conceive a blueprint for performing system tests

-of private Tor networks, before starting to code. Typical types of

-tests range from performing single requests over the private network to

-manipulating exchanged messages and see if nodes handle corrupt messages

-appropriately. The student should be able to obtain a good understanding

-of how Tor works and what problems and bugs could arise to design good

-test cases. Understanding the existing Tor code and documentation is

-vital. If PuppeTor is used, the student should also be able to understand

-and possibly extend an existing Java application. This project is partly

-about design and partly about coding.

-</li>

-

-<li>

-Implement a <a href="http://www.ss64.com/bash/top.html">top-like</a>

-management tool for Tor relays. The purpose of such a tool would be

-to monitor a local Tor relay via its control port and include useful

-system information of the underlying machine. When running this tool, it

-would dynamically update its content like top does for Linux processes.

-<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">This

-or-dev post</a> might be a good first read. The student should be familiar

-with or willing to learn about administering a Tor relay and configuring

-it via its control port. As an initial prototype is written in Python,

-some knowledge about writing Python code would be helpful, too. This

-project is for the one part about identifying requirements to such a

-tool and designing its interface; but on the other part, the project

-also requires a lot of coding.

-</li>

-

-<li>Help Mike Perry on his <a

-href="https://www.torproject.org/svn/torflow/">TorFlow</a>

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

-it's a python library that uses the <a

-href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor controller

-protocol</a> to instruct Tor to build circuits in a variety of ways,

-and then it measures performance and tries to detect anomalies.</li>

-<li>Torflow / soat to detect bad relays and automatically get that

-info to the directory authorities for realtime blacklisting</li>

-<li>Torstatus. Set up an automated system for tracking network health

-over time, graphing it, etc. Better metrics for assessing network

-health and growth.</li>

-<li>vidalia and upnp</li>

-<li>nymble</li>

-

-<li>

-Help port <a

-href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to

-Windows. 1) handle spaces in path names and understand the filesystem

-namespace — namespace meaning where application data, personal data,

-and program data typically reside in various versions of Windows. 2) the

-ability to handle ipv6 communications. 3) the ability to asynchronously

-query name servers, find the system nameservers, and manage netbios

-and dns queries. 4) use native regex capabilities of Windows, rather

-than using 3rd party GNU regex libraries. 5) manage events and buffers

-natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in

-Windows it's whatever the config specifies). 6) some sort of GUI config

-and reporting tool, bonus if it has a systray icon with right clickable

-menu options. Double bonus if it's cross-platform compatible.

-</li>

-

-<li>

-a way to generate the website diagrams from source, so we can translate

-them as utf-8 text rather than with gimp. (svg? or imagemagick?)

-integrate this with a wml file so translations are easy and images are

-generated in multiple languages at web publish

-</li>

-

-<li>How can we make the <a

-href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>

-easier to maintain, improve, and document?</li>

-<li>We need a distributed testing framework. We have unit tests,

-but it would be great to have a script that starts up a Tor network, uses

-it for a while, and verifies that at least parts of it are working.</li>

-

-<li>Don't like any of these? Look at the <a

-href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development

-roadmap</a> for more ideas.</li>

-<li>Don't see your idea here? We probably need it anyway! Contact

-us and find out.</li>

-</ol>

-

-<h2><a class="anchor" href="#Coding">Кодирование и проектирование</a></h2>

-<ol>

-<li>Серверы Tor под Windows XP работают не очень стабильно. Под Windows,

-Tor использует стандартный системный вызов <tt>select()</tt>, который потребляет

-память из non-page pool. Это значит что средний Tor сервер исчерпает весь

-non-page pool,

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

-вызовет ошибку и аварийный останов системы</a>. Наверное лучше было бы

-использовать overlapped IO. Т.е. надо научить

-<a href="http://www.monkey.org/~provos/libevent/">libevent</a> для Windows использовать

-overlapped IO вместо select(), а потом адаптировать Tor к новому интерфейсу

-libevent. Прошлым летом (2007) Christian King начал 

-<a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">работу в этом

-направлении</a>.</li>

-<li>Пора уже начинать вводить наш

-<a href="<page documentation>#DesignDoc">дизайн для противодействия

-блокированию</a>. Это включает отшлифовывание дизайна, исправления кода во

-многих местах, адаптирование <a href="http://vidalia-project.net/">Vidalia</a>

-так чтобы поддерживались новые возможности, и планирование внедрения.</li>

-<li>Нам требуется гибкая система симулирования для изучения атак на опознание

-трафика с оконечным шифрованием. Many researchers have whipped up ad hoc

-simulators to support their intuition either that the attacks work

-really well or that some defense works great. Можем ли мы создать хорошо

-документированный и открытый симулятор так чтобы все могли доверять полученным

-результатам? Это вызовет много новых исследований. Смотрите раздел <a

-href="#Research">ниже</a> о атаках на распознавание &mdash; кто знает, может

-быть когда это будет сделано вы сможете помочь в написании работы.</li>

-<li>Tor версии 0.1.1.x и выше поддерживают аппаратные ускорители криптографических операций

-с помощью OpenSSL. Впрочем, никто никогда это не проверял. Если у вас есть такая

-возможность, проверьте Tor на своей карточке и сообщите нам результаты.</li>

-<li>Выполнить анализ безопасности Tor с помощью

-<a href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Определить,

-существуют ли подходящие библиотеки.</li>

-<li>Tor использует TCP на транспортном уровне и TLS для шифрования

-соединений. Это просто и красиво, но это значит что все ячейки (cell)

-задерживаются, если один пакет потеряется, и это значит что мы можем

-поддерживать только TCP потоки. У нас есть

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

-список причин по которым мы не используем UDP транспорт</a>, но хотелось

-бы сократить этот список. У нас также есть предлагаемая

-<a href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">спецификация для Tor и UDP</a>

- &mdash; пожалуйста сообщите если с ней что не так.</li>

-<li>Мы уже близки к поддержке IPv6 для адресов назначения (на выходящих

-узлах). Если вас интересует IPv6, пожалуй стоит начать с этого пункта.</li>

-</ol>

-

-

-<a id="Research"></a>

-<h2><a class="anchor" href="#Research">Исследования</a></h2>

-<ol>

-<li>"Атака по сигнатуре сайта": создать список нескольких сотен

-популярных сайтов, скачать их страницы, и сохранить набор "сигнатур"

-этих страниц. Наблюдая трафик клиента Tor, по входящим данным,

-путём сопоставления сигнатур можно попытаться отгадать с каким из

-этих сайтов сейчас установлено соединение. Во-первых, насколько эффективна

-эта атака против Tor? После ответа на этот вопрос, начните проверять защиту:

-например можно увеличить размер ячейки с 512 до 1024 байт, можно реализовать

-техники дополнения (padding), такие как

-<a href="http://freehaven.net/anonbib/#timing-fc2004">defensive dropping</a>,

-или можно ввести задержки трафика. Как это повлияет на атаку, и как это скажется

-на юзабилити?

-<li>Атака по "корреляции оконечного трафика": наблюдая трафик Алисы и Боба,

-мы можем <a href="http://freehaven.net/anonbib/#danezis:pet2004">сравнить

-сигнатуры трафика и убедиться что мы наблюдаем один поток</a>.

-На данном этапе Tor принимает этот факт как данность и считается, что

-атака тривиально реализуется в любом случае. Во-первых, правдиво ли это

-допущение. Сколько трафика с каким распределением надо наблюдать чтобы

-атакующая сторона могла быть уверена в результате? Есть ли способы

-замедлить атаку (может быть уменьшить кол-во передаваемой информации)?

-Может быть некоторые схемы дополнения или изменения профиля трафика

-при такой атаке работают лучше чем другие?</li>

-<li>Атака "по зоне маршрута": в большинстве литературы предполагается что

-путь от Алисы к входному узла (и от выходного узла к Бобу) это одно ребро

-на некотором графе. На практике-же, путь проходит через несколько "автономных

-систем" (AS), и

-<a href="http://freehaven.net/anonbib/#feamster:wpes2004">

-не факт что одна и та же AS не будет включать и входящий и выходящий путь</a>.

-К несчастью, чтобы определить безопасность каждой конкретной четвёрки (Алиса,

-входящий узел, выходящий, и Боб), мы должны загрузить полную маршрутную таблицу

-Интернета и выполнить на ней ресурсоёмкие операции. Существуют ли какие-нибудь

-практические приближения, например избегание IP адреса в той же /8 сети?</li>

-<li>Другие исследования географического разнообразия рассматривают компромисс

-между выбором эффективной цепочки и случайной. Смотрите

-<a

-href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">работу</a>

-Stephen Rollyson'на о том как отбросить особенно медленные варианты "не сильно"

-ухудшая анонимность. Это направление исследований требует больше работы и размышлений,

-но выглядит многообещающе.</li>

-<li>Tor не работает очень хорошо на серверах с ассиметричной пропускной

-способностью (например кабель или DSL). Tor устанавливает отдельные TCP

-соединения между каждым прыжком, и если входящие байты прибывают нормально а

-исходящие теряются, механизм TCP push-back не передаёт эту информацию входящему

-потоку. Пожалуй Tor должен определять когда он теряет слишком много исходящих

-пакетов, и устанавливать ограничение на входящий поток чтобы регулировать

-самостоятельно? Можно представить такую схему - сначала выбирается

-консервативное ограничение трафика, которое медленно увеличивается до тех пор

-пока мы начинаем терять пакеты, откатываемся назад, повторяем. Нам требуется

-кто-нибудь хорошо разбирающийся в сетях чтобы симулировать это поведение и

-помочь спроектировать решение, и/или надо понять насколько упадёт

-производительность, и использовать это как мотивацию для пересмотра решения по

-использованию UDP транспорта.</li>

-<li>A related topic is congestion control. Is our

-current design sufficient once we have heavy use? Maybe

-we should experiment with variable-sized windows rather

-than fixed-size windows? That seemed to go well in an <a

-href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">ssh

-throughput experiment</a>. We'll need to measure and tweak, and maybe

-overhaul if the results are good.</li>

-<li>Для того чтобы диссиденты в разных странах могли использовать Tor избегая

-блокирования на уровне брандмауэра страны, требуется не несоклько сотен

-серверов, а несколько десятков тысяч. Надо придумать способ получить такое

-число серверов. Например можно представить GUI для Tor с кнопкой "Tor для

-Свободы" запускающей небольшой сервер (несколько КБ/сек и политика выхода

-non-exit не должны доставлять много хлопот). Но как нам автоматическим образом

-доставить список всех этих добровольных клиентов-серверов диссидентам так чтобы

-брандмауэры на уровне страны не могли перехватить эти списки? Возможно придётся

-разработать сеть доверия пользователей. Смотрите наши

-<a href="<page documentation>#DesignDoc">ранние работы по проектированию

-архитектуры устойчивой к блокированию</a> и соответствующий

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

-а также

-<a

-href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">раздел anonbib

-посвящённый противодействию цензуре</a>.</li>

-<li>Цепочки Tor строятся по одному прыжку за раз, так что в теории мы можем

-использовать некторые потоки для выхода со второго прыжка, некторые с третьего,

-и так далее. Это хорошо так как разбивает мноество выходящих потоков которое

-может наблюдать один конкретный сервер. Но если мы хотим добиться безопасности

-каждого потока, то по нашей логике они должны быть не менее трёх прыжков в длину

-каждый, а остальные тогда будут даже длиннее. Надо исследовать влияние такого

-подхода на скорость и безопасность.</li>

-<li>Сейчас довольно просто заDoSить сервера Tor или сервера каталогов.

-Правильный ответ - игра в загадки с клиентом? Какие ещё практические

-подходы вы можете предложить? Желательно чтобы они были совместимы с существующим

-протоколом.</li>

-</ol>

-

-<a href="<page contact>">Сообщите нам</a> если вы на пути к решению!

-

-  </div><!-- #main -->

-

-#include <foot.wmi>