id: Гость   вход   регистрация
текущее время 19:28 02/05/2024
Автор темы: Гость, тема открыта 25/02/2008 00:28 Печать
Категории: анонимность
https://www.pgpru.com/Форум/АнонимностьВИнтернет/ПодозрительнаяИнформацияОДеанонимизацииТор
создать
просмотр
ссылки

Подозрительная информация о деанонимизации тор

По ряду каналов пришла следующая инфа (реконструирую диалог и убираю несущественные детали):


СВИДЕТЕЛЬ: Я так понял – подсоединялся он прямо у провайдера, не со стороны (приходил к прову со своим лэптопом)


СВИДЕТЕЛЬ: Видели следующее. Человек пришел к провайдеру, подсоединился со своего ноута через тор к нему, и
в течение пары секунд программа выдала всю цепочку нод и конечный айпи


СПРАШИВАЮЩИЙ: Нужно хотя бы точно сказать что он видел, что конкретно?
СВИДЕТЕЛЬ: Ну а подтверждений кроме голословных заявлений тоже нет
СВИДЕТЕЛЬ: Тор сломала прога которая предназначена для слежки на пиринговыми сетями


СВИДЕТЕЛЬ: При чем тут пиринговые сети – я не смог выяснить. Человек утверждал – на его глазах тор был пробит за секунды!!!!
СВИДЕТЕЛЬ: То есть – если ты под тором зашел на какой то форум, или сайт – программа отследит всю цепочку и выйдет на твой айпи
СВИДЕТЕЛЬ: Эта программа за считанные секунды отследила цепочку нод и конечный айпи
СВИДЕТЕЛЬ: У провайдера стоит программа – по отслеживанию пиринговых сетей
СВИДЕТЕЛЬ: И то ли оттуда через тор на сайт какой то подсоединились, то ли отслеживали соединение со стороны – я так и не понял толком
СВИДЕТЕЛЬ: Приходит человек к провайдеру


СВИДЕТЕЛЬ: А вот обычный прокси-элит – не пробивает якобы
СВИДЕТЕЛЬ: Пробовали анонимизер в конце ставить – тоже пробило


СВИДЕТЕЛЬ: Провайдер сказал – фигня твой тор – пойдем покажу как он пробивается!
СВИДЕТЕЛЬ: И тот – провайдер (он работает на узле провайдерском (сори за дилетантизм. но я не знаю как это называется))
СПРАШИВАЮЩИЙ: У кого ?
СВИДЕТЕЛЬ: Это мой приятель – а пров – его хороший знакомый. Вот они о торе о спорили
СВИДЕТЕЛЬ: Я так понял – у них перед этм разговор о торе был


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


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Комментарии
— SATtva (15/01/2009 21:44)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Есть более дешёвые атаки – ввод небольшого числа узлов в тор, с декларированием заведомо завышенной пропускной способностью. Что даёт эта атака и даёт ли что-то вообще – не в курсе, – на pgpru она упоминалась кем-то вскольз.

Перелопатить трафика больше, чем реально под силу, узлу не удастся. В результате — классический DoS (для себя и, временно, для сети). В плане на ближайшие три года эта проблема упоминается как требующая решения.

Можно вкратце еще узнать о функции guard-узлов, они не для этого созданы?

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

Guard-узлы — это небольшой пул быстрых стабильных Tor-узлов. Когда клиент подключается к сети, он произвольно выбирает один из этих узлов и постоянно использует его в качестве первого узла цепочки. Исходя из прежних допущений, риск скомпрометированной цепочки в большинстве случаев уменьшается за счёт риска оказаться постоянно привязанным к злоумышленному guard-узлу (но, поскольку guard-узлы — это лишь подмножество всех узлов, а злоумышленные guard-узлы — ещё меньшее подмножество первых, статистика играет на пользователя).

Аналогично, guard-узлы так же эффективны против описанной атаки.
— Гость (15/01/2009 22:40)   <#>
А разве можно наблюдать активность трафика всех узлов и вычислять корреляцию? Это на практике существует или только слухи?

Увеличивая длину цепочки мы снижаем вероятность ее полного вычисления: пусть длина цепочки N, тогда для деанонимизации число шпионских узлов в ней должно быть ~ от N/2 до N. Пусть всего X узлов в сети TOR, Y – узлов шпионские. Вероятность самого неприятного для шпионов случая расположения узлов (вся цепочка за исключением одного узла должна быть шпионской): P=Y!/X!*(X-N)!/(Y-N)!->0, N->Y.

Задачи могут быть весьма конкретными: установка лиц, регулярно посещающих что-либо; установка лиц,
закачивающих (или скачивающих) контент куда-либо; попытка анализа контента (открытый напрямую, косвенно по появлению где-либо) и т.п.

А кто сказал, что заинтересованная организация расчитывает на быстрый успех? Это может быть похоже на рыбалку сетью: длительный процесс фильтрации, добычи немного, но она весьма ценная (просто так же тором не пользуются).

А зачем нужны guard-node, если в торе есть настройка EntryNodes? Вероятность того, что
guard-node – шпион может быть даже больше обычной: это очень лакомая добыча для шпионской сети, guard-шпионов мало, но и guard-node мало.

P. S. А можно узнать определение глобального наблюдателя?
— Гость (16/01/2009 00:48)   <#>
А разве можно наблюдать активность трафика всех узлов и вычислять корреляцию? Это на практике существует или только слухи?


P. S. А можно узнать определение глобального наблюдателя?

Про оба можете покопать начиная отсюда.
— Гость (16/01/2009 01:53)   <#>
Увеличивая длину цепочки мы снижаем вероятность ее полного вычисления: пусть длина цепочки N, тогда для деанонимизации число шпионских узлов в ней должно быть ~ от N/2 до N. Пусть всего X узлов в сети TOR, Y – узлов шпионские. Вероятность самого неприятного для шпионов случая расположения узлов (вся цепочка за исключением одного узла должна быть шпионской): P=Y!/X!*(X-N)!/(Y-N)!->0, N->Y.

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

Ваша логика с удлинением цепочки как средством защиты от атаки может быть перефразирована следующим образом: есть корзинка с белыми и чёрными шариками, хорошо перемешанными. Допустим, белых там 400, а чёрных – 100. Вы говорите, что можете выбрать большое число последовательных вытаскиваний шариков – соответствует длине цепочки (допустим, 100), – тогда вероятность, что среди них будет как минимум один белый (да и вообще, абсолютное число белых) – увеличится. По физике дела, это есть замена ситуации "Y/X – % злонамеренных в цепи из 3х узлов" на "Y/X – % злонамеренных в N узлах" (вроде процентное содержание злонамеренных узлов в корзине и среди выбранных будет равно). Допустим, что Y/X = 10%. Тогда в большинстве сгенерированных цепочек из 3х услов не будет ни одного злонамеренного. А теперь, сравним эту же ситуацию с N узалми из 100. В этом случае в среднем около 10ти из них – злонамеренные. Т.е. вы спасаетесь от вероятности "выбрать все узлы плохими" посредством увеличения длины цепочки, но платите за это тем, что вероятность присутствия некотрого числа (но не всех!) злонамеренных в них – будет существенно больше. Как уже было сказано выше, это, ожидается, упрощает проведение других атак. Или, как выразился SATtva, "защищает от глупого противника, но ослабляет защиту против умного". Верность этого утверждения немного под вопросом (сам статьи не копал по теме), но как понимаю, дело здесь вот в чём: если ваш трафик даёт цепочку из N нод, где N – велико, то можно коррелировать не последовательно 1ую ноду со второй, вторую – с третьей, и т.д., а сразу искать корреляции между входной нодой и выходной (ваш трафик даёт вклад во внутреннеторовский трафик большинства узлов (N штук), а потому проще увидеть большУю часть узлов задействованых в цепочке).

Формулу вашу не проверял, т.к. комбинаторику не знаю чтобы слёту посчитать. У меня получилась вероятность для выбора всех узлов злонамеренными (в цепочке из N узлов для сети с злонамеренностью Y/X) выражение P=[1-Y/X]*[1-(Y-1)/(X-1)]*...*[1-(Y-N+1)/(X-N+1)].
— Гость (16/01/2009 02:16)   <#>
Т.е. вы спасаетесь от вероятности "выбрать все узлы плохими" посредством увеличения длины цепочки, но платите за это тем, что вероятность присутствия некотрого числа (но не всех!) злонамеренных в них – будет существенно больше.

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

Допустим другую ситуацию: 100 узлов в сети тор, из которых 10 – злонамеренные. Вероятность выбрать все узлы злонамеренными в цепочке из 3х узлов достаточно мала, а удлинняя цпочку до N вы будете встраивать в неё в среднем всё большее число злонамаренных, облегчая им атаку на корреляцию трафика.

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

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

Что же касается деанонимизации конкретной группы пользователей, посещающих некий конкретный сайт, она решается проще другими способами, например, модификацией содержимого сайта таким образом, чтобы встроить эксплоиты на браузер. Поскольку последний – самая дырявая программа на стороне пользователя, успех отлова большинства ожидается :)
— unknown (16/01/2009 09:06)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Low-Resource Routing Attacks Against Tor:

fileРабота
fileСлайды
— Гость (16/01/2009 13:06)   <#>
Работа
Слайды

Acknowledgements. We thank Nikita Borisov, ... :-D
Проглядел. Не понимаю одного: а что им мешало делать эксперименты не на модельной тор-сети а реальной? Тогда сила результата и демонстративность была бы куда интересней... Я так понял из работы, что у них степень деанонимизации зависит не только от процентного содержания злонамеренных узлов, но и от абсолютного числа узлов. В частности, для 66 узлов тора с 6 злонамеренными им удалось получить вероятность успешной атаки до 46%. Насколько точно была сэмулирована тор-сеть, сервера директорий и прочее...? Учли ли они? Что выбор цепочки идёт пропорционально пропускной способности выбираемых? Кстати, для такой простой модели как тор, имхо, можно написать и ответ в виде аналитической форумлы... а не ограничиваться только экспериментом (это дало бы дополнительную проверку). Аналитику всегда надо проверять на численном эксперименте, а численный эксперимент – на аналитике, – иначе велика вероятность ошибки (сам статьи пишу, потому знаю). А так... ну они задекларировали "ответ" а остальные должны верить, либо воспроизводить эксперимент (проверить аналитику куда проще).
— Гость (16/01/2009 14:58)   <#>
удлинняя цпочку до N вы будете встраивать в неё в среднем всё большее число злонамаренных, облегчая им атаку на корреляцию трафика.
Вероятность выбора плохих крайних такая-же, а остальные, по большому счёту, не волнуют! :)

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

В общем случае задача защиты от такого противника решения не имеет, ибо если бы было не так, то это означало что можно заставить противника слушать всё что у него происходит в сети, но ничего не дать ему понять из этого – т.е. "всё знать и не знать ничего одновременно"
А нельзя ли создать защиту от подмены кода, используя TPM? Ведь вероятно можно придумать способ, чтобы можно было убеждаться удалённо, что программа выполняется в "доверяемом окружении", даже если она с открытыми исходниками? (Например доверяемым образом "раскрутить" компилятор)
А против внешнего наблюдения можно использовать что-нибудь типа garlic routing, когда в одной "луковице" "головке чеснока" несколько "долек", а на серверах производится их перепаковка.
— Гость (16/01/2009 15:34)   <#>
Ведь вероятно можно придумать способ, чтобы можно было убеждаться удалённо, что программа выполняется в "доверяемом окружении", даже если она с открытыми исходниками?

Нельзя. Язык общения между программами – протокол. Всё, что относится к реализации протокола и дополнительным "незадокументированным действиям" никак не видно со стороны.
— SATtva (16/01/2009 16:12)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
А с корреляционными атаками можно бороться случайными опциональными (т.е. только для желающих) задержками

Tor — транспорт реального времени. При дополнительных задержках TCP станет совершенно безнадёжным, о подобном можно будет говорить только после смены транспортного протокола сети на UDP, и то не для каждого протокола верхнего уровня — иначе связь будет рваться по таймаутам. Вводить QoS на узлах сети, значит передавать в cell'ах метаданные о содержимом, что само по себе частичная деанонимизация и наверняка открытие пути для новых более мощных атак.

Пожалуйста, прежде чем вносить предложения, ознакомьтесь с принципами работы сети и планами её развития. Предложения на текущем уровне контрпродуктивны.
— Гость (16/01/2009 17:13)   <#>
Нельзя. Язык общения между программами – протокол. Всё, что относится к реализации протокола и дополнительным "незадокументированным действиям" никак не видно со стороны.
Значит надо поменять протокол, с учётом возможностей TPE

связь будет рваться по таймаутам
А длинные задержкит и не нужны, достаточно в пределах таймаута, даже может и гораздо меньше, учитывая, сколько пакетов в секунду проходит через узел.
передавать в cell'ах метаданные о содержимом
Не о содержимом, а о способе доставки. Можно, кстати, перемешивать очередь и для всех.
— Гость (16/01/2009 17:22)   <#>
s/TPE/TPM/
— Гость (16/01/2009 18:05)   <#>
У меня получилась вероятность для выбора всех узлов злонамеренными (в цепочке из N узлов для сети с злонамеренностью Y/X) выражениеP=[1-Y/X]*[1-(Y-1)/(X-1)]*...*[1-(Y-N+1)/(X-N+1)].

При Y-числе злонамеренных узлов, X-общем числе узлов это вероятность того, что все узлы будут чистенькими. Вероятность того, что вся цепочка будет злонамеренной (это худший вариант деанонимизации канала для шпиона): Q=[Y/X]*[(Y-1)/(X-1)]*...*[(Y-N+1)/(X-N+1)] – как видно с ростом длины цепочки растет число сомножителей, каждый из которых <=1. Т.е. вероятность деанонимизации посредством "транзитивности" с ростом длины цепочки убывает (это верно на самом деле не только для худшего случая, но и для произвольного).

Что касается корреляционной или иной временно'й оценки, то с ростом длины цепочки повышается вероятность увеличения выборки, т.е. и качество деанонимизации. Но тут вопрос, насколько сильны "шумы" на узлах для их фильтрации.

Tor — транспорт реального времени.

А если держать принудительно всю сеть под постоянным максимальным напряжением (посредством пакетов пустышек), что нивелирует всплески активности?
— SATtva (16/01/2009 19:07)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
А длинные задержкит и не нужны, достаточно в пределах таймаута, даже может и гораздо меньше, учитывая, сколько пакетов в секунду проходит через узел.

Задержки в масштабе TCP (т.е. секунды, пара-тройка десятков секунд) не дадут практической выгоды, а только снизят практичность сети (даже при нынешних задержках, накладываемых одним лишь рутингом, сколько нытья, что Tor слишком медленный). Корреляция трафика невозможна в сети Mixmaster, но там задержки совершенно иных масштабов — часы и сутки.

А если держать принудительно всю сеть под постоянным максимальным напряжением (посредством пакетов пустышек), что нивелирует всплески активности?

Теоретические работы не показывают эффективность частичного покрывающего трафика. А полный покрывающий трафик (полная загрузка каналов между всему узлами и клиентами сети) — непрактичная мера, она никому не по карману.
— Гость (16/01/2009 20:27)   <#>
Теоретические работы не показывают эффективность частичного покрывающего трафика. А полный покрывающий трафик (полная загрузка каналов между всему узлами и клиентами сети) — непрактичная мера, она никому не по карману.

Тогда вся надежда на рост числа пользователей сети – естественное увеличение загрузки. Хотя можно пофантазировать на предмет постоянно-загруженной и низкопропускной для экономии трафика подсети с опцией подключения к ней в клиентах.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3