ru/volunteer.wml (ad7f14a8b) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 11649
# Last-Translator: ygrekheretix/gmail/com

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

<h2>Три вещи которые можно сделать прямо сейчас:</h2>
<ol>
<li> Пожалуйста задумайтесь над возможностью
<a href="<cvssandbox>tor/doc/tor-doc-server.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 для изменения ограничений трафика.
Возможно он будет запускаться cron'ом, или может самостоятельно засыпать и просыпаться
(выполняя действия по настройке) в определённое время. Может-ли кто-нибудь
написать такое за нас и мы положим этот скрипт в <a href="<svnsandbox>contrib/">contrib/</a>?
Это будет неплохая заявка на <a href="<page gui/index>">Tor GUI соревнование</a>.

</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>Мы часто слышим что пользователи Tor могут стать жертвами атак против
анонимности, если не отключат JavaScript, Java, ActiveX, Flash, итд. Существуют
ли какие-нибудь плагины (как например NoScript для Firefox), которые помогут
пользователям управлять этим риском. Какие точно риски с этой стороны?</li>
<li>Существует ли набор плагинов который может полностью заменить Privoxy для
Firefox 1.5+? Мы слышали что Tor работает намного быстрее, если не использовать
Privoxy при этом.</li>
<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>
<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.</li>
<li>Так как Tor сохраняет в памяти каждую ячейку (cell) для обработки,
высоко-скоростные сервера потребляют много памяти, просто для сохранения всех
этих буферов. Нам нужно улучшить эвристический алгоритм, который определяет
когда сжимать/расширять буферы. Может быть стоит использовать концепцию из ядра
Linux, где много маленьких буферов ссылаются на друг друга, вместо того
чтобы использовать монолитные буферы?</li>
<li>Нам нужен официальный центральный сайт для ответа на вопрос "Принадлежит ли данный
IP адрес выходящему узлу сети Tor?". Этот ресурс должен быть доступным по нескольким
интерфейсам, включая веб и DNSBL. Ответы могут быть наиболее точными основываясь
на локальной копии информации о директориях Tor. Дополнительный нюанс
заключается в том что определение exit-сервера зависит от адреса наблюдателя:
т.е .вопрос на самом деле звучит как "Принадлежит ли данный IP адрес серверу
сети Tor который может направлять соединения на мой IP адрес:порт?". DNSBL
интерфейс будет скорее всего получать сотни запросов в минуту, поэтому
потребуются какие-нибудь умные алгоритмы. Также было бы лучше проводить активное
тестирование на проверку IP адреса с которого на самом деле выходят соединения.
<a href="<svnsandbox>doc/contrib/torbl-design.txt">Прочитайте больше</a>.</li>
<li>Иногда случается что сервера Tor аварийно завершают работу, или компьютеры
теряют сетевое соединение, или происходит ещё что-нибудь непредвиденное.
Некоторые из операторов серверов Tor заинтересованы в сервисе "уведомлений"
который бы периодически проверял работу их сервера и присылал бы email в
случаеего недоступности. Кто-нибудь хочет написать несколько cgi скриптов,
пару веб-страниц, и настроить wget и/или что-то более сложное как например
<a href="http://nagios.org/">Nagios</a> мониторинга? Первая версия могла бы
просто проверять Dir-порт, например просматривая закэшированную информацию из
network-status для указанного IP и порта и запрашивая затем страницу
"/tor/server/authority".</li>
<li>Было бы замечательно иметь LiveCD с последними версиями Tor,
Polipo или Privoxy, Firefox, Gaim+OTR, etc. Тут вырисовываются два вопроса:
во-первых требуется задокументировать всю систему и обосновать выбор средств, чтобы
другие люди могли сложить своё мнение о безопасности этой системы, и во-вторых
надо решить как оперативно обновлять систему, чтобы не превратиться моментально
в устаревший хлам. Неплохо было бы при этом вместится на CD диск меньшего размера.</li>
<li>В связи с LiveCD образом, нам также следует выработать интуитивно безопасный
и хорошо документированный USB образ для Tor и вспомогательных приложений. Самая
тяжёлая часть это выбрать какие настройки наиболее безопасны, задокументировать
этот выбор, и упростить будущую поддержку.</li>
<li>Наш предпочтительный графический фронт-енд для Tor,
а именно <a href="http://vidalia-project.net/">Vidalia</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>Требуется сравнение
<a href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a>
vs <a href="http://www.privoxy.org/">Privoxy</a>. Правда ли что Polipo
значительно быстрее, если не учитывать замедление от использования Tor?
Проявляется ли это одинаково на Linux и Windows? Также, кто портит меньше сайтов
&mdash; Polipo или Privoxy? Как у Polipo с стабильностью, на разных платформах?</li>
<li>Кстати, не хотите ли вы помочь портировать
<a href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> чтобы он
работал стабильно и быстро на Windows?</li>
<li>Нам требуется распределённая система тестирования. У нас есть юнит-тесты,
но не мешало бы написать скрипт который бы запускал тестовую сеть Tor,
использовал её некоторое время, и проверял что хотя бы некоторые её части работают.</li>
<li>Помогите Mike Perry с его библиотекой
<a href="http://tor.eff.org/svn/torflow/">TorFlow</a> (<a href="http://tor.eff.org/svn/torflow/TODO">TODO</a>):
это либа для Python которая использует
<a href="http://tor.eff.org/svn/torctl/doc/howto.txt">протокол контроллера Tor</a>
для построения цепочек указанным способом, с последующим анализом и
измерением скорости с целью выявить аномалии.</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>
<li>Не интересует ничто из вышеперечисленного? Посмотрите
<a href="<svnsandbox>doc/design-paper/roadmap-2007.pdf">Tor development
roadmap</a>, может быть найдёте что-то интересное.</li>
<li>Здесь не перечислена ваша задумка? Возможно она нам всё равно пригодится!
Свяжитесь с нами.</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>

#include <foot.wmi>

tor-webwml.git

Change all wiki.noreply to wiki.torproject