id: Гость   вход   регистрация
текущее время 16:29 29/03/2024
Автор темы: Гость, тема открыта 18/03/2007 14:08 Печать
http://www.pgpru.com/Форум/АнонимностьВИнтернет/ОшибочноеМнениеОбОшибкеВTOR
создать
просмотр
ссылки

Ошибочное мнение об ошибке в TOR?


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


Исходное: Полученный cell (пакет) c relay payload на стороне OP (клиент) последовательно расшифровывается ключами для каждой из ноды в цепи, и после каждого хопа проверятся на исходные данные. Все сделано в целях приема пакетов от любой ноды в цепи для управления ширины канала.


Чтение исходников (имхо): Но не смотря на учет хопа на котором расшифровали пакет, эти данные не используются для проверки, а лишь для управления окнами посылки(ширина канала).


Домыслы: Предположим что модифицированные exit ноды(c исправленным алгоритмом), не будут шифровать содежимое payload для relay пакетов, при этом структуру самих пакетов будут формировать верной (stream_id, digest, length..). Кроме того оказавшись в середине цепи они же могут проверяя на отсутсвие шифра на содержимом пакетов, так же не шифровать своими сеансовыми ключами их, пропуская дальше по цепи (при этом они не смогут получать sendme пакетов, но в переправленном коде ноды можно как и отказ от шифра и это учесть).


Итог домыслов: Таким образом все входящие пакеты с данными могут оказаться шифрованными лишь entry-node.


 
Комментарии
— SATtva (18/03/2007 14:29)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
если конечно смог записать их правильно хотя-бы по русски :)

Не смогли. Это чтение исходников и спецификаций на Вас так пагубно повлияло? ;-)

на стороне OP (клиент)

OP, Onion Proxy, — это не клиент, а сервер (узел) сети. Практически, это может быть и клиент, но в Вашем контексте речь, как я понял, идёт всё-таки о транслирующих узлах.

Итог домыслов: Таким образом все входящие пакеты с данными могут оказаться шифрованными лишь entry-node.

Имеете в виду, что трафик, возвращаемый от удалённого хоста последовательно через exit-node, middleman-node и entry-node к клиенту будет зашифрован только последним? А клиент, получивший такой пакет, не сможет определить проблему, поскольку в любом случае получает "луковицу" с одним "слоем" шифрования? Я верно понял ход Ваших мыслей?

Вообще, любопытно. Не хочется перекапывать исходники и спецификации, но у других участников принципиальный возражений нет? Если нет, то переадресую вопрос разработчикам. Мне идея нравится.
— Лыжи_асфальт (18/03/2007 15:26)   <#>
В документации транслирующим узлом называют OR, OP обслуживает локальные запросы, вероятно все-таки его можно назвать клиентом.
Идея "ошибки" да сводилась к одному слою луковичного шифрования. Стоило мне записать все мысли и повторно взглянуть на документацию, как все вопросы отпали, приношу извинения за бурю в стакане.
Ошибки такого рода нет. Проверяется поле digest relay пакета, который связан как с ключевым материалом по итогам создания цепи, так и со всеми предыдущими данными от ноды.
Более детально сейчас перечитываю документацию, и гляжу исходники. :)
— Гость (18/03/2007 15:48)   <#>
принципиальный возражений нет?

Если я правильно понимаю, клиент (на машине пользователя) строит цепочку и формирует многослойную "луковицу" для посылки этой цепочке. По пути onion-рутеры её последовательно "раздевают", а ответ на обратном пути опять "одевают". Таким образом, получив однослойную "луковицу", клиент распознает нарушение.
— serzh (18/03/2007 16:13)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
По пути onion-рутеры её последовательно «раздевают», а ответ на обратном пути опять «одевают».

Чтобы «одеть» в обратном направлении нужно exit-nod-у знать всех участников соединения (их ключи), т.е. теряется вся анонимность.
— spinore (18/03/2007 18:09)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Нет, видать, на обратном пути не одевают: так как в принципе эксит не значет энтри ноду. Наскольок я понимаю, эксит знает тольок миддл, шифрует его ключом и шлёт ему. Мидл знает уже энтри-ноду, шифрует её ключом и шлёт ей, а ту уже – пользователю, шифруя его ключом. Хотя может это и не так реализовано. Можно ещё поверх предположить что эксит нода получает временный ключ юзера и на обратном пути 1-м слоем шифрует пакет публичным ключом юзера а далее – как описано выше. Хот наверняка это не совсем так реализовано.
— SATtva (18/03/2007 18:33)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
В документации транслирующим узлом называют OR, OP обслуживает локальные запросы, вероятно все-таки его можно назвать клиентом.

Onion Router и Onion Proxy. Вы правы, сам спутал.
— Гость (18/03/2007 19:46, исправлен 18/03/2007 23:47)   <#>
Exit-node, в отличии от пользовательского клиента, не формирует всю (обратную) "луковицу", а только один её слой. И так поступает каждый рутер в цепочке. А клиенту "обратные"(Kb) ключи становятся известны в процессе построения цепочки (путём расширения её через уже построенную часть).

см. http://tor.eff.org/svn/trunk/doc/spec/tor-spec.txt

5.3. Creating circuits

When creating a circuit through the network, the circuit creator (OP) performs the following steps:

1 Choose an onion router as an exit node (R_N), such that the onion router's exit policy includes at least one pending stream that needs a circuit (if there are any).
2 Choose a chain of (N-1) onion routers (R_1... R_N-1) to constitute the path, such that no router appears in the path twice.
3 If not already connected to the first router in the chain, open a new connection to that router.
4 Choose a circID not already in use on the connection with the first router in the chain; send a CREATE cell along the connection, to be received by the first onion router.
5 Wait until a CREATED cell is received; finish the handshake and extract the forward key Kf_1 and the backward key Kb_1.
6 For each subsequent onion router R (R_2 through R_N), extend the circuit to R.

To extend the circuit by a single onion router R_M, the OP performs these steps:

1 Create an onion skin, encrypted to R_M's public onion key.
2 Send the onion skin in a relay EXTEND cell along the circuit (see section 5).
3 When a relay EXTENDED cell is received, verify KH, and calculate the shared keys. The circuit is now extended.

When an onion router receives an EXTEND relay cell, it sends a CREATE cell to the next onion router, with the enclosed onion skin as its payload. The initiating onion router chooses some circID not yet used on the connection between the two onion routers.

When an onion router receives a CREATE cell, if it already has a circuit on the given connection with the given circID, it drops the cell. Otherwise, after receiving the CREATE cell, it completes the DH handshake, and replies with a CREATED cell. Upon receiving a CREATED cell, an onion router packs it payload into an EXTENDED relay cell (see section 5), and sends that cell up the circuit. Upon receiving the EXTENDED relay cell, the OP can retrieve g^y.


When a relay cell arrives at an OP, the OP decrypts the payload with the stream cipher as follows:
OP receives data cell:
For I=N...1,
Decrypt with Kb_I.

PS
Или я чего не понял, или в документации опечатка:
вместо
"For I=N...1 Decrypt with Kb_I"
следует написать
"For I=1.. N Decrypt with Kb_I"
— SATtva (19/03/2007 00:05)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Или я чего не понял, или в документации опечатка:

OP (клиент) ведь снимает слои в обратном порядке, с верхнего (того, который наложен последним, т.е. N) к нижнему (который был наложен первым). Стало быть всё правильно.
— unknown (19/03/2007 09:11, исправлен 19/03/2007 09:12)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Насколько мне удалось понять, в обратном потоке, действительно в целях экономии вычислений Exit-node получает один симметричный сеансовый ключ от клиента, но обратно проходят все стадии ассиметричного расшифрования, последния у клиента.

Exit node или сервер, с которым связывается клиент, в принципе может вносить искусственные задержки в траффик, чтобы его как-то пометить, их даже можно отследить при прохождении обратных пакетов по узлам, проткол ведь интерактивный.

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

Но если кому-то удасться выявить практичный способ, как это обойти, тогда это конечно дыра в протоколе.
— dfwe (20/03/2007 02:11)   <#>
Дыр в протоколе пока не нашли, но имхо слабость тора в очень малом количестве его узлов в сети.
Для реально атаки требуестся модифицировать тор сервер так, чтобы он каким либо образом помещал в пакеты исходящих соединений пометку о источнике соответствующих им входящих соединений. Если свободных полей в протоколе не найдется, то можно эту информацию передавать на следующий узел в отдельном соединении. Далее, выводим в сеть тысяч пять таких модифицированых серверов, и получаем от них логи о всей цепочке по которой шло соединение.
Вероятность успешной атаки очень велика, так как большая часть серверов в сети будут злоумышлеными.

З. Ы. чтобы резкое увеличение числа TOR серверов не вызвало подозрений, рекомендую вводить их очень постепенно, в течении длительного времени.
— Гость (20/03/2007 17:33)   <#>
Стало быть всё правильно.

Это вряд ли, так как нумерация (в параграфе 5.3 документа) идёт от клиента к exit-node:

exit node (R_N)


Конечно, можно считать и от конца (однако было бы неудобно расширять цепочку), но хочется единообразия хотя-бы в пределах одного документа. Впрочем, это всё мелочи.
— ygrek (20/03/2007 18:58)   профиль/связь   <#>
комментариев: 98   документов: 8   редакций: 10
Для реально атаки требуестся модифицировать тор сервер так, чтобы он каким либо образом помещал в пакеты исходящих соединений пометку о источнике соответствующих им входящих соединений. Если свободных полей в протоколе не найдется, то можно эту информацию передавать на следующий узел в отдельном соединении. Далее, выводим в сеть тысяч пять таких модифицированых серверов, и получаем от них логи о всей цепочке по которой шло соединение.
Вероятность успешной атаки очень велика, так как большая часть серверов в сети будут злоумышлеными.

Ну и зачем такие сложности с передачей этой информации по цепочке – просто вести лог и собирать его на одном сервере.
Вообще атака очевидная и известная.
— guest (21/03/2007 05:04)   <#>

Возникнут серьезные проблемы с приемом и обработкой гигабайт совершенно ненужных логов. Поэтому нужно задачу отслеживания цепочек возложить на сами TOR узлы.
— unknown (21/03/2007 09:16)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Теже самые сценарии ходили в своё время про ремэйлеры. Кстати по этой причине сеть ремэйлеров Mixminion так и не развивается – слишком мало узлов.
— Гость (21/03/2007 12:21)   <#>
Давно пора Mixminion сделать скрытым сервисом Tor!
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3