Ошибочное мнение об ошибке в TOR?
Попытка чтения документации, а затем осмысление исходников привели меня к странным мыслям. Выношу это на суд посетителей и Гуру проекта, поскольку я вероятно пропустил что-то важное (особенно в исходниках) и могу ошибаться на пустом месте, то опровергните мои мысли, если конечно смог записать их правильно хотя-бы по русски :)
Исходное: Полученный cell (пакет) c relay payload на стороне OP (клиент) последовательно расшифровывается ключами для каждой из ноды в цепи, и после каждого хопа проверятся на исходные данные. Все сделано в целях приема пакетов от любой ноды в цепи для управления ширины канала.
Чтение исходников (имхо): Но не смотря на учет хопа на котором расшифровали пакет, эти данные не используются для проверки, а лишь для управления окнами посылки(ширина канала).
Домыслы: Предположим что модифицированные exit ноды(c исправленным алгоритмом), не будут шифровать содежимое payload для relay пакетов, при этом структуру самих пакетов будут формировать верной (stream_id, digest, length..). Кроме того оказавшись в середине цепи они же могут проверяя на отсутсвие шифра на содержимом пакетов, так же не шифровать своими сеансовыми ключами их, пропуская дальше по цепи (при этом они не смогут получать sendme пакетов, но в переправленном коде ноды можно как и отказ от шифра и это учесть).
Итог домыслов: Таким образом все входящие пакеты с данными могут оказаться шифрованными лишь entry-node.
Ссылки
[link1] http://tor.eff.org/svn/trunk/doc/spec/tor-spec.txt
Не смогли. Это чтение исходников и спецификаций на Вас так пагубно повлияло? ;-)
OP, Onion Proxy, — это не клиент, а сервер (узел) сети. Практически, это может быть и клиент, но в Вашем контексте речь, как я понял, идёт всё-таки о транслирующих узлах.
Имеете в виду, что трафик, возвращаемый от удалённого хоста последовательно через exit-node, middleman-node и entry-node к клиенту будет зашифрован только последним? А клиент, получивший такой пакет, не сможет определить проблему, поскольку в любом случае получает "луковицу" с одним "слоем" шифрования? Я верно понял ход Ваших мыслей?
Вообще, любопытно. Не хочется перекапывать исходники и спецификации, но у других участников принципиальный возражений нет? Если нет, то переадресую вопрос разработчикам. Мне идея нравится.
В документации транслирующим узлом называют OR, OP обслуживает локальные запросы, вероятно все-таки его можно назвать клиентом.
Идея "ошибки" да сводилась к одному слою луковичного шифрования. Стоило мне записать все мысли и повторно взглянуть на документацию, как все вопросы отпали, приношу извинения за бурю в стакане.
Ошибки такого рода нет. Проверяется поле digest relay пакета, который связан как с ключевым материалом по итогам создания цепи, так и со всеми предыдущими данными от ноды.
Более детально сейчас перечитываю документацию, и гляжу исходники. :)
Если я правильно понимаю, клиент (на машине пользователя) строит цепочку и формирует многослойную "луковицу" для посылки этой цепочке. По пути onion-рутеры её последовательно "раздевают", а ответ на обратном пути опять "одевают". Таким образом, получив однослойную "луковицу", клиент распознает нарушение.
Чтобы «одеть» в обратном направлении нужно exit-nod-у знать всех участников соединения (их ключи), т.е. теряется вся анонимность.
Нет, видать, на обратном пути не одевают: так как в принципе эксит не значет энтри ноду. Наскольок я понимаю, эксит знает тольок миддл, шифрует его ключом и шлёт ему. Мидл знает уже энтри-ноду, шифрует её ключом и шлёт ей, а ту уже – пользователю, шифруя его ключом. Хотя может это и не так реализовано. Можно ещё поверх предположить что эксит нода получает временный ключ юзера и на обратном пути 1-м слоем шифрует пакет публичным ключом юзера а далее – как описано выше. Хот наверняка это не совсем так реализовано.
Onion Router и Onion Proxy. Вы правы, сам спутал.
Exit-node, в отличии от пользовательского клиента, не формирует всю (обратную) "луковицу", а только один её слой. И так поступает каждый рутер в цепочке. А клиенту "обратные"(Kb) ключи становятся известны в процессе построения цепочки (путём расширения её через уже построенную часть).
см. http://tor.eff.org/svn/trunk/doc/spec/tor-spec.txt
PS
Или я чего не понял, или в документации опечатка:
вместо
OP (клиент) ведь снимает слои в обратном порядке, с верхнего (того, который наложен последним, т.е. N) к нижнему (который был наложен первым). Стало быть всё правильно.
Насколько мне удалось понять, в обратном потоке, действительно в целях экономии вычислений Exit-node получает один симметричный сеансовый ключ от клиента, но обратно проходят все стадии ассиметричного расшифрования, последния у клиента.
Exit node или сервер, с которым связывается клиент, в принципе может вносить искусственные задержки в траффик, чтобы его как-то пометить, их даже можно отследить при прохождении обратных пакетов по узлам, проткол ведь интерактивный.
Но чтобы отслеживать все эти всплески траффика нужно быть глобальным наблюдателем с большими ресурсами, от которого tor не защищает. Думаю, что создатели позаботились о том, чтобы все манипуляции злонамеренных узлов были по ресурсоёмкости не ниже затрат на атаки глобального наблюдателя и им подобных.
Но если кому-то удасться выявить практичный способ, как это обойти, тогда это конечно дыра в протоколе.
Дыр в протоколе пока не нашли, но имхо слабость тора в очень малом количестве его узлов в сети.
Для реально атаки требуестся модифицировать тор сервер так, чтобы он каким либо образом помещал в пакеты исходящих соединений пометку о источнике соответствующих им входящих соединений. Если свободных полей в протоколе не найдется, то можно эту информацию передавать на следующий узел в отдельном соединении. Далее, выводим в сеть тысяч пять таких модифицированых серверов, и получаем от них логи о всей цепочке по которой шло соединение.
Вероятность успешной атаки очень велика, так как большая часть серверов в сети будут злоумышлеными.
З. Ы. чтобы резкое увеличение числа TOR серверов не вызвало подозрений, рекомендую вводить их очень постепенно, в течении длительного времени.
Это вряд ли, так как нумерация (в параграфе 5.3 документа[link1]) идёт от клиента к exit-node:
Конечно, можно считать и от конца (однако было бы неудобно расширять цепочку), но хочется единообразия хотя-бы в пределах одного документа. Впрочем, это всё мелочи.
Ну и зачем такие сложности с передачей этой информации по цепочке – просто вести лог и собирать его на одном сервере.
Вообще атака очевидная и известная.
Возникнут серьезные проблемы с приемом и обработкой гигабайт совершенно ненужных логов. Поэтому нужно задачу отслеживания цепочек возложить на сами TOR узлы.
Теже самые сценарии ходили в своё время про ремэйлеры. Кстати по этой причине сеть ремэйлеров Mixminion так и не развивается – слишком мало узлов.
Давно пора Mixminion сделать скрытым сервисом Tor!