id: Гость   вход   регистрация
текущее время 12:18 28/03/2024
Автор темы: unknown, тема открыта 31/07/2006 23:00 Печать
http://www.pgpru.com/Форум/АнонимностьВИнтернет/ПростойСпособАтакивОбходTor
создать
просмотр
ссылки

Простой способ атаки "в обход" tor


Простой способ атаки "в обход" против пользователя Tor.


Протокол сети tor (Onion Routing) имеет топологию статической сети с корневым сертификатом (Root CA). Этот сертификат используется для подписи статистики и ключей независимых серверов, подключаемых к сети Tor. Закрытая часть ключа сертификата принадлежит разработчикам программы tor, открытая зашита в саму программу. Поэтому пользователи всегда доверяют этому сертификату так же как и самой запускаемой ими программе, работу которой они могут протестировать и посмотреть исходники.


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


Однако, если использовать Tor в качестве "приманки" против конкретного пользователя, то всё делается достаточно гладко.


Вот как это может происходить:


1) Представитель силового ведомства Мэллори получает ордер на прослушивание интернет-соединения Алисы, которая использует Tor.
При этом он также получает ордер на выдачу закрытого ключа сети Tor у разработчиков (или получает его другим способом – прослушивание, кража, взлом сервера, подписывающего статистику).


2) Мэллори также получает ордер на установку у интернет-провайдера Алисы специального оборудования для прозрачной трансляции сетевых адресов (Network Adress Translation). В отличии от обычного NAT, который используют админы, это оборудование и соотвествующее программное обеспечение должно максимально незаметно подменять адреса из выбранного списка, имитировать соединение с ними, обрабатывать и отправлять траффик дальше.


3) Если Алиса использует обычное, не связанное с Tor, интернет-соединение, Мэллори просто прослушивает траффик сниффером (эту скучную работу он может поручить Еве).


4) Если Алиса посылает запрос статистики на один из серверов Tor, Мэллори осуществляет простейшую атаку человека посредине "man-in-the-middle". Он создает имитацию соединения с этим IP адресом, а на самом деле отправляет Алисе пакеты, подписанные похищенным сертификатом.


5) После того как Мэллори дал Алисе скачать фальшивую статистику, с фальшивыми же ключами серверов, заверенную сертификатом разработчиков Tor, он перехватывает все обращения к IP-серверам Tor, расшифровывает весь траффик Алисы теми ключами, которые он ей же и подсунул.


6) Для предотвращения подозрений со стороны Алисы Мэллори дополнительно фальсифицирует ответ от всех серверов, которые возвращают IP Алисы (http://serifos.eecs.harvard.edu/cgi-bin/ipaddr.pl?tor=1) и другие.
Правда этот метод не сработает, если Алиса зайдёт на SSL-защищённый сайт, от которого нет ключа у Мэллори и увидит там свой IP, не соответствующий сети tor.
В таком случае Мэллори может перенаправлять конечный траффик Алисы на свои подконтрольные сервера, зарегистрированные в сети Tor.


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


Спасибо Spinore http://www.pgpru.com/forum/viewtopic.php?p=11332#11332
который предложил множество интересных идей и вдохновил меня на более внимательное изучение анонимных протоколов, в результате чего мне и пришла в голову мысль насчёт возможности атаки на Tor и использования его в качестве средства индивидуального прослушивания траффика, после чего я и написал этот текст.


Spinore, а Вы хотели ключ хранить в анонимной сети! Современной криптографии пока ещё очень далеко до этого.


Особое внимание при написании данного текста я уделил прекрасному обзору Андреаса Хирта http://pages.cpsc.ucalgary.ca/~hirt
всвязи с его тезисами о том, что в течении давдцати лет так и не было разработано удовлетворительно стойкого и практичного анонимного сетевого протокола, надёжных сведений по доказательству стойкости и классификации атак на такие протоколы в открытой литературе крайне мало, а исследователи то и дело с подозрительным постоянством находят неописанные, хотя и очевидные атаки.


Также, советую тем, кто хочет и дальше копать в этом направлении ознакомиться с архивом проекта Gnunet.
http://www.gnunet.org/papers.php3?xlang=English


 
На страницу: 1, 2, 3, 4, 5, ... , 15, 16, 17, 18, 19 След.
Комментарии
— soot (23/12/2007 18:08)   <#>

Это одно и то же. "Корневые узлы (ноды)" — термин, выдуманный участниками этого форума (в том числе и мной) ради простоты и наглядности. Но он некорректен: "directory authority" не является обычным узлом, транслирующим трафик; эти серверы только поддерживают и выдают "официальный" список Tor-узлов.


В стабильной версии Tor использующей вторую версию протокола, "зашито" пять DA. Два узла находятся в Европе.

DA — полноценный узел, он также транслирует трафик (владельцы лишь предпочитают не делать его exit'ом).

Всё описание по назначению себя DA есть в документации (сам код программы у клиентов, узлов, DA идентичен — всё различие в конфигурации, torrc), только самопровозглашение ничто без координации с другими DA и информировании об этом клиентов.
— Гость (23/12/2007 20:02)   <#>
Неудачная мысль. Тогда для запуска каждого нового узла придётся выпускать новую версию программы. А ещё у оператор узла может рухнуть машина и лишить его ключа узла — опять придётся выпускать новую версию. Можно привести дюжину таких примеров

SATtva, ну вы прям как ребёнок! А доработать до работающего состояния идею никак? Можно сделать репозитарии публичных ключей и тор-клиенты бы периодически скачивали их. В конце концов, можно сделать внутренню сеть доверия среди все владельцев тор-узлов. Мало ли можно способов придумать как доставлять ключи в программу... Можно ещё ввести опцию: доверять ли ключам нод, не соответствующим скачанному архиву хэшей ключей... Можно много чего сделать чтобы её "децентрализовать".

Четыре. Все поддерживаются разными лицами. Правда, если не ошибаюсь, все размещены в США.

Если все в США – то эффективно одно лицо, пофиг сколько организаций... Даже не постарались разместить в разных странах... о чём это говорит?

Знаете историю про Черчилля и Энигму во время Второй Мировой?
Он позволил немцам разбомбить два города, хотя были разные поводы
эвакуировать мирное население и спасти несколько сотен тысяч жизней.

Да, не так давно читал... Я понимаю к чему вы, в целом согласен.
— soot (23/12/2007 20:03)   <#>

То, на чём основана гипотетическая атака, относится к пункту 2, но остальные пункты тоже не радуют.


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

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



Для конспирологов хочется заметить, что если большая часть ключей от DA будут украдены, даже наличие одной директории-"лжеца" внимательному клиенту должны дать пищу для размышления.
— Гость (23/12/2007 20:06)   <#>
В стабильной версии Tor использующей вторую версию протокола, "зашито" пять DA. Два узла находятся в Европе.

Если не сложно, можно назвать конкретно страны для всех 5ти DA? Лучше с их DNS'ами.
— Гость (23/12/2007 20:14)   <#>
Для конспирологов хочется заметить, что если большая часть ключей от DA будут украдены, даже наличие одной директории-"лжеца" внимательному клиенту должны дать пищу для размышления.

Как это попроще пронаблюдать кроме как ставить debug-like уровень и читать кучу текста с консоли? Или на уровне grep если знать типичные сообщения обо всех вохзможных ошибках(?).

Ещё где-то видел софт для визуализации цепочек, которые строит клиент tor'а. Не подскажете ли программу?
— SATtva (23/12/2007 20:19)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Можно сделать репозитарии публичных ключей и тор-клиенты бы периодически скачивали их.

Вы удивитесь, но Вы только что изобрели ныне используемую схему с директориями и дескрипторами. :-)

Ещё где-то видел софт для визуализации цепочек, которые строит клиент tor'а

Vidalia.
— soot (23/12/2007 20:44)   <#>

Если не сложно, можно назвать конкретно страны для всех 5ти DA? Лучше с их DNS'ами.


Страны для DA работающих со вторым протоколом: США, Австрия, Нидерланды.
Эта информация открытая, в каждом клиенте DA прописаны, глядите и обращайте каждую запись конкретно, сами.


Как это попроще пронаблюдать кроме как ставить debug-like уровень и читать кучу текста с консоли? Или на уровне grep если знать типичные сообщения обо всех вохзможных ошибках(?).


Уровень менять не нужно, все особо подозрительные вещи Tor собщает warn'ом и notice'ом. Кучи там точно не бывает.
— Гость (23/12/2007 21:08)   <#>
Вы удивитесь, но Вы только что изобрели ныне используемую схему с директориями и дескрипторами. :-)

Следует разделить 2 понятия: статистика нод (кто в онлайне а кто нет), и их ключи. Что касается статистики собственно ключей, хотелось бы, чтобы клиент сверял скачанные отпечатки ключей нод с уже имеющимися с пердыдущей загрузки и сообщал об изменениях. В этом случае атака unknown'а могла бы быть проведена исключительно один раз (!), если хотя бы один раз Алиса скачала правильную статистику то она не может впоследствии не заметить того факта что все ключи всех нод внезапно изменились. Такой функционал есть в программе, чтобы его осуществить встроенными средствами а не сверять всё руками/костыльными_решениями?
— Гость (23/12/2007 21:12)   <#>
Да, и ещё хотелось бы иметь возможность руками обновлять статистику онлайна нод ключей, но не сами ключи, принадлежащие им. Грубо говоря, разделить эти 2 процесса, чтобы всё не выглядело так как будто мы обнавляем свою gpg-связку доверяя всем ключам только на основе одной-единственной подписи (роль которой в случае тора играет DA).
— soot (23/12/2007 23:03)   <#>
Возможно поторопился с "лжецом" несущим правду. Клиент с v2 просто его проигнорирует (очень похоже что по тихому), увы но похоже что так. У паранойиков пока остается шанс паранойить дальше :)
— unknown (24/12/2007 21:07)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

У паранойиков пока остается шанс паранойить дальше :)


Стараимся. Изо всех сил!


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


Мне кажется это хорошее предложение. Можно даже разработчикам послать идею, только желательно в как можно более грамотно оформленном виде.

Например в логах могло бы появляться сообщение: Warning! All DA keys and > 90% nodes keys changed in a short time!

Только что порекомендовать простому озадаченному пользователю? Сообщить ему просто через лог? Остановить демон или процесс тора и послать ему веб страничку по типу http://127.0.0.1:9050/ (хотя посылать сообщения в виде страниц или tcp ответов – плохая идея, tor не должен вмешиваться в присылаемый контент, это возможность для атак и фишинга)?
Какой критерий выбрать в качестве порога срабатывания по времени, количеству, принадлежности ключей?
Что делать тем у кого давно не обновлялась статистика и все ключи устарели?

По крайней мере нужно это всё сформулировать разработчикам, они пусть придумают какое-то обоснованное решение или вынесут проблему на дальнейшее обсуждение.

Как вариант может быть придумать параметр для конфига вида:

StopClientIfTooMuchKeysChanged

а особо продвинутые в сторону параноидальных настроений пользователи пусть сами выставляют его в единицу.
— soot (24/12/2007 23:05)   <#>

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


Это всё бессмысленно, ибо атака unknown'а возможна только (во всяком случае начиная со второго протокола) против нового клиента, знающего исключительно отпечатки ключей DA. В таком случае и сравнивать не с чем и сообщать нечего (разве что факт каждого старта с нуля, что уже делается). Учитывая мощь и вероятно власть противника, Алиса попадает на такой крючок Мэллори один раз, но навсегда (не считая телепортации Алисы в неподконтрольную часть вселенной).

Но если вдруг:

хотя бы один раз Алиса скачала правильную статистику то она не может впоследствии не заметить того факта что все ключи всех нод внезапно изменились.


Да если использует отравленный кеш то заметит, по ошибкам при TLS хэндшейке с настоящими узлами.

При наличии кешированных дескрипторов, клиент способен скачивать новые статусы и дескрипторы используя защищённые однохоповые цепочки до произвольных директорий (через TunnelDirConns). Аттакующему для MitM понадобится предсказать с кем будет соединяться клиент, и завладеть еще секретными ключами этих узлов (дополнительно к ключам DA). Если же еще добавить/использовать скачивание через полноценные цепочки, то завладеть нужно будет ключами большинства узлов сети.

Понимаю что нет пределу совершенства (в т.ч. паранойи), но без КК это всё слишком дорого.


Развивая мысль про достоверную информацию от неподконтрольной Мэллори части серверов DA. Вероятно в текущем дизайне Tor, утрата большей части секретных ключей DA, считается необратимой катастрофой и все попытки опираться на информацию с оставшихся не подконтрольными DA не имеют смысла. К примеру не сдавшихся DA проще изолировать (на уровне запросов клиента, и это будет правдоподобной неисправностью). Следовательно сравнивать будет опять нечего.
— Гость (24/12/2007 23:08, исправлен 24/12/2007 23:12)   <#>
Мне кажется это хорошее предложение. Можно даже разработчикам послать идею, только желательно в как можно более грамотно оформленном виде.

Ув. unknown, вы бы не знаялись этим? У вас это лучше получится :=) Я своё дело сделал (идею высказал) :)

Например в логах могло бы появляться сообщение: Warning! All DA keys and > 90% nodes keys changed in a short time!

Логично, ну и сам процесс тора должен останавливаться если StopClientIfTooMuchKeysChanged есть 1.

Только что порекомендовать простому озадаченному пользователю? Сообщить ему просто через лог? Остановить демон или процесс тора и послать ему веб страничку по типу http://127.0.0.1:9050/

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

Какой критерий выбрать в качестве порога срабатывания по времени, количеству, принадлежности ключей?

Я полагаю, что нужно исходить с того что есть DA, и к их смене ключей следует подходить особенно жёстко (а не молчать в тряпочку когда они изменились). Что касается ключей остальных нод, оценка в 90% сильно завышена. Мне кажется при разумных оценках динамики процентов 30 тор-нод максимум... меняют свои ключи за год. Но: если клиент не запускался год, то ему логичнее заново скачать всю статистику и ключи с разных каналов, свериться что нет атаки на стороне его провайдера и далее жить спокойно. Поидее я бы расширил ваши идеи вот каким образом: при каждом старте тора он должен в логах писать:
  • Число использовавшихся ранее (при предыдущем запуске клиента) нод, которые теперь сменили ключи: N (M% от общего числа), их имена: vasya, masha, vitya.
  • Число не использовавшихся ранее (при предыдущем запуске клиента) нод, которые теперь предъявляются статистикой: N1 (M1% от общего числа), их имена: vanya, alisa, bob.
  • Суммарное время, протекшее с момента предыдущего благополучного запуска tor-клиента: чч:мм:сс.
  • Указанная выше статистика подтверждена следующими DA: moria, efbeay, essselon, противоречит статистике со следующих DA: <список0>, не удалось получить ответ от следующих DA: <список1>. Общий список DA заложенный в текущей версии клиента: <список2>.
После этого у клиента юзера интерактивно клиент спрашивает:
  • Поверить и принять (П)
  • Остановить клиент (О)
  • Перезапустить клиент ©
Таким образом, каждый сам будет решать доверять или нет... И не надо никаикх общих правил. Не знаю как Вам, unknown, а вот лично я не верю и в смену ключей 30% нод за неделю :=)
Все вышеотмеченные пункты клиент должен делать если StopClientIfTooMuchKeysChanged=1, в противном случае всё как раньше (для истиных самураев) :))
— SATtva (24/12/2007 23:15)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Видимо, да. Ну эта страница итак вроде посылается в некоторых случаях.

Её посылает Privoxy, а не Tor. Разработчики со временем хотят от Privoxy вообще отказаться.

Я полагаю, что нужно исходить с того что есть DA, и к их смене ключей следует подходить особенно жёстко (а не молчать в тряпочку когда они изменились).

Ключи DA намертво вшиты в клиентскую программу, дистрибутивы которой заверяются в помощью PGP.
— Гость (24/12/2007 23:36)   <#>
Конечно, вышеозвученный функционал можно написать самому в виде скриптиков, но хотелось бы не заниматься костылестроением, а видеть это в основной программе. Возможно, при надлежащей реализации вышепредложенного (не исключаю что требуется ещё много доработок к идее), получится сконструировать более-менее достойную защиту против злоупотребления сертификатом (Да, сертификат должен отвечать за то, что им было подписано недавно, за свои слова, так сказать :)) ). И в идеале сеть станет истино распределённой :)) И ещё: если идея будет грамотно доработана, то можно будет смело сделать много DA в сети и не бояться о том, что DA продестроит кого-то: я могу по своему желанию использовать 10-15 DA, скачивая с них статистику и вручную доверять/не_доверять загруженной статистике. каждый может сам интуитивно ориентироваться каким DA он доверяет больше, каким – меньше и т.д. В итоге мы получим уже давно знакомую схему сертификатов на сайтах: подтверждение разными DA ключей каких-то нод соответствует (по аналогии) тому, что сертификат для https с их сайтами был подписан разными CA. Мне уже начинает казаться что не были правы те, кто говорили, что все системы завязанные на единый сертификат, обладают защитой не большей некоторой... потому что технически такая схема вроде как дорабатываема до рабочей... Ещё есть такое понятие как онлайновое обновление статистики когда tor уже запущен: что тогда? Опять интерактивно спрашивать клиента, доверяет ли он обновлённой статистике? Или один раз спросить, а потом предложить использовать некую мнемонику допустимоого изменения статистики, которая в пределах отсутствия подозрительного? Вопрос вот в этой мнемонике, unknown уже сказал... Математически если выпендриться, нужно ввести адекватную метрику на множестве tor-статистик, учитывающую нашу модель безопасности, и потом сравнивать на каждом обновлении статистики полученную "разность" с "допустимой". И.. хорошо было бы дать возможность определять норму разности tor-статистик каждому юзверю мануально :=)) (например, для unknown'а если меньше 90% изменилось – то ничего страшного, а другие будут несогласны). В общем, метрика есть функция нескольких аргументов:
  • числа изменившихся ключей со времени последнего старта
  • числа новых нод, появившихся со времени последнего старта
  • числа DA, которые подтвердили предложенную статистику
  • общего числа DA с помощью которых патылись получить статистику
  • числа DA, которые отвергли предложенную статистику
  • числа DA, ответ от которых по неясным причинам получить неудалось
  • времени, прошедшего со времени последнего старта
  • степени паранойи пользователя

Но это всё так... в далёком будущем и в перспективе :)
На страницу: 1, 2, 3, 4, 5, ... , 15, 16, 17, 18, 19 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3