РегистрацияПрошу объяснить о Торе
Здравствуйте, уважаемые. Как я понял, входящие пакеты расшифровываются с первой ноды и приходят ко мне уже в незашифрованном виде. Неужели мой провайдер никак не увидит эти уже расшифрованные пакеты и тем самым не может определить их содержимое?
комментариев: 9796 документов: 488 редакций: 5664
Там рассматривается алгоритм оптимизированного выбора между своими (доверенными) и враждебными узлами. От заведомо враждебных узлов не отказываются.
При выборе учитывается не просто количество узлов, но и удельный вес по пропускной способности. Вопрос обсуждался где-то в районе /comment27294, /comment27370, /comment42879.
Плюс еще такое соображение: это наблюдение ничего не стоит, можно поставить сервера-шпионы и забыть. Если, допустим, за сутки деанонимизируется 1% посетителей наблюдаемого ресурса (pgpru.com, например), то за 300 дней... Было бы странно, если бы это не делалось.
Например нода kasperskytor01 одна из самых высокоскоростных.
Я уже понял что содержательного ответа на те два вопроса не будет. Поэтому просто напишу здесь ещё некоторые соображения, может кто прокомментирует. На них наводит вышеупомянутая нода, которая обладает очень высокой скоростью. Вряд ли касперский и компания держат её для повышения нашей анонимности, учитывая что торбраузер распознаётся как malware в их антивирусной программе. Скорей всего это злонамеренный узел для сбора статистики. Видимо преследует две цели – нахождение брижей для возможной блокировки в будущем и раскрытие анонимности. Он не является экситом, поэтому в основном работает как мидл. Теоретически это позволяет полностью раскрыть цепочку, если он находится в сговоре с государством контролирующим трафик (в случае касперского очевидно что это так, поскольку он кегебист). Гард и эксит могут располагаться где угодно, главное чтобы посередине цепи оказался этот узел. Трафик ищущий на гард и идущий с эксита (если целевой сайт находится в государстве) контролируются системой слежения. В принципе весь Tor-трафик на магистральном уровне можно направлять на специализировнные сервера статистики. Список узлов Tor известен, в пакетах идущих на/с них модифицируется поле Options в заголовке IP и указывается маршрут проходящий через эти сервера. Так можно создать единый центр мониторинга всех пользователей Tor внутри страны. Если это делать только для TCP-пакетов, то с помощью traceroute не обнаружить, т.к. он работает по ICMP. Сервера Tor-статистики имеют связи: пользователь-гард и эксит-сайт. Злонамерный мидл имеет проходящие через него связи: гард-эксит. Путём сложения этих данных, получается полная информация для вычисления цепи: пользователь-гард-эксит-сайт. Таким образом, для деанонимизации нужно
1. Цепочка проходит через злонамеренную мидл-ноду. Рано или поздно это случается с каждым пользователем, высокая пропускная способность ускоряет процесс.
2. Интернет-ресурс находится внутри государства, с которым нода сотрудничает. В данном случае это очевидно Россия.
Этот способ дополняет тот, что описан выше.
Увеличение длины цепочки до 4 узлов снижает эффективность этих двух способов на порядки.
А еще было бы здорово, если б Tor генерировал рандомный шумовой трафик. Количество помех не снижает уровень сигнала, в данном случае, плюс есть корреляция по времени запроса. То есть математически / статистически информация всё равно поддается анализу, но задача усложняется, а при нерегулярных соединениях с одного IP не решается.
Значит и есть эксит — узел который транслирует не только тор траффик. Не смотрите на флаг эксит из статистики, необходимый только для балансировки трафика. Эксит флаг как маркер, "берегите меня" и если экситов мало тогда исключите из гвардов и прочее. Для получения флага нужно разрешить как минимум 2 из 3 портов (80, 443, 6667) на как минимум /8 подсеть.
Можно подробностей? Разработчики всегда беспокоятся об таких ложных срабатываниях. До сих пор при проверке на virustotal не было срабатываний.
Tor не поддерживает ICMP.
Не «ещё и», а «только». Минусы такого решения уже были озвучены другими участниками.
Guard-узлы меняются раз в 2 месяца. Вы всегда можете посмотреть, какие были выбраны, и если не нравится, принудительно сменить. Когда был выбран нужный вам набор, соединение со всеми остальными узлами можно отключить посредством firewall'а.
Можно. Это, кстати, самый практичный способ.
Только не забывайте, что всё это пока что чистая теория с массой экстраполяций. Через каждый узел проходят десятки, если не сотни, соединений, в норме каждые 15 минут меняются цепочки. И никто заранее не скажет противнику, какая конкретно цепочка проходит как через его entry-, так и exit-ноду. Если противник будет активно влиять на трафик в попытке это отследить, он, подозреваю, как минимум, спалится, и, как максимум, превратится в настолько нестабильный и глючный узел, что через него толком ничего идти не будет. Часто бывает, что когда сеть начинает глючить, делаешь pkill -1 `pidof tor` и забываешь. А вдруг это вот такие «умные» узлы?
Кажется, были новости на эту тему, в которых было сказано, что покрывающий трафик сильно понизит пропускную способность, но даст сомнительную выгоду для анонимности. Сходу не гуглится (unknown бы лучше подсказал), но что-то обсуждалось здесь: [1], [2].
Unknown привёл конкретные ссылки с жаркими дискуссиями прошлых лет на эту тему. Никто не обязан за вас перечитывать все эти топики по 10-ому разу, чтобы найти конкретный пост-ответ на ваши вопросы. Всё, что вы предлагаете, лежит на поверхности, и обсуждалось уже миллион раз. Кроме того, судя по вашей манере (см. выше) делать выводы, к грамотному анализу вы вообще неспособны.
Для начала, чем длиннее цепочка, тем больше вероятность, что хотя бы часть вашего трафика пройдёт через узлы противника. Последнее облегачает ему атаку на деанонимизацию. Есть и много других атак, которые облегчаются. Есть те, которые усложняются. На предмет золотой середины сказано, кажется, даже в Tor-faq, с объяснением, почему взяли именно 3 для данных размеров сети. Можете доказанно опровергнуть — пишите исследовательскую статью.
Если б всё было так просто, как у диванных теоретиков, компартия Китая, как и Иран, не стояли бы раком от Tor'а и не блокировали бы его. Даже у АНБ далеко продвинуться не получилось, из-за чего они сосредоточились на атаках на браузер как самых перспективных.
Ссылка Хотя возможно по вине пользователя. Не вникал, т.к. не пользуюсь антивирусом.
В Tor FAQ приводится ещё два недостатка, кроме дополнительной нагрузки на канал. Это необходимость поддерживать шум круглосуточно от пользователя до сервера (за Tor), что обычно не поддерживается последним. А также уязвимость к отслеживанию реакции при активной блокировке трафика.
Против описанного выше способа нахождения связей зашумление не поможет.
Нет никакой теории, одна реализация. Если добавить подробностей, может сойти за проект ТЗ. Вы очевидно не поняли сути, это статистическая атака, которая за определённое время гарантирует раскрытие анонимности. Всего нод около 8 тысяч, высокоскоростных с большим приоритетом на порядок меньше. Предположим что злонамеренная нода с толстым каналом попадается с вероятностью 1/1000. Нужно вычислить пользователя который активно пользуется сайтом в контролируемой зоне (ru). Если за день он заходит на сайт несколько раз, то вычисляется в течение года. Когда таких нод десяток, он вычисляется в течение месяца.
Достаточно сохранять логи связей в одну базу данных. Для поиска задать интервал времени и веб-ресурс, чтобы получить список связей которые совпали и образовали целую цепочку.
В России сейчас 90 тысяч пользователей Tor, это уровень одного Интернет-провайдера крупного города. При этом для поддержания такой системы не нужны техподдержка и дорогое оборудование, т.к. нет NAT-ов, DNS и прочего, что требовало бы больших ресурсов. Поднять десяток нод в разных странах это вообще копейки.
Модификация IP-пакетов – стандартное действие для любого маршрутизатора. На каждом хопе меняется TTL. Запись нужного IP-адреса в поле Options аналогична, тоже производится на уровне IP и дополнительной нагрузки почти не создаёт. Это просто корректировка маршрута, пакет на пути к Tor-ноде должен пройти через узел с заданным IP-адресом. Для пользователя совершенно незаметно.
Практически любой ответ можно сформулировать в двух-трёх предложениях. Если нельзя, значит человек сам его не знает. В незнании нет ничего зазорного, но упёртость при отсутствии аргументов достойна лучшего применения.
Трафик любого пользователя пойдёт через злонамеренные узлы, независимо от длины цепочки, это лишь вопрос времени. Вероятность попадания противника в короткую цепочку меньше, но и возможности по раскрытию анонимности выше. Попадание в длинную цепочку вероятней, но воспользоваться этой позицией сложнее, нужно совпадение других обстоятельств. В результате, удлинение цепочки ускоряет момент прохождения трафика через враждебную ноду, но снижает её эффективность. Снижение эффективности связано с расположением нод и комбинаторикой, поэтому определяется по-видимому степенной зависимостью. Уменьшение времени почти линейно по длине цепочки, если процент злонамеренных нод невелик. Так что скорей всего при удлинении цепочки вероятность попадания враждебной ноды растёт слабей, чем убывает её эффективность. В итоге, для совпадения всех факторов, необходимых для раскрытия анонимности, нужно намного дольше ждать, несмотря на то, что злонамеренные ноды в длинной цепочке попадаются чаще. Всё это эвристические рассуждения, оценки нужно делать для конкретных атак. Для способа, изложенного выше, удлинение цепочки всего на одну ноду сильно снижает его эффективность.
Недостаточно. TCP-сессия каждый раз пересоздаётся на новом узле, нет никакого сквозного доступного противнику TCP-потока. Даже если у противника есть подконтрольный guard и exit, через которые в данный момент идёт цепочка пользователя, ему, чтобы убедиться в этом, надо делать активную атаку пересечения или модуляции трафика. Конечно, если он заранее знает, какие из межнодовых TCP-потоков принадлежат одной и той же цепочке, он таким вмешательством может легко и доказательно подтвердить гипотезу. А если не знает? Тогда ему придётся вмешиваться во все цепочки. Далее см. вышеозвученные аргументы.
Да пусть пакет идёт хоть через астрал между нодами, что толку-то? Все ваши модификации над пакетом будут тут же сняты миддлманом. Единственное, что не снимается — временные задержки и модуляция полосы пропускания.
Вопрос об оптимальном количестве нод в цепочках (с учётом всех возможных атак) сложный. Это утверждение полутривиально, потому что до сих пор вроде как нет всестороннего описания всех возможных атак и объяснения, какие из них эффективнее других. К тому же, могут быть несколько разные модели противника, и то, что сравнительно легко сделать одному, может оказаться практически нереальным для другого. Соответственно, от того, каких противников вы сочтёте более опасными для вас, зависит, защита от каких конкретно атак для вас более приоритетна.
То, что Tor принципиально выносит некоторые из своих известных слабостей за скобки — известный факт. К примеру, сейчас нет ни одной сети с защитой от глобального наблюдателя, даже Freenet не попадает в эту категорию [1], [2]. Зная всё это, разработчики Tor требуют конкретной исследовательской работы, а не «эвристических соображений». Однако, исходя из своих «эвристических соображений» они взяли число 3 как более-менее оптимальное. Возможно, за этим когда-то стояли простые расчёты и «пальцевые» соображения. А теперь приходит Гость (09/06/2014 19:22) и говорит, что всё просто, ничего исследовать не надо, а оптимальность более длинных цепочек очевидна. Кто не согласен, пусть доказывает. Но, извините, тяжесть доказательства (а не общих рассуждений) лежит на том, кто предлагает.
- GAdv → M → Eother
- Gother → M → EAdv
- GAdv → M → EAdv
Guard GAdv и exit EAdv принадлежат противнику (adversary), миддлман M ему неподконтролен. Как последнему отличить случай 3 (для него полезный) от случаев 1 и 2?Т.е. противнику.
C_ru — IPstat — G — M_adv — E — IPstat — S_ru
C_ru и S_ru – клиент и конечный сервер в контролируемой зоне (например ru), IPstat адрес через который идут IP-пакеты в Tor и из него. G и E – гард и эксит (любые), M_adv – враждебный мидл.
Для всех пакетов с IPdst = G и IPsrc = E (все ноды известны) корректируется маршрут через IPstat, с которого собирается статистика по связям.
На IPstat логируются связи C_ru — G и E — S_ru. На M_adv связи G — M_adv и M_adv — E. Эти логи объединяются в базе данных.
Количество нод 8000, возможных цепочек 8000^3 = полмиллиарда. Каждый из 2.5 миллиона пользователей Tor имеет уникальную цепочку в каждый момент времени. Всё цепочки, проходящие через M_adv вычисляются.
Видимо речь идёт о первом способе, описанном в comment80465 и выше.
C_ru — IPstat — G_ru — IPstat — M — IPstat — E_ru — IPstat — S
G_ru и E_ru – гард и эксит в контролируемой зоне, где и IPstat. M – любой мидл, S – любой сервер. На IPstat собираются все связи. В отличие от 1-го способа, через IPstat пропускаются все пакеты, связанные с Tor, а не только на/с G/E.
IPany = G и IPany = E, т.к. пакеты ходят в обе стороны. Если смотреть глубже, на уровень TCP, то можно определить направление по SYN-пакетам. Но это потребует дополнительных аппаратных ресурсов. Другой вариант – определять направление первого пакета для рассматриваемой связи, тогда можно ограничиться уровнем IP.