длинна цепочек в tor и анонимность

Чтобы эффективно отследить построенные цепочки, нужно записывать время прохождения "клетки" (или для экономии места отдельные их виды), адрес или узел с которого "клетка" получена, ее номер, адрес или узел куда клетка будет направлена, номер который будет ей присвоен. Даже если записывать только события создания и окончания цепочек, это значительный обьем информации (построением цепочек занимается не тысяча и даже не десять тысяч пользователей). Кроме того такого рода логи в Tor _не_ фиксируются вообще, даже в режиме debug. Если предположить, что все операторы серверов массово начали изменять код и записывать, столько в целом не нужной даже для отладки информации, тогда проще не использовать Tor.

Увеличивать длину цепочки даже не с точки зрения атак, не выгодно совершенно, возрастут значительно лаги, упадет скорость (она и при оптимальных 3-ех хопах оставляет желать лучшего). Кроме того прийдется переписывать другие участки кода, с такими задержками клиент работать вообще не сможет.

хм.. "Кроме того такого рода логи в Tor _не_ фиксируются вообще, даже в режиме debug" – вы имеете ввиду что в стандартном обеспечении необходимом для поднятия tor-сервака нет никакой возможности вести логи и для появления этой возможности необходимо изменить код? Честно говоря я никогда не был администратором никакого сервера но все таки мне кажется что для того что бы вести логи даже если такая возможность не встроена в сам tor достаточно установить какую-либо дополнительную утилиту...

"Увеличивать длину цепочки даже не с точки зрения атак, не выгодно совершенно, возрастут значительно лаги, упадет скорость (она и при оптимальных 3-ех хопах оставляет желать лучшего). Кроме того прийдется переписывать другие участки кода, с такими задержками клиент работать вообще не сможет."

Скорость упадет, но с этим можно смирится. А вот насчет переписывания кода и тут я уже ничего не понимаю – ведь возможность выбирать длинну цепочки есть безо всякого изменения кода?

ведь возможность выбирать длинну цепочки есть безо всякого изменения кода?

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

В Tor имеется достаточно продуманная система логирования событий, просто для того чтобы выявить неисправности не нужно всего того что надо для отслеживания цепочек. Кстати немного хочу огорчить, сейчас глянул предметно, в режиме debug пишут к примеру откуда поступил запрос на создание цепи (клетка create), можно если постараться найти процесс расширения цепи через узел (клетка extend), только все это безсистемно и нет записей о прямой взаимосвязи с расширенной цепочкой и узлом от которого эта команда была получена. Примерно так-же дело обстоит с экзит узлами, нет системы между фиксированием открытия соеденения на веб узел (например) и цепочкой. Чтобы получить внятные логи, по которым возможно связать события, нужно вмешательство в код. Операторам нет необходимости включать режим отладки(который даже у клиента создает мегабайты логов, при практическом бездействии), имеющихся уровней логирования достаточно для обнаружения неполадок.

Вообщем советую Вам запустить свой сервер включить логи на уровень debug, и потом попробывать найти взаимосвязи в цепочках, и сказать кто куда и что строит.

Впрочем все вышесказаное не отменяет наличие также хорошего механизма получения статистики, где так же можно получить всю исчерпывающую информацию, но этот процесс одноразовый и не ставит целью фиксировать процессы создания и уничтожения цепей.

Длина цепочки в клиенте неизменна, и константой зашита в теле Tor (не считая протокола управления, но использующий его вероятно понимает что делает). Самая большая нагрузка у серверов образуется в процессе создания и расширения цепей, всеобщие длинные цепочки негативно сказываются на общую производительность сети.

Лыжи_асфальт, может при наличии времени добавите в FAQ пункт с описанием причин, почему в Tor используются именно 3-звеньевые цепочки, а не более длинные или короткие? Просто чтобы не отвечать на эти вопросы ad infinitum.

Спасибо за ответы. В общем как я понял все строится на предположении что держатели большинства узлов не станут специально делать что-либо (вмешательство в код, впустую занимаемое значительное пространство на жестких и т.п.) для логирования траффика. Для обычных частных лиц это может быть и справедливо, но учитывая что многие узлы держат организации у меня все-таки остаются подозрения. Ведь широко известно например что держатели многих прокси-серверов и анонимайзеров ведут логи...

"Вообщем советую Вам запустить свой сервер включить логи на уровень debug, и потом попробывать найти взаимосвязи в цепочках, и сказать кто куда и что строит."

К сожалению у меня нет широкого анлим канала т.к. иначе я обязательно бы запустил сервер даже не с целью попробовать вести логи а с целью большей анонимности. Установил бы его как промежуточную точку..

Английское слово "cell" в данном контексте лучше переводить как "ячейка" а не "клетка", поскольку в русском языке есть подходящее значение слова ячейка – блок данных неизменной длины, имеющий заголовок и тело.

Говорить о бессмысленности увеличения длины цепочки может быть политически и правильно, так как предотвращает увеличение нагрузки на сеть, однако в реальности такое увеличение уменьшает защищённость от одного вида атаки, но увеличивает защищищённость от другого. А какой тип атаки выберет обладающий значительными ресурсами оппонент, заранее говорить, на мой взгляд, преждевременно.

однако в реальности такое увеличение уменьшает защищённость от одного вида атаки, но увеличивает защищищённость от другого.

От какого типа атаки защищает увеличение длины цепочки в Tor?

Видимо, Гость подразумевает защиту от одновременного лога всеми узлами в цепочке: в этом случае, если противник получит лог всех узлов, это упростит тайминг-атаку. Как я понял логику, если узлов в цепочке будет больше, то при произвольной перестройке цепочек шанс составить такую, в которой все узлы ведут лог, меньше. Только, на мой взгляд, это имеет смысл лишь в том случае, когда изначально логирование включено на значительной части узлов. Мои эвристические оценки с этим не согласуются.

Гость, Вы могли бы подтвердить свою позицию, если бы оценили, какая доля из действующих узлов действительно администрируется организациями, а не частными пользователями (можно проверить по whois-записям для их ip). По-моему, таких узлов как раз меньшинство. Соответственно, удлинение цепочки при таких вводных особой роли не сыграет.

От какого типа атаки защищает увеличение длины цепочки в Tor?

Не защищает, но увеличивает защищённость от ситуации частичной компрометации, то есть наличия некоторого количества "вражеских" серверов, приспособленных или созданных специально с целью ведения логов. Если все сервера в цепочке ведут логи связаны между собой – анонимность раскрыта! Вероятность этого уменьшается с увеличением длины цепочки.

какая доля из действующих узлов действительно администрируется организациями, а не частными пользователями

Если достаточно могущественная организация захочет контролировать сеть Tor, она может подключить к ней значительное число компьютеров с модифиированным Tor'ом и от имени частных пользователей. Например, компания, имеющая 1000 служащих, владеющих компьютерами и подключённых широким безлимитным каналом к интернету (обычное дело в некоторых странах), может директивно приказать своим служащим поставить VPN "фирменной" разработки(тоже обычное дело). :(

да не обязательно что бы все ведущие логи сервера принадлежали одной организации. достаточно что бы они при определенных условиях делились логами.

Если мы решаем увеличивать длину цепочки с целью увеличить защищеность от "пишущих" узлов, то одновременно увеличиваем шанс захватить некоторую часть "взломанных" узлов в нашу цепочку. И еще не известно что более вероятно. Вообщем хотелось бы примерных цифр, сколько выбирать узлов в цепочку, и каковы шансы увеличить защищеность.

Кроме того, много ли будет пользы если вторым и последним в нашей километровой цепочке окажутся узлы "противника". Можно долго петлять по Tor-сети, наращивая звенья на цепочку и повышая шанс "найти" узлы "противника", только зачем. К тому-же при архитектуре сети с охранными узлами, первым узлом (который очень долговечен) может оказаться узел "противника", тогда увеличение цепочки — пустая трата времени. Противнику не интересно глядеть что вы прочитали почту из гугла, он ее тоже прочитал (может чуть раньше :)), поэтому стремиться контролировать обязательно всю цепочку, могут лишь романтики. В остальных случаях "противник" будет контролировать нужный ему ресурс, и часть серверов Tor, это надежней чем ждать пока мы выберем в звенья его сервера. Если Вы считаете что у кого-то есть замысел зафиксировать всю деятельность, подавляющего большинства пользователей Tor, то для этого и число пишущих и контролируемых серверов должно быть подавляющим. Это слишком дорогая атака, и у этого "атакующего" уже есть имя, и способы отследить пользователей без использования подставных серверов.

P. S. чтобы делиться логами, нужно их иметь.

хотелось бы примерных цифр

Чтобы узнать вероятность того, что все сервера в цепочке окажутся скомпрометироваными, нужно долю скомпрометированных серверов возвести в степень равную длине цепочки.
Если в цепочке есть хотя бы один нескомпрометированный сервер, анонимность не нарушается.
Вероятность того, что анонимность не нарушается в каждой из построенных за сеанс цепочек равна дополнению до единицы вероятности того, что все сервера в цепочке окажутся скомпрометироваными, возведённой в степень, равную числу цепочек, построенных за сеанс. :)

Очень спорно, расскажите как повысится анонимность, если в цепочке первым и последним будут находиться узлы противника. И как поможет, в таком случае, множество промежуточных узлов с кристально чистой репутацией. Кстати именно такую модель угрозы (с первым и замыкающим узлами) описывают авторы и исследователи Tor в свои работах. (хотя формула (m/N)^с расчитывает вероятность при случайном выборе из всего числа узлов, тогда как в настоящий момент это не так). Вы описываете несуществующую, по причине не экономичности, модель угрозы.