Ошибочное мнение об ошибке в TOR?
Попытка чтения документации, а затем осмысление исходников привели меня к странным мыслям. Выношу это на суд посетителей и Гуру проекта, поскольку я вероятно пропустил что-то важное (особенно в исходниках) и могу ошибаться на пустом месте, то опровергните мои мысли, если конечно смог записать их правильно хотя-бы по русски :)
Исходное: Полученный cell (пакет) c relay payload на стороне OP (клиент) последовательно расшифровывается ключами для каждой из ноды в цепи, и после каждого хопа проверятся на исходные данные. Все сделано в целях приема пакетов от любой ноды в цепи для управления ширины канала.
Чтение исходников (имхо): Но не смотря на учет хопа на котором расшифровали пакет, эти данные не используются для проверки, а лишь для управления окнами посылки(ширина канала).
Домыслы: Предположим что модифицированные exit ноды(c исправленным алгоритмом), не будут шифровать содежимое payload для relay пакетов, при этом структуру самих пакетов будут формировать верной (stream_id, digest, length..). Кроме того оказавшись в середине цепи они же могут проверяя на отсутсвие шифра на содержимом пакетов, так же не шифровать своими сеансовыми ключами их, пропуская дальше по цепи (при этом они не смогут получать sendme пакетов, но в переправленном коде ноды можно как и отказ от шифра и это учесть).
Итог домыслов: Таким образом все входящие пакеты с данными могут оказаться шифрованными лишь entry-node.
комментариев: 11558 документов: 1036 редакций: 4118
Не смогли. Это чтение исходников и спецификаций на Вас так пагубно повлияло? ;-)
OP, Onion Proxy, — это не клиент, а сервер (узел) сети. Практически, это может быть и клиент, но в Вашем контексте речь, как я понял, идёт всё-таки о транслирующих узлах.
Имеете в виду, что трафик, возвращаемый от удалённого хоста последовательно через exit-node, middleman-node и entry-node к клиенту будет зашифрован только последним? А клиент, получивший такой пакет, не сможет определить проблему, поскольку в любом случае получает "луковицу" с одним "слоем" шифрования? Я верно понял ход Ваших мыслей?
Вообще, любопытно. Не хочется перекапывать исходники и спецификации, но у других участников принципиальный возражений нет? Если нет, то переадресую вопрос разработчикам. Мне идея нравится.
Идея "ошибки" да сводилась к одному слою луковичного шифрования. Стоило мне записать все мысли и повторно взглянуть на документацию, как все вопросы отпали, приношу извинения за бурю в стакане.
Ошибки такого рода нет. Проверяется поле digest relay пакета, который связан как с ключевым материалом по итогам создания цепи, так и со всеми предыдущими данными от ноды.
Более детально сейчас перечитываю документацию, и гляжу исходники. :)
Если я правильно понимаю, клиент (на машине пользователя) строит цепочку и формирует многослойную "луковицу" для посылки этой цепочке. По пути onion-рутеры её последовательно "раздевают", а ответ на обратном пути опять "одевают". Таким образом, получив однослойную "луковицу", клиент распознает нарушение.
комментариев: 232 документов: 17 редакций: 99
Чтобы «одеть» в обратном направлении нужно exit-nod-у знать всех участников соединения (их ключи), т.е. теряется вся анонимность.
комментариев: 1515 документов: 44 редакций: 5786
комментариев: 11558 документов: 1036 редакций: 4118
Onion Router и Onion Proxy. Вы правы, сам спутал.
см. http://tor.eff.org/svn/trunk/doc/spec/tor-spec.txt
PS
Или я чего не понял, или в документации опечатка:
вместо
комментариев: 11558 документов: 1036 редакций: 4118
OP (клиент) ведь снимает слои в обратном порядке, с верхнего (того, который наложен последним, т.е. N) к нижнему (который был наложен первым). Стало быть всё правильно.
комментариев: 9796 документов: 488 редакций: 5664
Exit node или сервер, с которым связывается клиент, в принципе может вносить искусственные задержки в траффик, чтобы его как-то пометить, их даже можно отследить при прохождении обратных пакетов по узлам, проткол ведь интерактивный.
Но чтобы отслеживать все эти всплески траффика нужно быть глобальным наблюдателем с большими ресурсами, от которого tor не защищает. Думаю, что создатели позаботились о том, чтобы все манипуляции злонамеренных узлов были по ресурсоёмкости не ниже затрат на атаки глобального наблюдателя и им подобных.
Но если кому-то удасться выявить практичный способ, как это обойти, тогда это конечно дыра в протоколе.
Для реально атаки требуестся модифицировать тор сервер так, чтобы он каким либо образом помещал в пакеты исходящих соединений пометку о источнике соответствующих им входящих соединений. Если свободных полей в протоколе не найдется, то можно эту информацию передавать на следующий узел в отдельном соединении. Далее, выводим в сеть тысяч пять таких модифицированых серверов, и получаем от них логи о всей цепочке по которой шло соединение.
Вероятность успешной атаки очень велика, так как большая часть серверов в сети будут злоумышлеными.
З. Ы. чтобы резкое увеличение числа TOR серверов не вызвало подозрений, рекомендую вводить их очень постепенно, в течении длительного времени.
Это вряд ли, так как нумерация (в параграфе 5.3 документа) идёт от клиента к exit-node:
Конечно, можно считать и от конца (однако было бы неудобно расширять цепочку), но хочется единообразия хотя-бы в пределах одного документа. Впрочем, это всё мелочи.
комментариев: 98 документов: 8 редакций: 10
Ну и зачем такие сложности с передачей этой информации по цепочке – просто вести лог и собирать его на одном сервере.
Вообще атака очевидная и известная.
Возникнут серьезные проблемы с приемом и обработкой гигабайт совершенно ненужных логов. Поэтому нужно задачу отслеживания цепочек возложить на сами TOR узлы.
комментариев: 9796 документов: 488 редакций: 5664