Подозрительная информация о деанонимизации тор
По ряду каналов пришла следующая инфа (реконструирую диалог и убираю несущественные детали):СВИДЕТЕЛЬ: Я так понял – подсоединялся он прямо у провайдера, не со стороны (приходил к прову со своим лэптопом)
СВИДЕТЕЛЬ: Видели следующее. Человек пришел к провайдеру, подсоединился со своего ноута через тор к нему, и
в течение пары секунд программа выдала всю цепочку нод и конечный айпи
СПРАШИВАЮЩИЙ: Нужно хотя бы точно сказать что он видел, что конкретно?
СВИДЕТЕЛЬ: Ну а подтверждений кроме голословных заявлений тоже нет
СВИДЕТЕЛЬ: Тор сломала прога которая предназначена для слежки на пиринговыми сетями
СВИДЕТЕЛЬ: При чем тут пиринговые сети – я не смог выяснить. Человек утверждал – на его глазах тор был пробит за секунды!!!!
СВИДЕТЕЛЬ: То есть – если ты под тором зашел на какой то форум, или сайт – программа отследит всю цепочку и выйдет на твой айпи
СВИДЕТЕЛЬ: Эта программа за считанные секунды отследила цепочку нод и конечный айпи
СВИДЕТЕЛЬ: У провайдера стоит программа – по отслеживанию пиринговых сетей
СВИДЕТЕЛЬ: И то ли оттуда через тор на сайт какой то подсоединились, то ли отслеживали соединение со стороны – я так и не понял толком
СВИДЕТЕЛЬ: Приходит человек к провайдеру
СВИДЕТЕЛЬ: А вот обычный прокси-элит – не пробивает якобы
СВИДЕТЕЛЬ: Пробовали анонимизер в конце ставить – тоже пробило
СВИДЕТЕЛЬ: Провайдер сказал – фигня твой тор – пойдем покажу как он пробивается!
СВИДЕТЕЛЬ: И тот – провайдер (он работает на узле провайдерском (сори за дилетантизм. но я не знаю как это называется))
СПРАШИВАЮЩИЙ: У кого ?
СВИДЕТЕЛЬ: Это мой приятель – а пров – его хороший знакомый. Вот они о торе о спорили
СВИДЕТЕЛЬ: Я так понял – у них перед этм разговор о торе был
Я сам отношусь к подобному довольно скептически, и осознаю ряд потенциальных дыр,
испольузя которые можно деанонимизировать тор (трояны, неверная настройка, и т.п.),
но всё же меня гложат сомнения. есть ли ещё какая-либо информация по этому поводу,
которая помогла бы разобраться в вопросе?
Ссылки
[link1] https://www.pgpru.com/novosti/2007/nemeckajapolicijanemozhetpreodoletjzaschituskype
[link2] http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1025-07.pdf
[link3] http://www.pgpru.com/novosti/2007/0528koncepcijaglobaljnogonabljudateljapodlezhitperesmotru
[link4] http://www.freehaven.net/anonbib/cache/bauer:wpes2007.pdf
[link5] http://systems.cs.colorado.edu/~bauerk/papers/WPES07-bauer-talk.pdf
[link6] http://ru.wikipedia.org/wiki/Trusted_Platform_Module
[link7] http://www.google.com/search?hl=en&q=garlic+routing&btnG=Search
[link8] https://www.pgpru.com/forum/anonimnostjvinternet/malobjudzhetnyeatakinatoriegoanalogi
[link9] https://wiki.torproject.org/noreply/TheOnionRouter/EndToEndAttacks
[link10] https://bugs.torproject.org/flyspray/index.php?do=details&id=821
[link11] https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#VariablePathLength
[link12] https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#SplitStreams
[link13] https://svn.torproject.org/svn/tor/trunk/doc/spec/path-spec.txt
Гыы :-D
Судя по всему тому что осбуждалось на этом сайте, подобное, как описано в деталях, возможно лишь в единственном случае: пров научился на лету подгружать троян к винде. Короче, так или иначе завязано на троян. Есть и другие атаки, позволяющие раскрыть анонимность, но они внешне не приведут к раскрытию произвольной полной цепочки "за секунды".
Информация на уровне бабушкиных сплетен, комментировать трудно.
Допустим что так. Но показывали неспециалисту, иначе было бы больше подробностей.
Сайт выбирался в пределах одной страны? Можно было бы предположить, что есть программа "глобальный наблюдатель", мониторящая весь тор трафик (и пиринговых сетей впридачу) и обменивающася данными между провайдерами.
А вообще стиль знакомый: "Вытащите любую карту из колоды. С помощью детектора лжи можно будет точно определить её по реакциям во время ваших ответов" (в колоду кладут все карты одинаковые, но проверить это предположение разумеется не дают).
"Мы знаем о Вас всё. Например вчера в такое-то время... "(даются выборочные, но ошемломляющие данные, создающие иллюзию полного досье, но задать любой уточняющий вопрос, "а про позавчера знаете?" тоже не дают) и т.д.
Обычно это какой-то демонстрационный трюк, подтасовка, специально чтобы поразить воображение.
Еще интересно знать источник информации, не скажите?
А детали диалога могут оказаться немоловажными хотябы для "проверки на вшивость".
[offtop]
Если вы хоть раз интересовались альтернативной энергетикой знаете сколько шарлотанов вьется вокруг темы – вд первого и второго рада, торсионные поля, безопорные двигатели и прочий бред но с очень убедительными демонстрациями и формулами и тд.
Не в обиду топикстартеру но похоже хотят просто привлечь внимание к своему сайту/каналу.
[/offtop]
Как вариант: скрытая камера в помещении или на одежде у завербованного друга сидящего рядом с "человеком СВИДЕТЕЛЯ", вот такой детектив.
Пока "человек СВИДЕТЕЛЯ" печатает название сайта, его перехватывают со скрытой камеры прямо с экрана ноутбука, передают оператору в другом помещении, который вводит эти данные по сети в фэйковую программу, результат работы которой и был продемонстрирован "человеку СВИДЕТЕЛЯ". Название первого узла в цепочке не является секретом от провайдера. Последний узел можно вывести сразу как его покажет "для сравнения" изумлённый "человек СВИДЕТЕЛЯ". Может у того на экране была какая-нибудь Видалия, где можно видеть сразу всю выбранную цепочку.
У оператора может быть список узлов сети Tor и программа с автодополнением имён и соотв. IP из списка для более быстрого ввода.
Если в конце не сказали: "Улыбнитесь, вас снимает скрытая камера!", значит это не для телерозыгрыша.
Еще интересно знать источник информации, не скажите?
через третьи руки видимо, и в интернете не публиковалась, раз диалог.
Сайт выбирался в пределах одной страны?
судя по уровню "свидетеля", не догадался он ввести сайт с другой страны :(
Можно было бы предположить, что есть программа "глобальный наблюдатель", мониторящая весь тор трафик (и пиринговых сетей впридачу) и обменивающася данными между провайдерами.
Сложно создать и эксплуатировать такую программу так, чтоб об этом никто не узнал. Зная по слухам, что осла в некоторых странах запретили, стоит предположить что такой программы всё же нет.
Предположим теорию заговора. Некие "компетентные службы" не могут справиться с Tor'ом, поэтому дискредитируют его эффективность. Заметьте в тексте заявление о якобы "непробиваемости" обычных анонимных прокси.
Если видите информацию, похожую на дезу, задайтесь вопросом, "кому это выгодно?". А вообще это всё к Джону Янгу на cryptome.org.
Гость (25/02/2008 03:50), выделяйте цитаты.
Определение цепочки вплоть до каждого звена, возможно:
1) клиентом.
2) атакой unknown'а (но она против обычного гражданина РФ, без существования рабочего КК более теоретическая, чем реальная)
3) глобальным наблюдателем (если вообще оправдано выявлять отдельные элементы цепочки).
Всё.
Имхо фейк и деза. Фраза про непробиваемость обычных прокси жжот, особенно на фоне того, что нешифрованые прокси протоколы по умолчанию декодируются СОРМом.
Ага, и мне так подумалось. В германии власти оффициально заявили что не могут взломать скайп, типа пользуйтесь на здоровье, выяснилось что все наоборот.
Вот если разговор про OpenVPN еще можно поверить, но ОБЫЧНЫЕ прокси :\
Не совсем; Вы тоже дезу не распространяйте. ;-) Первоначально речь шла о том, что они не могут взломать шифрование, поэтому приняли решение его обходить с помощью трояна на клиентской стороне (это не утверждалось напрямую, но из ответа руководителя BKA так можно было заключить, что я и сделал). Впоследствии этот намёк подтвердился утечкой через Wikileaks. Обе новости у нас публиковались, можете сами посмотреть.
В общем, всё, как обычно: каналы передачи данных защищены, а машины на обоих концах представляют собой решето; и что в итоге проще атаковать? Будьте уверены, если Tor и "взламывают", то точно так же.
Они не обычные, они Элитные ;) почуствуйте разницу (в своем кошельке).
Что касается дезы, это могла быть деза с целью вызвать вот такого рода обсуждения (согласитесь на основе источника ОБС конструктива в дальнейшем мало), чтобы погасить какой-либо информационный выброс с действительным деактивированием анонимности разного рода подпольного населения.
Чтобы все думали будто они знают что те не знают что они думают о том что знают не те кто думают о зн... *(взрыв мозга)*
А не в курсе, что за троян они написали? И какими-нибудь общеупотребимыми средствами он детектируется? И в чем выражается его активность, как его надежно заблокировать фаерволом?
А ни у кого нет надежной инфы из проверенных источников (от провайдеров, специальных технических служб ФСБ etc.)?!
Оффтопик. Я же отослал Вас к новостям[link1]. Читайте комментарии. Туда же адресуйте все свои вопросы.
Это никому не нужно. Все рассуждения и так предсказуемы. И ни на что это не повлияет.
Сначала пи*ёж, теперь провокация? В личке с такими запросами общайтесь или на других сайтах.
Понятно, очередной стратег, знающий что и кому нужно, и что в результате получится.
Кроме цифрового шума, в этой ветке пока ничего рассудительного нет.
А Вы чего ожидали, если само сообщение, открывшее ветку, — такой же информационный шум?
Мне кажется, человек не до конца был уверен в том что это деза и решил спросить специалистов, а вы на него накинулись :) Будьте конструктивными – так и скажите: на данный момент в академическом сообществе атак, могущих привести к описываемому поведению нет, за исключением впаривания трояна или обычного розыгрыша.
Сорри за оффтоп, мне почему-то показалось что аффтар как раз и хотел узнать именно это :-D
Ну, точнее, если у кого есть знакомый провайдер – то пусть спросят "есть ли что подобное". Это же не предмет, составляющий го...тайну... (вродь провы с гостайной не работают). Существование морса тож не го...тайна.
"Записываете на листе бумаги произвольную карту. Если человек вытаскивает не её, показываете какой-нибудь друго фокус" – читал в какой-то книге по фокусам.
Интересовался. Не хочу разводить оффтоп, но думаю тут не всё так просто, как вам кажется.
Мне кажется, что вам кажется, что вам не кажется, что это кажется не вам?
а почему тут считают что программными способами не решить проблему? Skype например шифрует себя в памяти...
реальна вообще идея: ключи от зашифрованной в оперативки информации хранить на винчестере (или может в кэше винчестера) ?
Можно ли это с точностью утверждать?! Хотелось бы знать, насколько, ибо ориентироваться в жизни надо на худшее.
Да и ничего страшного, если го...тайна. В конце концов, никто подписки в этом не давал, а от друзей оттуда еще не такое услышишь. Я у своих знакомых поинтересоваться не могу, просто потому что они в компах шарят меньше меня, а я так галимый ламер (правда со стремлением что-то познать, а они без такового). А из профильных техслужб нет. По крайней мере со скайпом уверяли что все могут просечь, в итоге – ничего не смогли в конкретном случае, когда понадобилось. (То ли их "развели" свои же технари-лентяи, толи – опираясь на инфу из Германии, реально не могут).
Хранить-то можно, а использовать как? Если у Вас нет специализированного криптопроцессора с контроллером и собственной памятью, любой обрабатываемый секрет неминуемо должен пройти через ОЗУ.
Думаю, да. На этом сайте есть публика, которая в курсе всех громких и известных атак на анонимные сети, так что если никто не припомнил никакого разумного объянения кроме трояна/розыгрыша, то так оно и есть.
Продолжаем повышать энтропию. На сей раз новости с ангоязычными источниками. Прошла информация о раскрытии анонимности пользователей с помощью скрытых сервисов, игравших роль приманки. Во главе действия был core.onion (это не адрес), несколько часов по свидетельствам очевидца(ев), перенаправлявший на страницу с текстом:
Вообще, у меня ещё изначально возникал вопрос о том, что анонимнее для пользователя, и что анонимнее: пользователь, идущий на скрытый ресурс, пользователь, идущий через тор на обычный сайт и пользователь, владеющий скрытым ресурсом. Вообще, последняя новость, кстати (если это правда, конечно), звучит куда более реалистично.
А что это за ресурс и за что он отвечает в скрытых сервисах?
P. S.: ранее встречалась информация на скрытых ресурсах об их странной особенности, которую подметили их пользователи: ресурсы открываются, живут сколько-то, а потом умирают, и после смерти никогда не восстанавливаются снова (уже некому восстанавливать?).
Ну, запустил оператор у себя на машине скрытый сервис. Из любопытства, скажем. Энтузиазм угас — сервис закрылся.
У скрытых сервисов нет аналога DNS (во всяком случае пока), каждый адрес представляет собой хэш ключа сервиса. Представим ситуацию, что у оператора накрылась машина, и ключ оказался утрачен. Даже если запустить сервис снова, он больше не будет доступен по старому адресу, т.е. оператору опять придётся как-то привлекать внимание к ресурсу. Это жуткая морока (сам знаю), поэтому кто-то может в такой ситуации просто опустить руки.
Короче, причин уйма. Многие ресурсы не столь интересны, чтобы кого-то интересовала личность оператора и, тем более, его устранение.
Потому что адрес ресурса составлен из отпечатка его ключа. Он может воссоздаться на другом .onion адресе
Там вроде бы алиасы вводили, так что если их использовать можно было по имени обращаться к хосту, но я ту систему не настраивал и не разбирался.
Кажется core.onion и занимался алиасами или был отправной точкой для редиректа на скрытые сервисы.
core.onion и сейчас работает. Он стал заменителем утраченной скрытой вики. Там размещают ссылки на другие ресурсы, с кратким описанием. Плюс чат, мини форум, расшаривание файлов, и прочее.
В продолжении истории с приманками. Копия сообщения была размещена в википедии (очень достоверный :) источник), примерно в час ночи по гринвичу (с адреса веб хостинга в голландии, также предлагающего выделенные сервера). На самом core зафиксированы сообщения на тему "что это было" уже в начале третьего часа (с непонятными цитатами и удобно образовавшимися пробелами в нумерациях сообщений, которые впрочем существовали и ранее в ходе "зачисток" религиозных троллей). И на текущий момент каких-либо других признаков случившегося нет, и комментариев(вне цитат от посетителей core) которым можно доверять.
Было ли это на сам деле, и "интерпол" на текущий момент просто отменил операцию. Или это хорошо срежиссированная социальная атака на анонимов (тех же властей, или коммерческих "конкурентов"). А может просто тролли развлекались.
Мониторим дальше.
А если формально, то из-за чего скрытая вики умерла?
Это вероятно останется тайною, и это уже обсуждали на форуме.
Владелец однажды просто избавился от содержимого, оставил краткое послание и был таков. Сам сервис еще долго работал, и даже радовал, некоторое время спустя, ссылкой на чужую вики (про неё незнаю ничего), продолжателя традиций. Но вот сейчас такого сервиса вообще нет.
Почитывая рунет, нашел мысль, как ломают пользователей Tor. Мысль была размещена открыто, звучит как-то по новому, и пересекается с первым сообщением, поэтому заслуживает трибуны, именно в этом топике.
Через провайдера тоже "рано или поздно" выходят в Tor-сеть.
Моя логика упорно отрицает написанное (например в части "рано или поздно" для узлов). Но возможно она не самая логичная, ну и шифры понятно "де"-шифруются.
[offtopic]
Если долго сидеть на берегу реки, то можешь увидеть проплывающий труп твоего врага (Конфуций).
[/offtopic]
Интересно, как они могут запомнить и меня и мой запрос, если первый узел в цепочке не знает мой запрос, а последний не знает меня. Или предполагается что число таких подставных узлов составляет существенный процент от всей сети?
Я бы сказал проще: когда тор-пользователей смогут массово "вычислять" мы узнаем – противнику сохранить это втайне не удастся. Пока зохавают первых, остальные уже будут в курсе.
глупость какая..это запросто может происходить и сейчас просто тихо. мелочь никто не тронет, а для остальных это приманка
А как насчёт той атаки, когда измеряется загруженность канала тор-узла по латентности ответов тор-узла. И используется свойство, что сайт отдаёт данные неравномерно?
poptalk, с этим вопросом к профессору Керомитису (Keromytis). И даже если он ответит, все равно кто-то должен эту неравномерность приводить к детектируемой форме. Если провайдер из текста топикстартера способен на такое, иначе говоря контролировал трафик на выходе и наблюдал на входе, тогда ему атака Керомитиса не нужна в принципе.
Что ж, буду ждать, когда профессор посетит сей форум. :) Я не совсем понял, что значит "на входе и на выходе". Насколько мне известно, из "особых прав" необходимо только право прослушивать посещаемый сайт.
Прочитайте эту статью: http://www.cs.colorado.edu/dep.....cs/CU-CS-1025-07.pdf[link2]
Вкратце:
Создавая ноды и напиздев Тору о том, что на них жирный канал, можно перенаправить новых юзеров к себе, захватив входной и выходной ноды, и узнав айпи. Есть еще улучшенные варианты.
Работает 50 на 50, вроде. Технология кажется очень простой в реализации и не требует ресурсов, можно даже с модема/модемов (лучше не аналоговых)
Буду краток: Выходите поскорей из анабиоза!
Hint:Уточните для себя функции guard узлов, как ими становятся и как они используются.
То что она в теории низко-бюджетная, не означает простоту реализации.
PS: Тема выбрана явно ошибочно. ТС сообщал о супер секретной разработке (но которой владеют даже isp по версии TC), а ваша "статья" на секретность и особое ноу-хау не претендует вовсе (лишь показаны математические выкладки для атаки, сценарий которой упоминался самими разработчиками).
Тору? Скандинавскому богу? А он за мат, ложь и фактологический оффтопик не прогневается?
У меня такой вопрос.
Пусть некоторая группа людей из разных стран захочет создать базу данных о работе TOR. Их могут интересовать постоянные пользователи TOR, их связи, интересы, трафик (если он не шифрован). Этим людям достаточно создать в своих странах узлы, на которых будут вестись логи и снифериться трафик. На каждом узле созданной подсети будет идти проверка соседних узлов, если вход и выход 3-звенной цепочки окажется внутри подсети, то входной и выходной IP и соответствующий трафик будет заноситься в базу данных. Если число узлов подсети высоко, то риск деанонимизации будет высоким.
Что можно этому противопоставить кроме увеличения длины цепочки? Можно вкратце еще узнать о функции guard-узлов, они не для этого созданы?
Увеличивания длину цепочки, вы увеличиваете степень защиты против одной атаки, но существенно её ослабляете против другой (атаки на корреляцию трафика), и что здесь более существенно – увеличение защиты или её уменьшение – большой вопрос. Исследователи пока сходятся к тому, что длина цепочки в 3 узла – оптимум. Не забывайте, что увеличив длину цепочки, вы будете чаще выбирать узлы, входящие в злонамеренную вами описанную подсеть (это банальная математика). В общем случае задача защиты от такого противника решения не имеет, ибо если бы было не так, то это означало что можно заставить противника слушать всё что у него происходит в сети, но ничего не дать ему понять из этого – т.е. "всё знать и не знать ничего одновременно". Частичная защита строится на том, что поднять большое число быстрых узлов под силу только крупным заинтересованным организациям – а надо ли им это? Чтобы ввод узлов в сеть не смотрелся атакой, вводить их нужно постепенно, а сами узлы должны принадлежать разным географически ареалам – даюы не портить статистику. Заранее выловить нужного пользователя не получится, – можно будт ловить лишь случайных, писать огромное число левого трафика. потом его собирать в одном месте, синхронизировать... эта задача не намного проще (если проще вообще) чем задача т.н. "глобального наблюдателя", от которого заведомо выводят за рамки угроз для тор. Есть более дешёвые атаки – ввод небольшого числа узлов в тор, с декларированием заведомо завышенной пропускной способностью. Что даёт эта атака и даёт ли что-то вообще – не в курсе, – на pgpru она упоминалась кем-то вскольз.
Не совсем против этой атаки, но от близкой по смыслу. Имеет эффект и против этой атаки, думаю.
Перелопатить трафика больше, чем реально под силу, узлу не удастся. В результате — классический DoS (для себя и, временно, для сети). В плане на ближайшие три года эта проблема упоминается как требующая решения.
Для пользователя Tor опасность представляет ситуация, при которой будут выбраны первый и последний узел, принадлежащие одному противнику. Если исходить из допущения, что часть узлов в сети злонамеренны, а пользователи выбирают узлы для всех звеньев цепочки абсолютно случайно, то, статистически, время от времени каждый пользователь будет попадать на такую цепочку, где оба оконечных узла злонамеренны.
Guard-узлы — это небольшой пул быстрых стабильных Tor-узлов. Когда клиент подключается к сети, он произвольно выбирает один из этих узлов и постоянно использует его в качестве первого узла цепочки. Исходя из прежних допущений, риск скомпрометированной цепочки в большинстве случаев уменьшается за счёт риска оказаться постоянно привязанным к злоумышленному guard-узлу (но, поскольку guard-узлы — это лишь подмножество всех узлов, а злоумышленные guard-узлы — ещё меньшее подмножество первых, статистика играет на пользователя).
Аналогично, guard-узлы так же эффективны против описанной атаки.
А разве можно наблюдать активность трафика всех узлов и вычислять корреляцию? Это на практике существует или только слухи?
Увеличивая длину цепочки мы снижаем вероятность ее полного вычисления: пусть длина цепочки 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. А можно узнать определение глобального наблюдателя?
Про оба можете покопать начиная отсюда[link3].
Вы немного путаете понятия "деанонимизации цепочки" и "расшифрования цепочки". Чтобы цепочку расшифровать, все до одного узла цепочки должны быть выбраны из числа злонамеренных. Чтобы её всего лишь деанонимизировать (сказать кто на какой сайт заходит) – достаточно иметь подробные логи большинства узлов, входящих в злонамеренную цеипочку, и применить "атаку на корреляцию".
Ваша логика с удлинением цепочки как средством защиты от атаки может быть перефразирована следующим образом: есть корзинка с белыми и чёрными шариками, хорошо перемешанными. Допустим, белых там 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)].
Ещё немного подумал. Кажется, это – попытка борьбы с огнём методом заливания бензином. Ваш метод как стратегия осмысленен, только если предполагается, что большинство существующих узлов тор – злонамеренные. В этом случае, раз всё равно большинство цепочек выбирается полностью скомпрометированными, вы удлиняете цепочку, и этим повышаете вероятность встраивания в неё хотя бы некоторых честных узлов сети.
Допустим другую ситуацию: 100 узлов в сети тор, из которых 10 – злонамеренные. Вероятность выбрать все узлы злонамеренными в цепочке из 3х узлов достаточно мала, а удлинняя цпочку до N вы будете встраивать в неё в среднем всё большее число злонамаренных, облегчая им атаку на корреляцию трафика.
Видимо, метода удлиннения цепочки облегчает атаку для корреляции трафика как со стороны честных (потенциальная коллективаня воображаемая возможность), так и злонамеренных узлов. А вывод насчёт увеличения реальной безопасности строится на соотношении числа честных и злонамеренных узлов в сети.
Кроме того, по поводу глобального наблюдателя: если он имеет доступ к логам всех провайдеров, то ему не нужно держать свои тор-ноды, ибо весь тор-трафик всё равно проходит через его логи. Если крупная группа провайдеров будет заниматься отслеживанием тор-трафика, то может добиться неких успехов :) Это я к тому, чтобы вы смотрели на проблему шире: число атак и подходов со стороны противника не так-то мало.
Что же касается деанонимизации конкретной группы пользователей, посещающих некий конкретный сайт, она решается проще другими способами, например, модификацией содержимого сайта таким образом, чтобы встроить эксплоиты на браузер. Поскольку последний – самая дырявая программа на стороне пользователя, успех отлова большинства ожидается :)
Low-Resource Routing Attacks Against Tor:
Работа[link4]
Слайды[link5]
Acknowledgements. We thank Nikita Borisov, ... :-D
Проглядел. Не понимаю одного: а что им мешало делать эксперименты не на модельной тор-сети а реальной? Тогда сила результата и демонстративность была бы куда интересней... Я так понял из работы, что у них степень деанонимизации зависит не только от процентного содержания злонамеренных узлов, но и от абсолютного числа узлов. В частности, для 66 узлов тора с 6 злонамеренными им удалось получить вероятность успешной атаки до 46%. Насколько точно была сэмулирована тор-сеть, сервера директорий и прочее...? Учли ли они? Что выбор цепочки идёт пропорционально пропускной способности выбираемых? Кстати, для такой простой модели как тор, имхо, можно написать и ответ в виде аналитической форумлы... а не ограничиваться только экспериментом (это дало бы дополнительную проверку). Аналитику всегда надо проверять на численном эксперименте, а численный эксперимент – на аналитике, – иначе велика вероятность ошибки (сам статьи пишу, потому знаю). А так... ну они задекларировали "ответ" а остальные должны верить, либо воспроизводить эксперимент (проверить аналитику куда проще).
Вероятность выбора плохих крайних такая-же, а остальные, по большому счёту, не волнуют! :)
А с корреляционными атаками можно бороться случайными опциональными (т.е. только для желающих) задержками – типа пропускать в очереди вперёд себя пакеты других (зато другим быстрее будет, и учёт разных потребностей в анонимности даст дополнителный ресурс за счёт возможного обмена скорости на анонимность или наоборот). Ну сделают же это хоть когда нибудь! Если, конечно, сами разработчики не злонамерены. :(
А нельзя ли создать защиту от подмены кода, используя TPM[link6]? Ведь вероятно можно придумать способ, чтобы можно было убеждаться удалённо, что программа выполняется в "доверяемом окружении", даже если она с открытыми исходниками? (Например доверяемым образом "раскрутить" компилятор)
А против внешнего наблюдения можно использовать что-нибудь типа garlic routing[link7], когда в одной
"луковице""головке чеснока" несколько "долек", а на серверах производится их перепаковка.Нельзя. Язык общения между программами – протокол. Всё, что относится к реализации протокола и дополнительным "незадокументированным действиям" никак не видно со стороны.
Tor — транспорт реального времени. При дополнительных задержках TCP станет совершенно безнадёжным, о подобном можно будет говорить только после смены транспортного протокола сети на UDP, и то не для каждого протокола верхнего уровня — иначе связь будет рваться по таймаутам. Вводить QoS на узлах сети, значит передавать в cell'ах метаданные о содержимом, что само по себе частичная деанонимизация и наверняка открытие пути для новых более мощных атак.
Пожалуйста, прежде чем вносить предложения, ознакомьтесь с принципами работы сети и планами её развития. Предложения на текущем уровне контрпродуктивны.
Значит надо поменять протокол, с учётом возможностей TPE
А длинные задержкит и не нужны, достаточно в пределах таймаута, даже может и гораздо меньше, учитывая, сколько пакетов в секунду проходит через узел.
Не о содержимом, а о способе доставки. Можно, кстати, перемешивать очередь и для всех.
s/TPE/TPM/
При Y-числе злонамеренных узлов, X-общем числе узлов это вероятность того, что все узлы будут чистенькими. Вероятность того, что вся цепочка будет злонамеренной (это худший вариант деанонимизации канала для шпиона): Q=[Y/X]*[(Y-1)/(X-1)]*...*[(Y-N+1)/(X-N+1)] – как видно с ростом длины цепочки растет число сомножителей, каждый из которых <=1. Т.е. вероятность деанонимизации посредством "транзитивности" с ростом длины цепочки убывает (это верно на самом деле не только для худшего случая, но и для произвольного).
Что касается корреляционной или иной временно'й оценки, то с ростом длины цепочки повышается вероятность увеличения выборки, т.е. и качество деанонимизации. Но тут вопрос, насколько сильны "шумы" на узлах для их фильтрации.
А если держать принудительно всю сеть под постоянным максимальным напряжением (посредством пакетов пустышек), что нивелирует всплески активности?
Задержки в масштабе TCP (т.е. секунды, пара-тройка десятков секунд) не дадут практической выгоды, а только снизят практичность сети (даже при нынешних задержках, накладываемых одним лишь рутингом, сколько нытья, что Tor слишком медленный). Корреляция трафика невозможна в сети Mixmaster, но там задержки совершенно иных масштабов — часы и сутки.
Теоретические работы не показывают эффективность частичного покрывающего трафика. А полный покрывающий трафик (полная загрузка каналов между всему узлами и клиентами сети) — непрактичная мера, она никому не по карману.
Тогда вся надежда на рост числа пользователей сети – естественное увеличение загрузки. Хотя можно пофантазировать на предмет постоянно-загруженной и низкопропускной для экономии трафика подсети с опцией подключения к ней в клиентах.
Нет, это сущностное непреодолимое ограничение. Аналогия: считайте, что компы – люди, а протокол – язык общения. Очевидно, что общаясь с человеком нельзя понять всё, что он думает в данный момент на самом деле. А случаи детекторов лжи как раз соответствуют атакам на побочные электромагнитное и прочие излучение (называется TEMPEST). Поскольку у вас физического доступа ко всем рутерам сети нет, про TEMPEST можете забыть :) В общем, эти рассуждения ведут в оффтопик, а потому прошу придерживаться темы.
Да, ступил чё-то я :)
Это так может быть только у военных. Некогда на этот счёт уже высказывался unknown. Гражданским институтам иметь такую спецсеть непомерно дорого.
Я бы не был столь категоричен. Используя TPM, можно гарантировать, что исполняемая ОС кошерно-халяльно-православна, а ОС, в свою очередь, может аттестовать исполняемый софт, согласовывая эти данные через Сеть. Это весьма активная область исследований, продвигаемая корпоративным сектором (например, удалённый сотрудник допускается в корпоративную сеть только после того, как ОС пройдёт аттестацию на отсутствие зловредного кода).
Только с практическими реализациями такой архитектуры напряг. Начиная с надёжных TPM, собственно.
По моему, при достаточной нагрузке на сеть, они существенно затруднят корреляционные атаки. А если допустить дополнительный бит метаданных для QoS, могут даже улучшить пропускную способность для торопливых. А простую рандомизацию очереди по-моему надо оформить в виде предложения разработчикам. (Сам хотел было Написать патч, да уж больно реализация очередей в Tor'e "нертивиальная")
А вот как пришлют вам по заказу программу, зашифрованную открытым ключём вашего TPM, которая будет подписывать все исходящие из неё в сеть пакеты... :)
Осталось придумать как убедиться, что вам прислали именно то, что вы хотели и ничего больше. Ну тут может какие-нибудь протоколы с нулевым разглашением сгодятся.
Всё болше людей переходят на безлимит, однако.
Мне объяснять надоело. Но, раз по-вашему так, напишите работу с обоснованием, представьте её на PET, оформите proposal в or-dev.
Вы не объясняете а просто утверждаете. Корреляции ведь в долях секунды меряют, и отклонение даже на такое время затруднит атаку.
Допустим, у нас есть сферический TPM в вакууме, он позволяет запускать только ПО подписанное производителем TPM, и может выдавать этому ПО удостоверяющие подписи, которые затем используются в протоколе. Предположим, что наше ПО запускается без ОС, и не содержит никаких уязвимостей могущих привести к модификации его кода в памяти. Тогда, обладая физическим доступом к системе, мы можем быть уверены в отсутствии модификаций ПО в той степени, в какой мы доверяем производителю TPM.
Если мы не имеем физического доступа, то такой уверенности уже быть не может, поскольку ПО может быть модифицировано в памяти с помощью прямого подключения к железу (достаточно вставить PCI плату, подключить IDE или SATA устройство, или даже просто девайс к порту 1394). Это делается гораздо проще, чем кажется, и некоторые методы даже не требуют спецтехники.
Если рассматривать реальную систему, то наше ПО будет работать под какой-либо ОС, а в любой ОС имеются уязвимости на исполнение кода в ядре, а драйвера железа имеют еще больше таких уязвимостей. Это позволяет локальному пользователю обойти ограничения TPM без применения аппаратных методов.
Ну и наконец, если применить такую модель безопасности именно к Tor, то всё становиться ещё плачевнее. Для создания злонамеренного узла не обязательно модифицировать Tor, достаточно написать собирающую статистику программу. Даже не обязательно писать полноценную программу, можно собирать статистику соединений скриптом запускающим netstat, и инжектировать отпечатки в трафик путем изменения правил фаерволла. Ну и наконец, можно вообще не трогать Tor сервер, а просто подключить его к интернету через злонамеренный маршрутизатор, который будет всё это делать.
Еще добавим проблему доверия к самому TPM. Кто будет решать, какой софт можно юзать, а какой нельзя? Кто гарантирует, что ключом TPM не будет подписан вредоносный код? Наивно считать, что заинтересованные лица не смогут получить нужную им подпись для модифицированного софта.
Сферический TPM в вакууме должен представлять из себя однокристальный (на одной микросхеме вместе с памятью и с защитой от физического взлома) компьютер, которому можно поручить выполнение критических операций, в случае "чесночного" рутинга (в Tor'e – "луковый") это может быть перепаковка пакетов, включение в них хэша исполняемого в TPM кода и подписание их.
Если же ещё и производство подобного TMP сделать открытым и публично проверяемым, то есть надежда, что даже "заинтересованным лицам" не удастся его подделать. В общем, мечтать не вредно.
, заверенного ключом этого TPM. Это должна быть встроенная команда.
Невозможно рандомизировать очередь, поскольку в Tor оперируют в терминах потоков. Краевой узел не имеет другой информации о порядке передачи данных в место назначения, кроме как в полученном по цепочке. Реализация очередей очень простая, поскольку они в настоящий момент не являются элементом дизайна сети. Очереди служат лишь для разгрузки output буфера, и более аккуратного использования памяти. О рандомизации можно говорить лишь при описании процесса выбора очереди из которой данные пойдут "в провод". Интуитивно кажется, что такая рандомизация может чему-то и поможет, но вдруг это лишь откроет возможности к новым атакам, или в лучшем случае просто бессмысленно? (Заплатки в код это самое простое и последнее что необходимо сделать, в процессе реализации чего-либо.)
PS: Не настаиваю на правильности изложенного. Кроме того иногда (кому и всегда :>) проще выразить всё патчем, просто для того что бы начать думать над предложенным.
Присоединяюсь, мне тоже не ясно. Атака на кореляцию трафика это когда в начале и конце соединения стоят враги и видят: "пошёл пакет на старте, через 5 секунд пошёл пакет на финише. 3 пакета здесь, 3 пакета там. Снова и снова, через одинаковые промежутки времени. Значит, это одна цепочка". Так? Тогда, кажется, задерки, меньшей либо равной времени пинга должно хватить с избытком. А это вполне приемлемо – в худшем случае сеть замедлится в два раза.
...это статистическая атака. Там меряют не пакеты (тем более, что Tor их нормализует), а форму трафика: степень загруженности каналов, пики и прочее. Задержки в масштабе реального времени форму трафика не изменяют. Сеть (как Tor, так интернет в ряде случаев) и сама их достаточно накладывает, только на общую статистику это почему-то не влияет.
Вот именно, чтобы её переупорядочить, надо писать свою реализацию.
Угу, речь об этом. Входной буфер, кстати, тоже есть.
По хорошему, надо вообще отказываться от очередей в явном или не явном виде. От них все беды и атаки, и не только в Tor. Очереди должны быть или сильно сокращены или удалены полностью, но это невозможно в нынешнем виде. Релизацию контроля доставки нужно переносить на уровни клиента и/или краевого узла, и это возможно лишь после миграции на UDP транспорт.
Ну... я имел в виду не это. Здесь вы очень хорошо хватанули. Перевести абсолютно все компьютеры в мире на TPM – это не тривиально. Кроме того, даже пусть это будет и так, вера в невзламываемость логики физических схем сродни вере в невзламываемость ассемблерного кода. С кое-какими элементами того, как это делается можно ознакомиться в "игре в умные карты" от Киви Берда. А раз кто-то сможет утянуть глобальные ключи, значит он сможет построить программный эмулятор TPM. В итоге "защита" с его помощью будет выглядеть как "защита авторских прав с помощью DRM". Проблему можно решить, вводя уг. ответственность за модификацию кода программ, используемых на PC. Скорее это ближе пока к фантастике. Да, и не следует забывать, что на свете много стран. И одна страна не захочет, чтобы ключами к её TPM владела какая-то другая. А если одними и теми же сакральными ключами будут владеть все страны (а это слишком большое число), то кто-то их быстро и сольёт.
Допущение о публичной проверяемости железяки, к сожалению, выводит нас за рамки действующего мира и его правил. Нарушить проверяемость можно всегда, ибо музыку заказывает прежде всего власть, а внутри железки будет именно то, что она захочет.
Мне тоже не ясно. Я думаю, здесь всё чуть сложнее. Измеряется число пакетов, прошедших за какой-то промежуток времени (не обязательно совсем маленький). Раз все пакеты всё равно должны пройти по указанному маршруту, то усреднённая статистика пакетов, прошедших через измеряемые точки, не изменится. А из разности потоков и можно выудить, кто откуда пришёл. Для таких задач, полагаю, есть готовые модели по статистическому анализу. Моё предположение в том, что введение задержек не нивелирует возможность корреляций, а лишь несколько затрудннит их ценой существенного усложнения протокола, его реализации, и его производительности для конечных пользователей. Имхо, именно поэтому от этой полумеры и отказались. Интуитивные рассуждения о "задержках" здесь неприемлемы: нужно брать формальную строгую математику, и вычислять корреляции – это отдельная задача, требующая квалификации. Скорей всего, для конкретно тора её ещё никто не решал, чтобы дать ответ: на что конкретно и в какой степени повлияли бы эти корреляции. Btw, почему матмодели не очень перспективны в плане исследований на данном этапе – потому что много side-эффектов в тор и чисто технических тонкостей, полный учёт которых нетривиален. В частности, делая небольшие нюансы на чисто технической стороне дела, можно смущественно облегчить деанонимизацию. К примеру, ранее писали о том, что tor-трафик можно отличить от стороннего https-трафика из-за того, что горе-разработчики не подумали о точной его маскировке под https. Стороннему же математику разбираться с тонкостями реализации https, tcp/ip и прочего очень муторно, а без этого ажекватное исследование протокола невозможно, равно как и построение его модели. Да, ещё вспомнил, как, кажется, Мухтар, что ли, спрашивал у unknown'а по поводу обнуления какого-то счётчика для https. И вот оказалось что, типа в RFC-то не так, как обычно считают... эффект того же рода.
Раньше — да. Сейчас уже неактуально.
Тут ранее обсуждали внесение задержек для "пакетов". Если правильно догадываюсь, Гость применял такой перевод для обозначения cell. Кстати и выполненый cooshoo перевод спецификации, также трактует cell как пакет. Думаю это не самый лучший вариант для cell. Потому как не всегда может быть понятно из дискуссии, какие именно "пакеты" нужно придерживать.
Это просто комментарий к прочитанному :>
Здесь часть дискутирующих (я, например), никогда не разбирались с протоколом основательно, чтобы вообще понимать что есть cell, и т.п. Просто высказываются общие соображения. Лично я имел в виду под пакетами некие пакеты tcp-сессии (типа тех, что ловит tcpdump).
Атака на корреляцию – это название класса атак, некоторые[link8] из которых могут быть чувствительны и к малым задержкам.
cell можно переводить словом "ячейка".
Кажется, сам Роджер где-то приводил такие формулы:
Подробнее здесь: EndToEnd attacks[link9]:
Первоисточник не помню. То ли из работы взято, то ли из обсуждения в рассылке, то ли из черновика спецификации.
Все предложения, обсуждаемые здесь в предыдущих нескольких страницах (увеличение длины цепочки, введение случайных задержек, смешивание путей) уже неоднократно обсуждались с разработчиками и были отвергнуты.
См. дискуссию[link10] с Ником Мэттьюсоном, там даны его ответы, ссылки на FAQ здесь[link11] и заодно здесь[link12], на работы, в том числе на то как была полностью скомпрометирована сеть Crowd со случайно выбираемой длиной цепочек (один из предшественников проекта Tor).
SATtva верно заметил выше:
У кого-то есть серьёзная теоретическая модель? Готовая оформленная работа с опровержением моделей из предыдущих работ? Без неё ваши предложения рассматривать не будут. У разрабов уже похоже аллергия на рандомизацию и длину цепочек.
Непродуманные предложения по рандомизации траффика, увеличению или случайному выбору длины цепочки – одни из самых распространённых наивных предложений по улучшению, которые судя по работам, были отвергнуты ещё когда Tor разрабатывался как закрытый проект.
Может что-то из этого будет реализовано позднее, при более высоком уровне теоретических проработок, но пока это ничего не улучшает, скорее наоборот.
Впрочем, по указанным же ссылкам[link11]:
Видимо, проблема в том, что все лишь утверждают, что данные наивные улучшения не помогут анонимности. Однако, скурпулёзное изучение ранее опубликованных работ по теме и используемых в них моделей, доступно далеко не всякому из-за требования квалификации и/или времени. Было бы не дурно, если б кто-то на пальцах для непосвящённых объяснил, почему подобные предложения не улучшат тор. Что касается end-to-end атак, я вижу только один прямой аргумент: атака пересечения, которая быстро позволяет установить, общается ли A и B. Однако, только из этого не следует наивность всех предложений по {}.
И что же может ухудшить рандомизация очереди? А вот кое-что (при атаках, чуствительных к малым задержкам) улучшить может.
Судя по этому высказыванию, противники удлиннения цепочек – пессимисты. :)
А как пессимисты, они должны учитывать возможность сотрудничества авторов Tor c властями, чем и может объясняться их нежелание усиливать защиту Tor. :(
Которыми? Из: Великобритания, США, Австрия, Германия. Может кого-то пропустил, но для начала сойдет. Выбирайте? Люди из этих стран, являются разработчиками на полный рабочий день. Средства на оплату их труда идут из фонда НКО "Тор Проект".
У вас есть ссылки на научные статьи или исследовательские работы, которые решали бы описанные ранее в этом топике задачи, и которые разработчики намеренно игнорируют?
Надгосударственными, глобальными (кстати, управляют, в том числе и через НКО)
Пока что только подозрения.
Так Мэтьюсон буквально на пальцах и объяснил почему следует. Атака end-to-end – самая эффективная. Если невозможно защититься от неё (а в сетях типа Tor это так и есть), то и от всех остальных, которые гораздо более затратны защищаться смысла нет.
Рандомизация, удлинение цепочек пока реально могут защитить против менее эффективных атак, с менее эффективным результатом, при неисследованных до конца теоретических параметрах и при сложностях в реализации при скоростных соединениях.
С другой стороны, удлинение цепочек, смешивание потоков приведёт к тому, что tor-трафик пройдёт через большее число узлов. Реально анонимность это не повысит, а число точек съёма трафика увеличит.
Скорее всего, многие просто думают по аналогии с почтой (римэйлерами), где все письма делятся на пакеты перемешиваются и задерживаются сутками, иои рэндомно или по мере накопления пула. Вот там никакой статистический анализ практически невозможен и даже защита от глобального наблюдателя практически гарантирована, и там чем больше длина цепочки, тем лучше (хотя потеря пакетов и время доставки тоже снижаются). Но когда проектируется сеть типа Tor – с TCP-соединением реального времени и интерактивными протоколами, она изначально не может иметь таких свойств анонимности и проектировать её надо по другому.
Ну скачали с сети 1.5 Mb за 3 мин с характерными распределениями по времени, а на другом конце примерно таже картинка трафика, только более смазанная и огрублённая по размерам пакетов. Не нужны там точности до малых задержек. Ну соберут 1000 образцов вместо 10 для достоверной корреляции. Наверняка авторы (и не они одни) модели строили и считали более точные цифры и поняли, что это всё неэфективно.
В открытых исследованиях хорошо бы сначала разобраться, а потом строить подозрения насчёт того, что якобы скрывают.
А если чат (с репликами по 100 байт раз в минуту), да ещё оба сидят в крупных локальных сетях?
По поводу такого узкого канала как чат не знаю, но на обычном просмотре страниц с графикой (даже не мегабайтной) это уже неэффективно.
Также надо учитывать, что активный end-to-end атакующий может сам вносить задержки в трафик или портить пакеты и смотреть на изменение статистики на другом конце.
По моему качать и чатить можно считать разными классами задач. Поскольку траффик чата невелик, вполне реально построить специально чатовую анонимизирующую сеть (или добавить соответствующий режим в Tor) с гораздо лучшими показателями анонимности, например используя непрерывный покрывающий траффик.
По поводу гвардов-шпионов, без них всё равно хуже:
Tor path spec.[link13]
См. пункт "5. Guard nodes"
По поводу чатов. Сеть tor – универсальный транспорт для TCP, но скорее с прицелом на браузинг. Стоит ли усложнять протокол для любителей чатов? Может для них наоборот покрывающий трафик не нужен из-за узкого канала?. Кому-то может нужны скрытые форумы или особые режимы для покрывания трафика из Tor в римэйлеры или ещё что. Будут ли это всё вносить в протокол? Как управлять включением-отключением этих опций?
Вероятно не стоит, вероятно лучше под каждую из задач (чат, броузинг, файлообмен,...) иметь свою специально заточенную программу, просто можно было-бы объединять их в один дистрибутивный комплект.
Касаемо чата кажется реальным сделать защиту и от глобального наблюдателя.
... и сделать у них неотличимый снаружи формат ячеек (cells)
Поделитесь секретом :)
"End-to-End" наблюдатель – это лишь частный случай глобального наблюдателя.
Против глобального наблюдателя TCP-соединение сделать анонимным практически нереально (или сделать постоянный покрывающий трафик всего и всех).
Против глобального наблюдателя эффективны только неинтерактивные протоколы с односторонней медленной отправкой сообщений
(почта через римэйлеры), с накоплением пакетов в пулах, когда можно накапливать необходимое число пакетов неопределёно долго (до суток) и добавлять недостающие рэндомные пакеты в пул.
И то, против римэйлеров имеются другие атаки – активный атакующий может вбрасывать кучу пакетов и т.д. Это всё уже оффтопик для Tor'a.
...и транслировать их через одни и те же узлы. И по одному протоколу. Ибо в противном случае получите просто разные сети (список узлов, по крайней мере в реальном Tor, а не в гипотетических чат-сетях, открыт и общедоступен) с разным контингентом пользователей, т.е. с заведомо меньше анонимностью.
... а также общие библиотеки времени исполнения и межпрограммный взаимообмен информацией, а после (для оптимизации) добавить разделяемую память и единый исполняемый файл. ;)
Именно, только не всего и всех, а лишь чата. Со скоростью 100 байт в минуту очень даже реально.
Гость (20/01/2009 14:03), а если противник перекроет от Вас трафик в сеть, а спустя пару минут увидит, что некий подозрительный юзер в чатруме отвалился по таймауту (причём такая картина будет стабильно воспроизводиться), какую информацию это ему даст и чем покрывающий трафик (в любых объёмах) здесь поможет?
Поскольку Tor уже раскручена, неплохо бы к ней присоединиться :)
Протокол тот-же должен быть только снаружи, внутри может быть и другой.
Уж лучше тогда "присоединиться" (сделать патч) к eMule. И весь Tor заодно – будут десятки миллионов серверов :)
Не кладите все яйца в одну
вагинукорзину, выходите в сеть сразу через нескольких провайдеров, включая соседских, сотовых, WiMax'овых, спутниковых,...Для хождения по
болотуопасным местам нужны боты! Умные боты, которых не сразу отличишь от глупого человека.Кроме того, пишите под Гостем :)
Если у вас случился перебой в сети у всех ваших провайдеров одновремено, ложитесь на дно, рвите когти, принимайте ампулу с ядом,.., в зависимости от ситуации.
На такой случай не ходите в чат один, пусть вас прикрывают товарищи с других IP.
Против отключения от сети лучше не чат а форум.
Если форум, то какой тогда смысл в протоколе реального времени? Используйте список рассылки (с веб-архивом) и публикуйте в него через ремэйлеры. Будет защита даже от глобального наблюдателя.
А быстро реагирующий форум можно использовать как чат. ;)
Вопрос: я сижу в Tor и изредка обновляю страницу https://check.torproject.org/?lang=en-US&small=1 и вижу "Congratulations. You are using Tor."
Иногда мне пишет "Sorry. You are not using Tor.", хотя ip-адрес показывает не мой, левый.
Это происки врагов? Кто-то подменил узел Tor?
Или просто новый узел ещё не добавлен в список, по которому проверяет этот checker?
peergynt, возможно вы стали объектом атаки unknown'а. Сеть тор централизована, владеющий ключами для управляющих директорий может полностью контролировать ваш трафик. Вы можете доверять тору, а он вам нет. Или противником может просто тайно эксплуатироваться КК.
Да. Или этот узел сидит на двух IP, один из которых используется для входящих соединений (и опубликован в консенсусе), а другой — для исходящего трафика.
В текущем протоколе тор эта атака много менее практична чем альтернативы (afair).
Да, только это очень большое число ключей, которыми в общей сложности владеют много независимых людей. Если они все сговорятся, то да (как раз параллели с цитатой из соседней ветки).
Ну или звездолёт-телепортатор. Вероятность того и того примерно одинакова на текущий момент.
Достаточно сговориться владельцам четырёх из шести DA-узлов, что неоднократно признавал сам Роджер. Иерархия доверия ко всем остальным ключам строится от них.
А атакующие уверены в том, что именно нужный пользователь в имено нужный момент получит предназначенную инфицированную статистику? Клиент тора проверяет текущие ключи, которые выдаются arair на неделю, подписываясь основными ключами не то DA, но то ещё и роджеровскими. Т.о. в общей схеме получается больше 4х действующих независимых ключей. Имею в виду, что интересен-то как раз пример воспроизводимой атаки, а не случай "может прокатить лишь раз при невероятных обстоятельствах и везучести атакующего".
Верно, если ещё учесть что сейчас только двое владельцев корневых узла "не зависимы". Это одиночка шифропанк и группа ССС.
Вариант, при котором клиент вынужден запускаться с пустым кешем, очевидно выполним. Это один из наиболее верных и быстрых способов атаковать по unknown'у. На форуме уже бились за эту тему, и доказали что обнуления кеша возможно, даже при постоянном использовании тора.
И много этих ремэйлеров осталось?
имхо, все проще.
Известно, что для для ДНС резолва ТОР поддерживает протокол Socks 4A, который отличается от Socks 4 тем, что для соединения можно указывать не только IP адрес, но и имя хоста, которое в таком случае резолвится уже сокс сервером (в данном контексте ТОРом) "на его стороне".
Но не все программы и соксификаторы поддерживают эту подверсию протокола, некоторые только Socks 4 и Socks 5, поэтому в таком случае приходится пользоваться версией 4. (т.к. 5-ю ТОР не поддерживает).
И мне самому приходилось делать таким образом, прекрасно понимая, что в этом случае провайдер знает какие сайты я посещаю, т.к. все хосты резолвятся ДНС сервером провайдера. Естессно, в таком случае, пров только знает адреса сайтов, но не знает передаваемую информацию.
Tor может подерживать полное заворачивание всего исходящего трафика для TCP и UDP-DNS, если в системе есть фильтр пакетов, который может это сделать. По крайней мере в Unix это есть. Возможно и для Win есть такие программы.
unknown
Я давно не пользовался ТОРом (тормозит), поэтому может что-то уже изменилось.
Я к тому, что в случае ТС мог быть именно такой случай, когда пров по ДНС запросам видит кто куда ходит...
С чего бы это? Даже привокси ранее не поддерживающая сокс5, научилась. В то время как тор изначально (с самого начала своего существования) поддерживает все версии сокс протокола динамически, как пожелает вопрошающий сокс-клиент так и будет.
Плюс сейчас имеет днс-прокси, и транспарентные прокси в системах где это умеют. Трудно в настоящее время чему-либо утечь мимо тор.
Вы что-то путаете, та версия, которой я пользовался не поддерживала Socks 5
Возьмите исходники и поглядите, или пройдитесь по истории изменения кода. Покажите, где тор, зная сокс4а, не поддерживал или только начал поддерживать сокс5?
Вот что было найдено мною, подходящее хоть немного под описание "не поддерживает" сокс5:
Единственный раз когда была сломана поддержка (и значит не работал) сокс5 пришелся на релиз кандидат 0.0.9rc1, было это в 2004 году, но выпущенная буквально днем позже версия это исправила.
Однако вплоть до 2006 года тор имел проблемы при общении с кривыми реализациями сокс-клиентов. Вот запись:
Проблема кривых реализаций сокс-клиентов это ошибка тора?
Мысль моя в том, что не повод перекладывать проблему утечек на тор, из-за "неподдерживаемости" им сокс5.
Кроме того, в данном форуме (если пропарсить архив), много раз указывалось что желательно в сокс-клиенте наличие именно 4а, потому как 5ый может реализован в свободном стиле — "где хочу там и выясняю ip-адреса для хостов".
Да, обычно это сделано в следующем виде:
- Клиент обращается к DNS напрямую.
- Если удалось — получает IP-адрес, который отдаёт в Tor.
- Если не удалось, запрашивает DNS-resolve через сокс-прокси (т.е. через Tor).
Ну, и, как следствие, в подавляющем большинстве случаев получаем утечку запросов. Хотя технически ничто не мешает делать их все через Tor, как делает Firefox с включенной опцией network.proxy.socks_remote_dns.Сценарий, описанный ТС, довольно фантастичен и по стилю изложения смахивает на тонкий троллинг. Вы уж извините, если это в действительности не так. С другой стороны, данный сценарий "деанонимизации" технически реализуем: дело в том, что технически Tor защищает лишь от одной модели атаки – поиск по выходному трафику Tor реального источника, но в реальности моделей куда больше – от обсуждаемого везде сценария доказательтсва того, что Алиса общается с Бобом, до поиска по известному источнику его выходного трафика. Ничто не мешает провайдеру вставить в трафик Tor, который даже в новых версиях клиента продолжает вопить "я трафик Tor, а не HTTPS", задержки или иные отклонения, которые будут зафиксированы уже после выходного узла. Данный сценарий, кстати, весьма кстати подходит под существующий опыт легального перехвата и уже реализован в некоторых активных системах легального перехвата. Поэтому, прежде чем говорить об анонимности Tor, ИМХО, надо пояснить, какая именно модель анонимности интересует.
Чем подтвердите?
Описанный сценарий был в действительности. Факт остается фактом – соединение по сокс5 не работало, не знаю кто в этом был виноват, сокс клиент нормально работал с обычными соксами... Верю вам на слово, что это не проблема ТОРа, но имхо не важно на кого свалена вина, в конечном итоге это все равно проблема пользователя...
Как это проявлялось?
Смогли бы Вы вспомнить названия приложений и их версии у которых произошли описанные несовместимости с тором (версию тор неплохо было бы узнать, хотя не столь важно)? Возможно эта проблема до сих пор существует, или Вы использовали тор действительно очень и очень давно.
Поставил TOR, ради эксперимента. Первый IP узла он мне назначил... скажем так, красивый. (В логах посещений pgpru.com должен был остаться) Правда я dns и privoxy не настраивал, подключил браузер через сокс и полез :)
Зато теперь я знаю что такое "забанили в гугле": sorry.google.com
Забанили в гугле?
http://www.scroogle.org/
Может совпадение. IP этот в Google хорошо известен – 66.230.230.230
Гугл часто банит исходящие узлы сети tor, так как через них долбится много всякой троянской нечисти.
А есть ли способ исключить из цепочки все региональные узлы, чтобы уменьшить опасность регионального наблюдения?
Перечислить все страны, кроме своей в одной специальной опции (есть такая в новых версиях). М.б. есть опция чтобы проще сделать.
Не подскажите адресок перечня всех настроек TOR (желательно на русском)?
Я тоже видел свой IP-шник при подключении через TOR и JAP к узлам, собирающим информацию об IP-адресе пользователя в том случае, если в разделе Содержимое не была сброшена галка напротив JAVA (всё делалось в XP). После отключения активного содержимого исчезала и информация об адресе. Соответственно в firewall'e надо наложить правила на javaw.exe, тем более, что при установке TOR'а специально предупреждают о необходимости отключать активное содержимое, тереть куки и историю
доброго времени сутом всем здешним знающим обитателям!! Простите за глупый вопрос дилетанта... Я прочитала ваши обсуждения и ничего непоняла, кроме одного знакомого номера который "хорошо известен – 66.230.230.230" делов том что на нашем форуме образовалась непонятная ситуация когда несколько разных пользователей "имеют" один и тот же IP адрес, из-за чего уже случилась немала неприятных инцендентов. Может быть кто-нибудь из знатоков сможет объяснить мне доступным языком (для юзера, ламера и чайника) что у нас происходит и как с этим бороться и стоит ли, потому что боюсь уже пострадали многие невинные пользователи.
Заранее спасибо!
Возможно, люди используют один и тот же прокси, либо географически привязаны к одному и тому же провайдеру (ничего в этом странного нет – это естественное положение вещей). Как бороться – вводить регистрацию, удалять сообщения. "Банить по IP" может оказаться контрпродуктивно. Зависит и от контингента. Полностью избавиться от навязчивых посетителей нельзя никак (если только запретить регистрацию новых пользователей вообще) – такова технологическая сущность интернетов...
PS: следите за орфографией. К тому же, сообщение не по теме данной ветки вообще.