> Никакого ssl, а значит рано или поздно пароль будет отснифан на транзитных нодах Для hidden service'ов (т.е. сайтов .onion) SSL не нужен, т.к. весь трафик внутри сети Tor и так зашифрован. Его невозможно не только поснифать, но даже и определить откуда он и куда.
Более того, при обращении к .onion-сайту между вами и сервером находится как минимум 7 (СЕМЬ) промежуточных узлов (т.к. и клиент и сервер устанавливают стандартный 3-х узловой путь к случайно выбранному "рандеву-узлу"). Каждый из этих узлов знает адрес только предыдущего и следующего узла в цепочке. Это, кстати, является причиной того, что .onion сайты так тормозят.
Про деанонимизацию 2008 г. - это оказалось описанием теоретической возможности атаки на основе компьютерной симуляции сети Tor. На реальной сети эта атака не работала даже в 2008. Причем даже теоретическая версия атаки предполагала только перехват обращений через Tor к обычным сайтам, а не к .onion.
Вообще, .onion-сайты очень и очень хорошо защищены, тот же самый silk road может находится на любом из около 500 тысяч подключенных к Tor клиентов (http://metrics.torproject.org/users.html) и чтобы узнать на каком - надо чтобы у атакующего был доступ к подавляющему большинству из 2500+ Tor-узлов, расположенных по всему миру.
Насчет ПХП - все эти сайты скорее всего крутятся в виртуальной машине, трафик из которой жестко файрволлом хост-машины перенаправляется через Tor. То есть даже при взломе пхп и получении рута на машине реальный адрес хоста узнать будет невозможно.
Поисковик xycpusearchon2mc.onion в принципе выдает только одну страницу результатов, по любому запросу.
Я настолько давно читал обзор того как устроен Tor, что забыл очень многое и некоторые из Ваших утверждений мне не очвидны:
> Для hidden service'ов (т.е. сайтов .onion) SSL не нужен, т.к. весь трафик внутри сети Tor и так зашифрован. > Его невозможно не только поснифать, но даже и определить откуда он и куда. > Более того, при обращении к .onion-сайту между вами и сервером находится как минимум 7 (СЕМЬ) промежуточных узлов > (т.к. и клиент и сервер устанавливают стандартный 3-х узловой путь к случайно выбранному "рандеву-узлу"). > Каждый из этих узлов знает адрес только предыдущего и следующего узла в цепочке.
Давайте я опишу выдуманную, на мой взгляд, не слишком дорогую атаку, а Вы меня покритикуете:
Ставим relay узел на очень быстрое соединение с сетью. Наверняка скорость работы релея является важным фактором в выборе маршрута, поэтому мы так повышаем свои шансы стать узлом участвующим в трафике. Далее пишем весь трафик и пытаемся его расшифровать при помощи заранее предвычисленных массивов данных (аналогично тому, как подбирают пароли подходящие к хешам при помощи гигазов заранее вычисленных хэшей). Как только у нас получилось подобрать что-то используем это к хосту, который предоставляет tor mail или tor messaging сервисы - .onion хостов по сравнению с полным объёмом сети мало и нам не нужно затруднять себя - проще попробовать пароль на всех имеющихся .onion хостах с нужными нам сервисами.
> Это, кстати, является причиной того, что .onion сайты так тормозят. Некоторые не так уж и тормозят - вполне терпимо.
> Про деанонимизацию 2008 г. - это оказалось описанием теоретической возможности атаки на основе компьютерной > симуляции сети Tor. На реальной сети эта атака не работала даже в 2008. > Причем даже теоретическая версия атаки предполагала только перехват обращений через Tor к обычным сайтам, а не к .onion. Спасибо за краткое резюме.
> Вообще, .onion-сайты очень и очень хорошо защищены, тот же самый silk road может находится на любом > из около 500 тысяч подключенных к Tor клиентов (http://metrics.torproject.org/users.html) > и чтобы узнать на каком - надо чтобы у атакующего был доступ к подавляющему большинству > из 2500+ Tor-узлов, расположенных по всему миру. У меня большие сомнения, что это нельзя, при желании и возможностях на уровне "гебня отдельно взятой страны", сузить до региона, а затем, постепенно, до количества, которое можно обработать силами административно-полицейского характера используя местные аналоги СОРМ. То есть, грубо говоря, когда количество потенциальных виновных снизится до пятисот можно инкриминировать всем этим деятелям участие в тероризме и на этом основании получить ордер на технические меры . ) Вот только это всё равно не дешево. )
> Насчет ПХП - все эти сайты скорее всего крутятся в виртуальной машине, > трафик из которой жестко файрволлом хост-машины перенаправляется через Tor. > То есть даже при взломе пхп и получении рута на машине реальный адрес хоста узнать будет невозможно. Эти утверждения могут быть и правдой и ложью в каждом отдельно взятом случае. Получив рута в виртуалке можно: *. копать в сторону эксплойтов к самой виртуалке. На моей памяти, о чем-то подобном писала Рутковска в своём блоге по мотивам Xen. *. думать в сторону встраивания в педоконтент эксплойтов, предназначенных для атаки на оператора педосайта и на его клиентов - они там многие любят "новые материалы", а значит откроют залитый файл своей смотрелкой картинок и видео.
Причем, второй вариант атаки можно пробовать даже не имея удаленного доступа ни к guest ни к host системе.
На мой взгляд с педофилами выгодно бороться публично, но вот реально потратиться на поиск никто не хочет. =)
> Поисковик xycpusearchon2mc.onion в принципе выдает только одну страницу результатов, по любому запросу. Спасибо, не знал. Какое-то странное ограничение.
ЗЫ: вообще говоря, если долго сидеть на берегу - можно дождаться взрыва сверхновой - солнце не вечное. ;)
> Ставим relay узел на очень быстрое соединение с сетью. Наверняка скорость работы релея является важным фактором в выборе маршрута, поэтому мы так повышаем свои шансы стать узлом участвующим в трафике.
Все верно, в Tor используется простенький load balancing, благодаря которому узлы с большей пропускной способностью чаще используются при построении пути.
> Далее пишем весь трафик и пытаемся его расшифровать при помощи заранее предвычисленных массивов данных (аналогично тому, как подбирают пароли подходящие к хешам при помощи гигазов заранее вычисленных хэшей).
Вот здесь атака захлебнется, т.к. rainbow tables, которые вы описываете, для взлома TLS (который используется для шифрования всего внутрисетевого трафика Tor) бесполезны. Наглядный пример: аналогом rainbow tables для алгоритма RSA 512-бит будет таблица всех простых чисел до 2^512. Если допустить, что для хранения данных нами используется накопитель, где 1 петабайт умещается в 1 грамм, то накопитель превысит массой лимит Чандрасекара и схлопнется в черную дыру :)) Ну а в TLS используется ЕМНИП как минимум RSA-1024, а может даже и RSA-2048 бит.
Вообще, на безопасности TLS (который используется в том числе и в HTTPS) основана вся инфраструктура банковских транзакций, оплаты кредитными картами через интернет и т.п. Если взломают RSA, то рухнет считай вся электронная коммерция.
На этом собственно и основывается безопасность Tor - из-за того, что TLS взломать невозможно, то для того, чтобы расшифровать трафик и даже для того, чтобы узнать откуда и куда этот трафик идет, взломщику нужно получить контроль над всеми тремя relay-ями, через которые проходит путь. Один или даже два подконтрольных узла ничего не дадут.
> У меня большие сомнения, что это нельзя, при желании и возможностях на уровне "гебня отдельно взятой страны", сузить до региона
На практике наиболее реальной против .onion-сайта является такая атака: если гебня контролирует всех провайдеров данного региона, то можно следить за всеми соединениями с сетью Tor. И дальше, если каждый раз, когда мы запрашиваем с silk road файл размером 100 мб, от некого IP-адреса уходит в сеть Tor 100 мб зашифрованного трафика, то этот IP с большой вероятностью и является этим самым silk road. Проблема (для атакующего) в том, что эта атака не более чем метод исключения. Т.е. даже полностью контролируя весь российский сегмент интернет, мы можем с определенной (большой) вероятностью определить, что silk road в России не находится. Допустим ФБР сделает то же самое и определит, что в Америке его тоже нет. Что дальше? Более того, на проведение такой атаки (корреляции трафика) нужно время, как минимум несколько дней (а в цивилизованных странах - еще и распоряжение суда и т.п.), а искомый нами hidden service может хоть каждый час прозрачно менять свое расположение, подключаясь к сети Tor то через прокси на Багамах, то через VPN на Мальдивах и т.д.
Но, разумеется, такого рода атака на порядки осуществимее, чем собирать кластер суперкомпьютеров и ломать несколько тысяч лет RSA.
> думать в сторону встраивания в педоконтент эксплойтов, предназначенных для атаки на оператора педосайта и на его клиентов
Вот это, на мой взгляд, наиболее реальный способ атаки. Им же кстати воспользовались прошлой осенью Anonymous, которые в hidden wiki разместили ссылку на модифицированный ими плагин Torbutton (используется для максимизации анонимности при выходе в Tor с Firefox), выдав его за "апдейт". Этот Torbutton отправлял анонимусам реальные айпишники пользователей. Короче как и в любой системе безопасности, человеческий фактор оказался самым слабым звеном :)
>> Ставим relay узел на очень быстрое соединение с сетью. Наверняка скорость работы релея является важным фактором в выборе маршрута, поэтому мы так повышаем свои шансы стать узлом участвующим в трафике. >Все верно, в Tor используется простенький load balancing, благодаря которому узлы с большей пропускной способностью чаще используются при построении пути. Сразу вопрос, пардон, что не в документацию - где трафик оказывается дешифрован окончательно - только на точке получателе локальным тор-стеком протоколов?
>> Далее пишем весь трафик и пытаемся его расшифровать при помощи заранее предвычисленных массивов данных (аналогично тому, как подбирают пароли подходящие к хешам при помощи гигазов заранее вычисленных хэшей). >Вот здесь атака захлебнется, т.к. rainbow tables, которые вы описываете, для взлома TLS (который используется для шифрования всего внутрисетевого трафика Tor) бесполезны. Наглядный пример: аналогом rainbow tables для алгоритма RSA 512-бит будет таблица всех простых чисел до 2^512. Если допустить, что для хранения данных нами используется накопитель, где 1 петабайт умещается в 1 грамм, то накопитель превысит массой лимит Чандрасекара и схлопнется в черную дыру :)) Ну а в TLS используется ЕМНИП как минимум RSA-1024, а может даже и RSA-2048 бит. Спасибо, действительно наглядно.
>Вообще, на безопасности TLS (который используется в том числе и в HTTPS) основана вся инфраструктура банковских транзакций, оплаты кредитными картами через интернет и т.п. Если взломают RSA, то рухнет считай вся электронная коммерция. А вот тут - подробнее - как насчет атак на распространение ключей? Если аналогия верная, то получается, что кто-то генерирует сертификаты, которые уже потом используются для шифрования и распространения траффика. Кого ломать чтобы поиметь доверяемые сертификаты и подставить себя для фищинга педопорно?
> На этом собственно и основывается безопасность Tor - из-за того, что TLS взломать невозможно, то для того, чтобы расшифровать трафик и даже для того, чтобы узнать откуда и куда этот трафик идет, взломщику нужно получить контроль над всеми тремя relay-ями, через которые проходит путь. Один или даже два подконтрольных узла ничего не дадут. Я уже проглядывал мельком статьи по бедам современной реализации TLS и сделал вывод, что главная беда - невменяемый PKI. Как с этим в тор? Нет ли у 'местного подразделения кровавой гэбни'(tm) возможности атаковать административную структуру?
>> У меня большие сомнения, что это нельзя, при желании и возможностях на уровне "гебня отдельно взятой страны", сузить до региона >На практике наиболее реальной против .onion-сайта является такая атака: если гебня контролирует всех провайдеров данного региона, то можно следить за всеми соединениями с сетью Tor. > И дальше, если каждый раз, когда мы запрашиваем с silk road файл размером 100 мб, от некого IP-адреса уходит в сеть Tor 100 мб зашифрованного трафика, то этот IP с большой вероятностью и является этим самым silk road. Как вариант конечно сойдет, но по моему слишком накладно.
> Проблема (для атакующего) в том, что эта атака не более чем метод исключения. > Т.е. даже полностью контролируя весь российский сегмент интернет, мы можем с определенной (большой) вероятностью > определить, что silk road в России не находится. Если одна гебня сотрудничает с другой, то так можно дойти до гео-региона и AS прова в нем. =) Ну а дальше локальная гебня включает свой вариант СОРМ и вася кот. ;)
> Допустим ФБР сделает то же самое и определит, что в Америке его тоже нет. Что дальше? С учётом того, что искомый .onion может быть в стране с законами сильно отличными от наших - есть шанс уперется в чисто юридические проблемы. Ну а дальше уже давить на региональные власти всем миром.. А больше никак. )
> Более того, на проведение такой атаки (корреляции трафика) нужно время, как минимум несколько дней > (а в цивилизованных странах - еще и распоряжение суда и т.п.), в цивилизованных странах, включая США и РФ, есть замечательные статьи о борьбе с тероризмом. В конце концов, вся эта херь с "мы не имеем права" благополучно игнорируется когда это действительно нужно. Вывод - ловить педопорно претстижно, но не особо нужно - и без того проблем хватает. Не? Я к тому, что в тех же штатах следак (или кто там у них в системе оформляет отношения с разрешителями) может при некоторой ловкости без всякого мошенничества предъявить обвинения по одной статье (тероризм), получить ордер, а потом, собрав улики, по факту предъявить доп. обвинение по другой статье (педопорно). Я не прав? ?-)
> а искомый нами hidden service может хоть каждый час прозрачно менять свое расположение, подключаясь к сети Tor то через прокси на Багамах, то через VPN на Мальдивах и т.д. Есть более дорогое (по потерям из разряда недополученная прибыль), но и более эффективное решение. Обеспечиваем одновременную потерю связности в реальном интернете с мониторингом нужного .onion из разных мест. Повторяем последовательно, вплоть до локализации до отдельной юрисдикции, а далее до отдельно AS, после чего обвиняем в тероризме и получив ордер включаем все возможности местного аналога СОРМ. Кстати, буквально недавно у всех кроме корбины в мск не работал гугль.. Истинные причины никем не проверены.=)))
> Но, разумеется, такого рода атака на порядки осуществимее, чем собирать кластер суперкомпьютеров и ломать несколько тысяч лет RSA. OK, не будем ломать сферического коня в вакууме - займемся недостатками имплементации. =)
>> думать в сторону встраивания в педоконтент эксплойтов, предназначенных для атаки на оператора педосайта и на его клиентов >Вот это, на мой взгляд, наиболее реальный способ атаки. Да, один из наиболее вероятных способов. Есть еще варианты, я думаю. =)
>Им же кстати воспользовались прошлой осенью Anonymous, которые в hidden wiki разместили ссылку на модифицированный ими > плагин Torbutton (используется для максимизации анонимности при выходе в Tor с Firefox), > выдав его за "апдейт". У меня сразу вопрос - при наличии request policy и noscript с политиками типа белый список - разве торбаттон еще зачем-то нужен?
> Этот Torbutton отправлял анонимусам реальные айпишники пользователей. > Короче как и в любой системе безопасности, человеческий фактор оказался самым слабым звеном :) отличия жизни от красивых лекций шифропанков в том числе в том, что бьют не по IP/паспорту, а по лицу. )
Я к тому, что вместо того, чтобы кричать ужас-ужас, граждане запретители могли бы открыть фонд по сбору денег на оплату услуг частных forensic компаний или, что тоже неплохо объявить существенную награду за данные, которые помогут найти реального педопорно изготовителя. Но нет - вопить "запретите им" куда как дешевле. =)
Вон жидомассоны(tm) после захвата заложников на олимпиаде заказали заказчиков теракта, и ниче - ща даж фильм можно посмотреть про крутость спецслужб отдельно взятой относительно молодой страны. ) Они, кстати, в прошлом или позапрошлом году скиднеппили из УА взрослого палестинского дядю и ниче - все утёрлись. ) Наши, в своё время, в Катаре, кажется, сработали более топорно - спалили абрека-террориста вместе с машиной, но, почему-то, решили, что "местное кровавоеГБ"(tm) будет уважать экстерриториальность здания посольства, не обеспеченную полком "военных красивых-здоровенных"(tm). )
Смысл в том, что кракер ВасяПупкин не связан законами вообще, частные forensic могут иметь по месту открытия компании ограничения на деятельность полегче, чем "местная кроваваяГБ"(tm) вынужденная для публики казаться вмеру белой и пушистой. =) Ну а уж имея ip и украденный пароль к криптодиску - дело отдельно взятого следака подставить саспекта так, что вполне легитимной для суда окажется сказка о том, что пароль де получен от подельника. =)
Я, как и многие другие люди, с удовольствием поучаствоавал бы в мозговом штурме по отлову педопорно провайдеров, но вот не предлагают.) Из чего я делаю вывод, что, на самом деле это не так уж и необходимо. )
> Вывод - ловить педопорно претстижно, но не особо нужно - и без того проблем хватает. Не?
Получается так. Безопасности государства файлообменники с педопорно не угрожают. Из-за того, что они скрыты в глубине сети Tor, среднестатический избиратель об их существовании даже не догадывается и пожаловаться властям не может. СМИ эту тему тоже особо не поднимают.
> У меня сразу вопрос - при наличии request policy и noscript с политиками типа белый список - разве торбаттон еще зачем-то нужен?
Теперь нет, сейчас Tor распространяется в виде Tor Browser Bundle, который уже включает в себя модифицированный Firefox, в котором отключен Java, Flash, встроен Noscript, отключена история, кэш, изменен User-Agent, чтобы не выдавать никаких сведений о системе и т.п. А раньше для этого использовался плагин Torbutton, с помощью которого можно было быстро включить/выключить использование Tor в браузере. Это было менее защищено чем теперешний вариант (отдельный браузер для Tor), т.к. с помощью Javascript, например, можно было передать данные между Tor и не-Tor сессиями.
> где трафик оказывается дешифрован окончательно - только на точке получателе локальным тор-стеком протоколов?
Если речь идет о доступе к обычному сайту через Tor, то полностью (т.е. известен адрес получателя, адрес отправителя и содержимое) трафик дешифрован только у нас на компьютере. После того того, как запрос ушел в Tor: 1-ый relay в пути знает наш адрес и адрес 2-го relay (но не знает содержимого трафика и кому он предназначен) 2-ой relay знает только адрес 1-го relay и адрес Exit node (т.е. не знает ни содержимого, ни адресов) 3-ий relay (Exit node) расшифровывает содержимое трафика и адрес получателя (но не знает нашего адреса)
Если через Tor мы обращаемся к HTTPS сайту, то "расшифрованное" Exit node'ом содержимое окажется зашифрованным TLS-потоком, т.е. в этом случае окончательно его узнает только тот сайт, к которому мы обращаемся. В Tor Browser Bundle кстати встроен плагин, который автоматом перенаправляет запросы на HTTPS версию сайта, если такая есть (например http://google.com -> https://encrypted.google.com). Иначе - Exit node сможет снифать трафик.
В случае доступа через Tor к .onion-сайту трафик нигде полностью не расшифрован. Ни одной точке сети не известен одновременно и адрес .onion-сайта и адрес клиента.
> Нет ли у 'местного подразделения кровавой гэбни'(tm) возможности атаковать административную структуру?
Для функционирования сети клиенту Tor нужно знать адреса всех открытых relay-узлов (есть и закрытые - для обхождения блокировки Tor в какой-либо стране). Этот список хранится на т.н. Directory servers, которых сейчас восемь штук. Айпишники и публичные ключи этих серверов прошиты в клиент Tor. Теоретически, если гебня получит доступ к этим серверам, раздобудет их приватные ключи и запустит 2500 своих подконтрольных релеев (чтобы пользователи не заметили разницы в количестве), то на некоторое время весь Tor окажется у них под колпаком.
>> Нет ли у 'местного подразделения кровавой гэбни'(tm) возможности атаковать административную структуру? >Для функционирования сети клиенту Tor нужно знать адреса всех открытых relay-узлов (есть и закрытые - для обхождения блокировки Tor в какой-либо стране). > Этот список хранится на т.н. Directory servers, которых сейчас восемь штук. >Айпишники и публичные ключи этих серверов прошиты в клиент Tor. > Теоретически, если гебня получит доступ к этим серверам, раздобудет их приватные ключи и запустит 2500 своих > подконтрольных релеев (чтобы пользователи не заметили разницы в количестве), > то на некоторое время весь Tor окажется у них под колпаком. Дорого, но осуществимо.
Вот только нахрен нужен вообще весь tor? Нужен конкретный tor клиент и конкретный .onion .
1. Допустим, атакует "кровавая гэбня"(tm). Например, для разнообразия, штатовская, причем сговорившаяся с произвольной другой "кровавой гэбней"(tm), например, нашей или "демократичной европы"(tm). Допустим, правдами и неправдами получены публичные ключи всех directory server'ов.
2. Для большой вероятности, что трафик данного .onion и данного клиента пойдет через нас ставим в стране пребывания данного .onion/клиента самые быстрые релеи. (Допустим мы уже вычислили в какой стране сидит данный .onion, например устроив серию кратких потерь связности между точками пиринга обсуживающими отдельные страны, ну или более тихим и прозрачным долгим способом корреляции трафика).
При этих двух допущениях - можно ли (и как) атаковать конкретного tor клиента и конкретный .onion с целью: a) выявления его обычного ipv4 адреса. b) дешифровки его tor трафика. c) подмены destination tor трафика фишинговой обманкой
Пункт c) можно использовать с последующим перенаправлением на реальный .onion по факту ввода паролей, как это часто бывает у фишинговых обманок.
Тут два разных вектора атаки. Если у нас есть контроль над всеми восемью directory servers (которые, кстати, расположены в разных странах), то это надо использовать именно для того, чтобы заменить список релеев своими и временно, пока все не опомнились, снифать весь Tor трафик и, соответственно, узнать расположение всех .onion-ов и их клиентов. Хотя, такая атака скорее всего неосуществима из-за того, что каждый клиент Tor имеет несколько случайно выбранных релеев в качестве Entry guards и подключается к сети только через них (набор entry guards меняется только каждые несколько месяцев). Даже в случае подмены всех релеев на подконтрольные гебне, entry guards клиентов, которые подключались к Tor ранее, будут из неподмененного списка. А значит, даже сломав все directory servers, у атакующего в лучшем случае будет доступ к 2-м из 3-х релеев каждого пути, что ничего не даст в плане расшифровки трафика.
А если мы вычислили в какой стране сидит данный .onion, то остается только следить за трафиком всех соединений с сетью Tor в данной стране и тем же самым методом корреляции трафика (ну или отключениям разных частей сети от интернета) постепенно сужать область поиска... Опять же, результат не гарантирован, а если .onion активно предпринимает попытки воспрепятствовать своему нахождению (да хотя бы подключение к Tor через разных провайдеров, или через прокси), то и маловероятен.
> c) подмены destination tor трафика фишинговой обманкой
Вот этого в любом случае сделать не получится, т.к. адрес .onion представляет из себя хеш публичного ключа этого сервера. А для того, чтобы подтвердить свою аутентичность, серверу нужно знать соответствующий приватный ключ, которого ни у кого кроме самого .onion-а нет.
> Если у нас есть контроль над всеми восемью directory servers (которые, кстати, расположены в разных странах), > то это надо использовать именно для того, чтобы заменить список релеев своими и временно, пока все не опомнились, > снифать весь Tor трафик и, соответственно, узнать расположение всех .onion-ов и их клиентов Вообще говоря контроль и знание их ключей вещи довольно разные. Собственно, я так понял, что 'directory servers' отдают tor клиенту адреса для входа в tor сеть - "tor relays" подписанные этими самыми ключами. При этом адреса этих самых directory servers известны. Очевидная атака уровня "сговор кровавой гебни нескольких стран" может быть реализована так:
1. ставим на пути трафика к tor directory server "умную прерывалку", которая имеет полученные не важно как (например, средствами TEMPEST Attack или иным незаметным владельцам сопособом) приватные ключи данного directory server.
2. ставим N штук evil relay node, на которые можно будет перенаправить траф. Чем более незаметной и эффективной мы хотим сделать атаку, тем больше таких узлов ставим.
3. на каждой evil relay node заменяем алгоритм установки соединения так, чтобы транзитные соединения устанавливались только с нашими evil relay nodes + они сообщали друг другу ключи шифрования транзитного трафа для выявления полных цепочек.
4. На умной прерывалке коллекционируем реальные адреса tor клиентов и отдаем им адреса evil relay node подписанные умыкнутым ключём tor directory server.
5. Если мы имеем дело с искомым .onion, то на наших evil relays мы это сразу увидим. Если нет - перенаправляем траф в реальную tor сеть и складываем реальный IP в список уже прошедших первичную проверку чтобы игнорироровать на нашей умной прерывалке траф с этого адреса (пропускать к реальному tor directory).
Так вот наша задача, как атакующей стороны будет дождаться пока к нам не попадет траф от искомого .onion .
Так как клиентский трафик мы можем легко создать сами, запрашивая нужный .onion, то должно получиться быстро сузить список потенциальных держателей .onion следующими средствами:
A. Организуем кратковременные потери связности между сегментами реальной сети для того чтобы заставить держателя .onion пересоединится к tor выбрав случайным образом новый входной релей, а значит с какой-то вероятностью - наши evil relays.
B. Организуем периодические клиентские запросы к .onion чтобы искомый .onion и наш клиент строили новые цепочки-подключения по случайному принципу. При этом, с некоторой вероятностью, рано или поздно .onion войдет в сеть через наши evil relay, а значит оставит свои реальные адреса.
C. Ставим наши evil relays на широкий канал, обеспечивая их выбор в качестве точек рандеву. Так добиваемся, что нормальные тор релеи сдают нам свои реальные IP.
D. Периодически обеспечиваем потерю связности с обычной сетью (а значит и с tor) для нормальных tor релеев, адреса которых получены в предыдущем пункте, вынуждая таким образом держателя .onion сменить релей, а значит, с некоторой вероятностью вляпаться в наш блок evil relay nodes.
Конечно тут не рассмотрено что делать с адресами за NAT в пункте 5, но это только черновая схема атаки. )
Кстати, если искомый .onion скачет по проксям перед входом в tor сеть, то он вынужден постояно менять точки входа в tor, а значит попадет в наш evil relay с большей вероятностью, чем если будет сидеть на месте. =)
> набор entry guards меняется только каждые несколько месяцев Для того чтобы избежать необходимости поддерживать вышеописанную атаку годами нужно пользоваться откючением нормальных тор-релеев согласно пунктам C и D выше.
Если тор клиент обнаруживает все entry guards оффлайн, то ЕМНИП он самостоятельно не предпринимает попыток подключиться через другие ноды. В общем думаю, что такая атака маловероятна, такое крупномасштабное вклинивание в сеть будет очень быстро замечено, максимум у атакующих будет несколько часов, чтобы что-либо успеть сделать, пока не поднимется шум.
В общем случае не обязательно оффлайнить entry guards - надо только посмотреть детально способ их ротации и подстроить алгоритм атаки соответственно. Это правда сделает атаку дороже. =) Я так понимаю, что по остальным моим предложениям по организации атаки принципиальных возражений нет?
> Никакого ssl, а значит рано или поздно пароль будет отснифан на транзитных нодах
Для hidden service'ов (т.е. сайтов .onion) SSL не нужен, т.к. весь трафик внутри сети Tor и так зашифрован. Его невозможно не только поснифать, но даже и определить откуда он и куда.
Более того, при обращении к .onion-сайту между вами и сервером находится как минимум 7 (СЕМЬ) промежуточных узлов (т.к. и клиент и сервер устанавливают стандартный 3-х узловой путь к случайно выбранному "рандеву-узлу"). Каждый из этих узлов знает адрес только предыдущего и следующего узла в цепочке. Это, кстати, является причиной того, что .onion сайты так тормозят.
Про деанонимизацию 2008 г. - это оказалось описанием теоретической возможности атаки на основе компьютерной симуляции сети Tor. На реальной сети эта атака не работала даже в 2008. Причем даже теоретическая версия атаки предполагала только перехват обращений через Tor к обычным сайтам, а не к .onion.
Вообще, .onion-сайты очень и очень хорошо защищены, тот же самый silk road может находится на любом из около 500 тысяч подключенных к Tor клиентов (http://metrics.torproject.org/users.html) и чтобы узнать на каком - надо чтобы у атакующего был доступ к подавляющему большинству из 2500+ Tor-узлов, расположенных по всему миру.
Насчет ПХП - все эти сайты скорее всего крутятся в виртуальной машине, трафик из которой жестко файрволлом хост-машины перенаправляется через Tor. То есть даже при взломе пхп и получении рута на машине реальный адрес хоста узнать будет невозможно.
Поисковик xycpusearchon2mc.onion в принципе выдает только одну страницу результатов, по любому запросу.
Reply
> Для hidden service'ов (т.е. сайтов .onion) SSL не нужен, т.к. весь трафик внутри сети Tor и так зашифрован.
> Его невозможно не только поснифать, но даже и определить откуда он и куда.
> Более того, при обращении к .onion-сайту между вами и сервером находится как минимум 7 (СЕМЬ) промежуточных узлов
> (т.к. и клиент и сервер устанавливают стандартный 3-х узловой путь к случайно выбранному "рандеву-узлу").
> Каждый из этих узлов знает адрес только предыдущего и следующего узла в цепочке.
Давайте я опишу выдуманную, на мой взгляд, не слишком дорогую атаку, а Вы меня покритикуете:
Ставим relay узел на очень быстрое соединение с сетью. Наверняка скорость работы релея является важным фактором в выборе маршрута, поэтому мы так повышаем свои шансы стать узлом участвующим в трафике. Далее пишем весь трафик и пытаемся его расшифровать при помощи заранее предвычисленных массивов данных (аналогично тому, как подбирают пароли подходящие к хешам при помощи гигазов заранее вычисленных хэшей). Как только у нас получилось подобрать что-то используем это к хосту, который предоставляет tor mail или tor messaging сервисы - .onion хостов по сравнению с полным объёмом сети мало и нам не нужно затруднять себя - проще попробовать пароль на всех имеющихся .onion хостах с нужными нам сервисами.
> Это, кстати, является причиной того, что .onion сайты так тормозят.
Некоторые не так уж и тормозят - вполне терпимо.
> Про деанонимизацию 2008 г. - это оказалось описанием теоретической возможности атаки на основе компьютерной
> симуляции сети Tor. На реальной сети эта атака не работала даже в 2008.
> Причем даже теоретическая версия атаки предполагала только перехват обращений через Tor к обычным сайтам, а не к .onion.
Спасибо за краткое резюме.
> Вообще, .onion-сайты очень и очень хорошо защищены, тот же самый silk road может находится на любом
> из около 500 тысяч подключенных к Tor клиентов (http://metrics.torproject.org/users.html)
> и чтобы узнать на каком - надо чтобы у атакующего был доступ к подавляющему большинству
> из 2500+ Tor-узлов, расположенных по всему миру.
У меня большие сомнения, что это нельзя, при желании и возможностях на уровне "гебня отдельно взятой страны", сузить до региона, а затем, постепенно, до количества, которое можно обработать силами административно-полицейского характера используя местные аналоги СОРМ. То есть, грубо говоря, когда количество потенциальных виновных снизится до пятисот можно инкриминировать всем этим деятелям участие в тероризме и на этом основании получить ордер на технические меры . )
Вот только это всё равно не дешево. )
> Насчет ПХП - все эти сайты скорее всего крутятся в виртуальной машине,
> трафик из которой жестко файрволлом хост-машины перенаправляется через Tor.
> То есть даже при взломе пхп и получении рута на машине реальный адрес хоста узнать будет невозможно.
Эти утверждения могут быть и правдой и ложью в каждом отдельно взятом случае. Получив рута в виртуалке можно:
*. копать в сторону эксплойтов к самой виртуалке. На моей памяти, о чем-то подобном писала Рутковска в своём блоге по мотивам Xen.
*. думать в сторону встраивания в педоконтент эксплойтов, предназначенных для атаки на оператора педосайта и на его клиентов - они там многие любят "новые материалы", а значит откроют залитый файл своей смотрелкой картинок и видео.
Причем, второй вариант атаки можно пробовать даже не имея удаленного доступа ни к guest ни к host системе.
На мой взгляд с педофилами выгодно бороться публично, но вот реально потратиться на поиск никто не хочет. =)
> Поисковик xycpusearchon2mc.onion в принципе выдает только одну страницу результатов, по любому запросу.
Спасибо, не знал. Какое-то странное ограничение.
ЗЫ: вообще говоря, если долго сидеть на берегу - можно дождаться взрыва сверхновой - солнце не вечное. ;)
Reply
Все верно, в Tor используется простенький load balancing, благодаря которому узлы с большей пропускной способностью чаще используются при построении пути.
> Далее пишем весь трафик и пытаемся его расшифровать при помощи заранее предвычисленных массивов данных (аналогично тому, как подбирают пароли подходящие к хешам при помощи гигазов заранее вычисленных хэшей).
Вот здесь атака захлебнется, т.к. rainbow tables, которые вы описываете, для взлома TLS (который используется для шифрования всего внутрисетевого трафика Tor) бесполезны. Наглядный пример: аналогом rainbow tables для алгоритма RSA 512-бит будет таблица всех простых чисел до 2^512. Если допустить, что для хранения данных нами используется накопитель, где 1 петабайт умещается в 1 грамм, то накопитель превысит массой лимит Чандрасекара и схлопнется в черную дыру :)) Ну а в TLS используется ЕМНИП как минимум RSA-1024, а может даже и RSA-2048 бит.
Вообще, на безопасности TLS (который используется в том числе и в HTTPS) основана вся инфраструктура банковских транзакций, оплаты кредитными картами через интернет и т.п. Если взломают RSA, то рухнет считай вся электронная коммерция.
На этом собственно и основывается безопасность Tor - из-за того, что TLS взломать невозможно, то для того, чтобы расшифровать трафик и даже для того, чтобы узнать откуда и куда этот трафик идет, взломщику нужно получить контроль над всеми тремя relay-ями, через которые проходит путь. Один или даже два подконтрольных узла ничего не дадут.
> У меня большие сомнения, что это нельзя, при желании и возможностях на уровне "гебня отдельно взятой страны", сузить до региона
На практике наиболее реальной против .onion-сайта является такая атака: если гебня контролирует всех провайдеров данного региона, то можно следить за всеми соединениями с сетью Tor. И дальше, если каждый раз, когда мы запрашиваем с silk road файл размером 100 мб, от некого IP-адреса уходит в сеть Tor 100 мб зашифрованного трафика, то этот IP с большой вероятностью и является этим самым silk road. Проблема (для атакующего) в том, что эта атака не более чем метод исключения. Т.е. даже полностью контролируя весь российский сегмент интернет, мы можем с определенной (большой) вероятностью определить, что silk road в России не находится. Допустим ФБР сделает то же самое и определит, что в Америке его тоже нет. Что дальше? Более того, на проведение такой атаки (корреляции трафика) нужно время, как минимум несколько дней (а в цивилизованных странах - еще и распоряжение суда и т.п.), а искомый нами hidden service может хоть каждый час прозрачно менять свое расположение, подключаясь к сети Tor то через прокси на Багамах, то через VPN на Мальдивах и т.д.
Но, разумеется, такого рода атака на порядки осуществимее, чем собирать кластер суперкомпьютеров и ломать несколько тысяч лет RSA.
> думать в сторону встраивания в педоконтент эксплойтов, предназначенных для атаки на оператора педосайта и на его клиентов
Вот это, на мой взгляд, наиболее реальный способ атаки. Им же кстати воспользовались прошлой осенью Anonymous, которые в hidden wiki разместили ссылку на модифицированный ими плагин Torbutton (используется для максимизации анонимности при выходе в Tor с Firefox), выдав его за "апдейт". Этот Torbutton отправлял анонимусам реальные айпишники пользователей. Короче как и в любой системе безопасности, человеческий фактор оказался самым слабым звеном :)
Reply
>Все верно, в Tor используется простенький load balancing, благодаря которому узлы с большей пропускной способностью чаще используются при построении пути.
Сразу вопрос, пардон, что не в документацию - где трафик оказывается дешифрован окончательно - только на точке получателе локальным тор-стеком протоколов?
>> Далее пишем весь трафик и пытаемся его расшифровать при помощи заранее предвычисленных массивов данных (аналогично тому, как подбирают пароли подходящие к хешам при помощи гигазов заранее вычисленных хэшей).
>Вот здесь атака захлебнется, т.к. rainbow tables, которые вы описываете, для взлома TLS (который используется для шифрования всего внутрисетевого трафика Tor) бесполезны. Наглядный пример: аналогом rainbow tables для алгоритма RSA 512-бит будет таблица всех простых чисел до 2^512. Если допустить, что для хранения данных нами используется накопитель, где 1 петабайт умещается в 1 грамм, то накопитель превысит массой лимит Чандрасекара и схлопнется в черную дыру :)) Ну а в TLS используется ЕМНИП как минимум RSA-1024, а может даже и RSA-2048 бит.
Спасибо, действительно наглядно.
Reply
А вот тут - подробнее - как насчет атак на распространение ключей? Если аналогия верная, то получается, что кто-то генерирует сертификаты, которые уже потом используются для шифрования и распространения траффика. Кого ломать чтобы поиметь доверяемые сертификаты и подставить себя для фищинга педопорно?
> На этом собственно и основывается безопасность Tor - из-за того, что TLS взломать невозможно, то для того, чтобы расшифровать трафик и даже для того, чтобы узнать откуда и куда этот трафик идет, взломщику нужно получить контроль над всеми тремя relay-ями, через которые проходит путь. Один или даже два подконтрольных узла ничего не дадут.
Я уже проглядывал мельком статьи по бедам современной реализации TLS и сделал вывод, что главная беда - невменяемый PKI. Как с этим в тор? Нет ли у 'местного подразделения кровавой гэбни'(tm) возможности атаковать административную структуру?
Reply
>На практике наиболее реальной против .onion-сайта является такая атака: если гебня контролирует всех провайдеров данного региона, то можно следить за всеми соединениями с сетью Tor.
> И дальше, если каждый раз, когда мы запрашиваем с silk road файл размером 100 мб, от некого IP-адреса уходит в сеть Tor 100 мб зашифрованного трафика, то этот IP с большой вероятностью и является этим самым silk road.
Как вариант конечно сойдет, но по моему слишком накладно.
> Проблема (для атакующего) в том, что эта атака не более чем метод исключения.
> Т.е. даже полностью контролируя весь российский сегмент интернет, мы можем с определенной (большой) вероятностью
> определить, что silk road в России не находится.
Если одна гебня сотрудничает с другой, то так можно дойти до гео-региона и AS прова в нем. =) Ну а дальше локальная гебня включает свой вариант СОРМ и вася кот. ;)
> Допустим ФБР сделает то же самое и определит, что в Америке его тоже нет. Что дальше?
С учётом того, что искомый .onion может быть в стране с законами сильно отличными от наших - есть шанс уперется в чисто юридические проблемы. Ну а дальше уже давить на региональные власти всем миром.. А больше никак. )
> Более того, на проведение такой атаки (корреляции трафика) нужно время, как минимум несколько дней
> (а в цивилизованных странах - еще и распоряжение суда и т.п.),
в цивилизованных странах, включая США и РФ, есть замечательные статьи о борьбе с тероризмом. В конце концов, вся эта херь с "мы не имеем права" благополучно игнорируется когда это действительно нужно. Вывод - ловить педопорно претстижно, но не особо нужно - и без того проблем хватает. Не?
Я к тому, что в тех же штатах следак (или кто там у них в системе оформляет отношения с разрешителями) может при некоторой ловкости без всякого мошенничества предъявить обвинения по одной статье (тероризм), получить ордер, а потом, собрав улики, по факту предъявить доп. обвинение по другой статье (педопорно). Я не прав? ?-)
> а искомый нами hidden service может хоть каждый час прозрачно менять свое расположение, подключаясь к сети Tor то через прокси на Багамах, то через VPN на Мальдивах и т.д.
Есть более дорогое (по потерям из разряда недополученная прибыль), но и более эффективное решение. Обеспечиваем одновременную потерю связности в реальном интернете с мониторингом нужного .onion из разных мест. Повторяем последовательно, вплоть до локализации до отдельной юрисдикции, а далее до отдельно AS, после чего обвиняем в тероризме и получив ордер включаем все возможности местного аналога СОРМ. Кстати, буквально недавно у всех кроме корбины в мск не работал гугль.. Истинные причины никем не проверены.=)))
> Но, разумеется, такого рода атака на порядки осуществимее, чем собирать кластер суперкомпьютеров и ломать несколько тысяч лет RSA.
OK, не будем ломать сферического коня в вакууме - займемся недостатками имплементации. =)
>> думать в сторону встраивания в педоконтент эксплойтов, предназначенных для атаки на оператора педосайта и на его клиентов
>Вот это, на мой взгляд, наиболее реальный способ атаки.
Да, один из наиболее вероятных способов. Есть еще варианты, я думаю. =)
Reply
> плагин Torbutton (используется для максимизации анонимности при выходе в Tor с Firefox),
> выдав его за "апдейт".
У меня сразу вопрос - при наличии request policy и noscript с политиками типа белый список - разве торбаттон еще зачем-то нужен?
> Этот Torbutton отправлял анонимусам реальные айпишники пользователей.
> Короче как и в любой системе безопасности, человеческий фактор оказался самым слабым звеном :)
отличия жизни от красивых лекций шифропанков в том числе в том, что бьют не по IP/паспорту, а по лицу. )
Я к тому, что вместо того, чтобы кричать ужас-ужас, граждане запретители могли бы открыть фонд по сбору денег на оплату услуг частных forensic компаний или, что тоже неплохо объявить существенную награду за данные, которые помогут найти реального педопорно изготовителя. Но нет - вопить "запретите им" куда как дешевле. =)
Вон жидомассоны(tm) после захвата заложников на олимпиаде заказали заказчиков теракта, и ниче - ща даж фильм можно посмотреть про крутость спецслужб отдельно взятой относительно молодой страны. )
Они, кстати, в прошлом или позапрошлом году скиднеппили из УА взрослого палестинского дядю и ниче - все утёрлись. ) Наши, в своё время, в Катаре, кажется, сработали более топорно - спалили абрека-террориста вместе с машиной, но, почему-то, решили, что "местное кровавоеГБ"(tm) будет уважать экстерриториальность здания посольства, не обеспеченную полком "военных красивых-здоровенных"(tm). )
Смысл в том, что кракер ВасяПупкин не связан законами вообще, частные forensic могут иметь по месту открытия компании ограничения на деятельность полегче, чем "местная кроваваяГБ"(tm) вынужденная для публики казаться вмеру белой и пушистой. =) Ну а уж имея ip и украденный пароль к криптодиску - дело отдельно взятого следака подставить саспекта так, что вполне легитимной для суда окажется сказка о том, что пароль де получен от подельника. =)
Я, как и многие другие люди, с удовольствием поучаствоавал бы в мозговом штурме по отлову педопорно провайдеров, но вот не предлагают.) Из чего я делаю вывод, что, на самом деле это не так уж и необходимо. )
Reply
Reply
Получается так. Безопасности государства файлообменники с педопорно не угрожают. Из-за того, что они скрыты в глубине сети Tor, среднестатический избиратель об их существовании даже не догадывается и пожаловаться властям не может. СМИ эту тему тоже особо не поднимают.
> У меня сразу вопрос - при наличии request policy и noscript с политиками типа белый список - разве торбаттон еще зачем-то нужен?
Теперь нет, сейчас Tor распространяется в виде Tor Browser Bundle, который уже включает в себя модифицированный Firefox, в котором отключен Java, Flash, встроен Noscript, отключена история, кэш, изменен User-Agent, чтобы не выдавать никаких сведений о системе и т.п. А раньше для этого использовался плагин Torbutton, с помощью которого можно было быстро включить/выключить использование Tor в браузере. Это было менее защищено чем теперешний вариант (отдельный браузер для Tor), т.к. с помощью Javascript, например, можно было передать данные между Tor и не-Tor сессиями.
> где трафик оказывается дешифрован окончательно - только на точке получателе локальным тор-стеком протоколов?
Если речь идет о доступе к обычному сайту через Tor, то полностью (т.е. известен адрес получателя, адрес отправителя и содержимое) трафик дешифрован только у нас на компьютере. После того того, как запрос ушел в Tor:
1-ый relay в пути знает наш адрес и адрес 2-го relay (но не знает содержимого трафика и кому он предназначен)
2-ой relay знает только адрес 1-го relay и адрес Exit node (т.е. не знает ни содержимого, ни адресов)
3-ий relay (Exit node) расшифровывает содержимое трафика и адрес получателя (но не знает нашего адреса)
Если через Tor мы обращаемся к HTTPS сайту, то "расшифрованное" Exit node'ом содержимое окажется зашифрованным TLS-потоком, т.е. в этом случае окончательно его узнает только тот сайт, к которому мы обращаемся. В Tor Browser Bundle кстати встроен плагин, который автоматом перенаправляет запросы на HTTPS версию сайта, если такая есть (например http://google.com -> https://encrypted.google.com). Иначе - Exit node сможет снифать трафик.
В случае доступа через Tor к .onion-сайту трафик нигде полностью не расшифрован. Ни одной точке сети не известен одновременно и адрес .onion-сайта и адрес клиента.
> Нет ли у 'местного подразделения кровавой гэбни'(tm) возможности атаковать административную структуру?
Для функционирования сети клиенту Tor нужно знать адреса всех открытых relay-узлов (есть и закрытые - для обхождения блокировки Tor в какой-либо стране). Этот список хранится на т.н. Directory servers, которых сейчас восемь штук. Айпишники и публичные ключи этих серверов прошиты в клиент Tor. Теоретически, если гебня получит доступ к этим серверам, раздобудет их приватные ключи и запустит 2500 своих подконтрольных релеев (чтобы пользователи не заметили разницы в количестве), то на некоторое время весь Tor окажется у них под колпаком.
Reply
Вот по этому всё ещё есть комментарии:
>> Нет ли у 'местного подразделения кровавой гэбни'(tm) возможности атаковать административную структуру?
>Для функционирования сети клиенту Tor нужно знать адреса всех открытых relay-узлов (есть и закрытые - для обхождения блокировки Tor в какой-либо стране).
> Этот список хранится на т.н. Directory servers, которых сейчас восемь штук.
>Айпишники и публичные ключи этих серверов прошиты в клиент Tor.
> Теоретически, если гебня получит доступ к этим серверам, раздобудет их приватные ключи и запустит 2500 своих
> подконтрольных релеев (чтобы пользователи не заметили разницы в количестве),
> то на некоторое время весь Tor окажется у них под колпаком.
Дорого, но осуществимо.
Вот только нахрен нужен вообще весь tor? Нужен конкретный tor клиент и конкретный .onion .
1. Допустим, атакует "кровавая гэбня"(tm). Например, для разнообразия, штатовская, причем сговорившаяся с произвольной другой "кровавой гэбней"(tm), например, нашей или "демократичной европы"(tm). Допустим, правдами и неправдами получены публичные ключи всех directory server'ов.
2. Для большой вероятности, что трафик данного .onion и данного клиента пойдет через нас ставим в стране пребывания данного .onion/клиента самые быстрые релеи. (Допустим мы уже вычислили в какой стране сидит данный .onion, например устроив серию кратких потерь связности между точками пиринга обсуживающими отдельные страны, ну или более тихим и прозрачным долгим способом корреляции трафика).
При этих двух допущениях - можно ли (и как) атаковать конкретного tor клиента и конкретный .onion с целью:
a) выявления его обычного ipv4 адреса.
b) дешифровки его tor трафика.
c) подмены destination tor трафика фишинговой обманкой
Пункт c) можно использовать с последующим перенаправлением на реальный .onion по факту ввода паролей, как это часто бывает у фишинговых обманок.
Было бы любопытно услышать Ваш комментарий. :)
Reply
А если мы вычислили в какой стране сидит данный .onion, то остается только следить за трафиком всех соединений с сетью Tor в данной стране и тем же самым методом корреляции трафика (ну или отключениям разных частей сети от интернета) постепенно сужать область поиска... Опять же, результат не гарантирован, а если .onion активно предпринимает попытки воспрепятствовать своему нахождению (да хотя бы подключение к Tor через разных провайдеров, или через прокси), то и маловероятен.
> c) подмены destination tor трафика фишинговой обманкой
Вот этого в любом случае сделать не получится, т.к. адрес .onion представляет из себя хеш публичного ключа этого сервера. А для того, чтобы подтвердить свою аутентичность, серверу нужно знать соответствующий приватный ключ, которого ни у кого кроме самого .onion-а нет.
Reply
> то это надо использовать именно для того, чтобы заменить список релеев своими и временно, пока все не опомнились,
> снифать весь Tor трафик и, соответственно, узнать расположение всех .onion-ов и их клиентов
Вообще говоря контроль и знание их ключей вещи довольно разные. Собственно, я так понял, что 'directory servers' отдают tor клиенту адреса для входа в tor сеть - "tor relays" подписанные этими самыми ключами. При этом адреса этих самых directory servers известны. Очевидная атака уровня "сговор кровавой гебни нескольких стран" может быть реализована так:
1. ставим на пути трафика к tor directory server "умную прерывалку", которая имеет полученные не важно как (например, средствами TEMPEST Attack или иным незаметным владельцам сопособом) приватные ключи данного directory server.
2. ставим N штук evil relay node, на которые можно будет перенаправить траф. Чем более незаметной и эффективной мы хотим сделать атаку, тем больше таких узлов ставим.
3. на каждой evil relay node заменяем алгоритм установки соединения так, чтобы транзитные соединения устанавливались только с нашими evil relay nodes + они сообщали друг другу ключи шифрования транзитного трафа для выявления полных цепочек.
4. На умной прерывалке коллекционируем реальные адреса tor клиентов и отдаем им адреса evil relay node подписанные умыкнутым ключём tor directory server.
5. Если мы имеем дело с искомым .onion, то на наших evil relays мы это сразу увидим. Если нет - перенаправляем траф в реальную tor сеть и складываем реальный IP в список уже прошедших первичную проверку чтобы игнорироровать на нашей умной прерывалке траф с этого адреса (пропускать к реальному tor directory).
Так вот наша задача, как атакующей стороны будет дождаться пока к нам не попадет траф от искомого .onion .
Так как клиентский трафик мы можем легко создать сами, запрашивая нужный .onion, то должно получиться быстро сузить список потенциальных держателей .onion следующими средствами:
A. Организуем кратковременные потери связности между сегментами реальной сети для того чтобы заставить держателя .onion пересоединится к tor выбрав случайным образом новый входной релей, а значит с какой-то вероятностью - наши evil relays.
B. Организуем периодические клиентские запросы к .onion чтобы искомый .onion и наш клиент строили новые цепочки-подключения по случайному принципу. При этом, с некоторой вероятностью, рано или поздно .onion войдет в сеть через наши evil relay, а значит оставит свои реальные адреса.
C. Ставим наши evil relays на широкий канал, обеспечивая их выбор в качестве точек рандеву. Так добиваемся, что нормальные тор релеи сдают нам свои реальные IP.
D. Периодически обеспечиваем потерю связности с обычной сетью (а значит и с tor) для нормальных tor релеев, адреса которых получены в предыдущем пункте, вынуждая таким образом держателя .onion сменить релей, а значит, с некоторой вероятностью вляпаться в наш блок evil relay nodes.
Конечно тут не рассмотрено что делать с адресами за NAT в пункте 5, но это только черновая схема атаки. )
Кстати, если искомый .onion скачет по проксям перед входом в tor сеть, то он вынужден постояно менять точки входа в tor, а значит попадет в наш evil relay с большей вероятностью, чем если будет сидеть на месте. =)
> набор entry guards меняется только каждые несколько месяцев
Для того чтобы избежать необходимости поддерживать вышеописанную атаку годами нужно пользоваться откючением нормальных тор-релеев согласно пунктам C и D выше.
Покритикуйте схему?
Reply
Reply
Reply
(The comment has been removed)
Reply
Leave a comment