Русскоязычное сообщество TOR
Уважаемые Гуру и посетители, имею предложить организоваться в русскоязычное комьюнити TOR в рамках данного проекта (этого раздела), которое будет по русски разбирать полеты TOR. Обсуждать найденные неточности в коде и возможно алгоритме(а вдруг), и на чистом английском, технически верном, делиться с создателями TOR и англоязычной общественностью в почтовой рассылке.
Например, если не ошибаюсь то местный участник ygrek, осуществляет перевод веб документации на русский язык в рамках TOR сообщества.
Как бы там ни было, хочу поделиться самой свежей особенностью нового релиза (ранее такого не наблюдал): корневая нода dizum "отдыхает" более суток, в связи с этим клиент считает своим долгом каждую минуту выкачивать ее network-status по 100КБ.
Трафик не так критичен, но сама постановка вопроса заставляет подумать. К тому же клиент перестал скачивать более свежие статусы других корневых нод, по сколько в его 30 минутном таймере проверяется дата файлов(хотя и пишет в лог: router_set_networkstatus(): Not replacing network-status from directory server "dizum", но файл обновляет), а не публикаций статусов. Стоит пойти отдохнуть еще двоим, и клиент просто перестанет строить цепочки.
Есть еще несколько мелких штрихов к портрету, которые в текущей форме донести до авторов самостоятельно не имею возможности, из-за небольшого языкового барьерчика, и не всегда ясной формой выражения мыслей :)
Надеюсь предложение по сообществу будет поддержано, и главное в этом возможность вещать мысли и замечания авторам TOR, на понятном для них языке, на постоянной основе :)
комментариев: 1515 документов: 44 редакций: 5786
На английский я бы мог перевести, да не соображаю в предмете. А как так получилось,
что вы разбираетесь в коде, а в английском – нет? Обычно программисты хорошо
владеют техническим программистским английским. Надо писать в рассылку и спрашивать –
под лежачий камень вода не течёт. Думаю, если вы связно изложите суть проблемы
в готовом письме на русском, я или кто-либо другой переведёт на английский и вы
сможете послать разработчикам.
комментариев: 11558 документов: 1036 редакций: 4118
Точно, это проблемой не станет. Труднее, как правило, собрать чужие разрозненные мысли воедино, для этого нужно по меньшей мере пройти тем же путём, что и автор идеи.
комментариев: 98 документов: 8 редакций: 10
ЗЫ Its Tor, not TOR! :)
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 11558 документов: 1036 редакций: 4118
"dizum" и раньше падал, чего не скажешь о других authority.
И немного не по теме, вечерние мысли; хотя может это об идее сообщества. Отчего-то в рунете(кроме этого проекта) о Tor отзываются в лучшем случае как болото, если конечно имеется ввиду скорость, чаще "ловушка" и прочие красивые эпитеты, голосов людей которые для начала просто прочитали документацию, или больше – глянули код, за этим ором почти не слышно.
комментариев: 1515 документов: 44 редакций: 5786
технические. Проект пытается максимизировать анонимность исходя из доступных
реалий. Ясно, что это не абсолютная анонимность... Но никто это и не утверждал.
Однако, это анонимность существенно не плохого уровня. Я не исключаю что сейчас
втихушку террористами ведутся работы по дискредитации анонимности серверов тор,
а узнаем мы об этом не ранее чем из новостей когда захапают кучу народа
сидевших за тором.
Параллельно могу от себя добавить: дефолтное состояние тора таково что слишком
часто мои запросы идут через малое число эксит-узлов. Скажем, не через 100
а всего-лишь через 20 может быть (надо бы пособирать статистику и опубликовать).
Это я к тому что часть айпишников эксит-нод уже запоминаются :-) => легко строить
портрет пользователя сидя за рулём на эксит-ноде.
комментариев: 1515 документов: 44 редакций: 5786
слегка странновато выглядит:
P. S.: поотом если перезапустить, то уже всё нормально. Удивительно, что мусора много в ошибке...
комментариев: 11558 документов: 1036 редакций: 4118
Господа, будьте столь любезны: если цитируете какой-то лог, окружайте его с двух стороны двойными знаками процента — %%. Не заставляйте делать всё за вас.
[/moderator]
Exit-node не знает, чей трафик транслирует (если только не суёте через него куки и т.п. ерунду). Если первые два узла всякий раз разные, то можно при желании вообще постоянно через один экзит ходить (но всё же это не руководство к действию).
комментариев: 1515 документов: 44 редакций: 5786
без этого многие сайты не будут работать, а потому приходится...
Проблема по моему, на стороне DIR сервера, сейчас на заявленном порту крутится апач: "Server: Apache/1.3.29 (Unix) mod_ssl/2.8.16 OpenSSL/0.9.7j"
На запрошенные дескрипторы отвечает 403, если GET запрос слишком велик, но в целом там 404. Возможно владелец ноды в стадии создании веб сервера.
Насчет экзитов, есть такое дело, алгоритм выбора заточен под более вероятностный выбор экзитом, ноды с наибольшей пропускной способностью. К томуже слабо охвачены алгоритмом, крайние ноды из выбираемого списка, но тут до конца не буду утверждать – всего лишь эксперементы на практике.
Опять же в новом релизе уменьшили вероятность выбора ноды которая exit под middle или guard, увеличив для конкретной цепочки список выбираемых экзитов. В целом в настоящее время экзит-нод более 300.
Неверная мысль, однако :) Ничего не увеличивается.
В любом случае строительство цепи начинается с выбора exit, при этом не важно в каких цепочках уже участвует выбранная нода, все зависит лишь от exit-policy.
Все многоходовые арифметические операции по исключению из промежуточных нод экзитов возможно направлены на повышение анонимности, поскольку уменьшается вероятность с одной ноды участвующей в разных цепях выходить и просто транслировать транзитный шифрованный трафик. Только не понятно как смешивания трафиков от разных цепей от одного клиента на одной ноде может помочь установить меж ними взаимосвязь?
Или для разгрузки экзитов от транзитного трафика в глобальном Tor масштабе, тогда это наверняка снизит анонимность. Tor получается некой трубой когда хорошо предопределены вход, и не менее обрисован выход? Тогда как раньше все было больше похоже на сито?
комментариев: 9796 документов: 488 редакций: 5664
– Stop overloading exit nodes — avoid choosing them for entry or middle hops when the total bandwidth available from non-exit nodes is much higher than the total bandwidth available from exit nodes.
Их мало, их надо беречь, на них и так нагрузка больше. А снизит ли это анонимность? Ну наверное какой-то компромисс между скоростью и анонимностью соблюдается. То что мало входов и мало выходов это издержки концепции, И принудительно тут ситуацию менять нет смысла. Легко запустить промежуточный сервер, сложнее решиться на входящий, ещё сложнее на исходящий. То же примерно наблюдается в сетях римэйлеров.
комментариев: 9796 документов: 488 редакций: 5664
Скорее на множество перепутанных между собой лабиринтов. Как в пещерах.
Если уж прибегать к статичным образам.
Думаю больше проблема для экзитов – жалобы на владельца сервера, за все те действия что могут совершить через него. Тогда как общая нагрузка по трафику зависит от заявленной пропускной способности и от exit-policy, устанавливаемых самим владельцем.
Сейчас запустивший сервер и разрешивший выход, а также одновременно использующий функции клиентского прокси, будет одним единственным кто строит исходящие цепи. Если раньше, предположим гипотетически, при раскручивании цепочки(в цепи оказался уязвимый хоп/хопы) вышли бы на владельца сервера, он смог бы заявить что это транзитный трафик(если он выключил createfast).
Пессимистически: основная масса экзитов останется на хостинговых и университетских площадках, этакий jap2 для экзитов :(