Простой способ атаки "в обход" 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
В стабильной версии Tor использующей вторую версию протокола, "зашито" пять DA. Два узла находятся в Европе.
DA — полноценный узел, он также транслирует трафик (владельцы лишь предпочитают не делать его exit'ом).
Всё описание по назначению себя DA есть в документации (сам код программы у клиентов, узлов, DA идентичен — всё различие в конфигурации, torrc), только самопровозглашение ничто без координации с другими DA и информировании об этом клиентов.
SATtva, ну вы прям как ребёнок! А доработать до работающего состояния идею никак? Можно сделать репозитарии публичных ключей и тор-клиенты бы периодически скачивали их. В конце концов, можно сделать внутренню сеть доверия среди все владельцев тор-узлов. Мало ли можно способов придумать как доставлять ключи в программу... Можно ещё ввести опцию: доверять ли ключам нод, не соответствующим скачанному архиву хэшей ключей... Можно много чего сделать чтобы её "децентрализовать".
Если все в США – то эффективно одно лицо, пофиг сколько организаций... Даже не постарались разместить в разных странах... о чём это говорит?
Да, не так давно читал... Я понимаю к чему вы, в целом согласен.
Но эти пункты описывали недостатки первой версии протокола доступа к информации о узлах сети, сейчас использовать её клиентам нет необходимости (если кто-то будет реализовывать клиента с нуля по спецификациям). И считается что эти пункты сейчас решены вторым протоколом. Нерешёные проблемы масштабируемости, напрямую не касаются доверия к DA.
Увеличение числа DA во второй версии, напротив желательно (не считая масштабируемость), и только повысит надежность всей сети и клиента в отдельности (клиент всегда будет верить только информации подписанной более чем половиной списочных DA).
Для конспирологов хочется заметить, что если большая часть ключей от DA будут украдены, даже наличие одной директории-"лжеца" внимательному клиенту должны дать пищу для размышления.
Если не сложно, можно назвать конкретно страны для всех 5ти DA? Лучше с их DNS'ами.
Как это попроще пронаблюдать кроме как ставить debug-like уровень и читать кучу текста с консоли? Или на уровне grep если знать типичные сообщения обо всех вохзможных ошибках(?).
Ещё где-то видел софт для визуализации цепочек, которые строит клиент tor'а. Не подскажете ли программу?
комментариев: 11558 документов: 1036 редакций: 4118
Вы удивитесь, но Вы только что изобрели ныне используемую схему с директориями и дескрипторами. :-)
Vidalia.
Страны для DA работающих со вторым протоколом: США, Австрия, Нидерланды.
Эта информация открытая, в каждом клиенте DA прописаны, глядите и обращайте каждую запись конкретно, сами.
Уровень менять не нужно, все особо подозрительные вещи Tor собщает warn'ом и notice'ом. Кучи там точно не бывает.
Следует разделить 2 понятия: статистика нод (кто в онлайне а кто нет), и их ключи. Что касается статистики собственно ключей, хотелось бы, чтобы клиент сверял скачанные отпечатки ключей нод с уже имеющимися с пердыдущей загрузки и сообщал об изменениях. В этом случае атака unknown'а могла бы быть проведена исключительно один раз (!), если хотя бы один раз Алиса скачала правильную статистику то она не может впоследствии не заметить того факта что все ключи всех нод внезапно изменились. Такой функционал есть в программе, чтобы его осуществить встроенными средствами а не сверять всё руками/костыльными_решениями?
комментариев: 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
а особо продвинутые в сторону параноидальных настроений пользователи пусть сами выставляют его в единицу.
Это всё бессмысленно, ибо атака unknown'а возможна только (во всяком случае начиная со второго протокола) против нового клиента, знающего исключительно отпечатки ключей DA. В таком случае и сравнивать не с чем и сообщать нечего (разве что факт каждого старта с нуля, что уже делается). Учитывая мощь и вероятно власть противника, Алиса попадает на такой крючок Мэллори один раз, но навсегда (не считая телепортации Алисы в неподконтрольную часть вселенной).
Но если вдруг:
Да если использует отравленный кеш то заметит, по ошибкам при TLS хэндшейке с настоящими узлами.
При наличии кешированных дескрипторов, клиент способен скачивать новые статусы и дескрипторы используя защищённые однохоповые цепочки до произвольных директорий (через TunnelDirConns). Аттакующему для MitM понадобится предсказать с кем будет соединяться клиент, и завладеть еще секретными ключами этих узлов (дополнительно к ключам DA). Если же еще добавить/использовать скачивание через полноценные цепочки, то завладеть нужно будет ключами большинства узлов сети.
Понимаю что нет пределу совершенства (в т.ч. паранойи), но без КК это всё слишком дорого.
Развивая мысль про достоверную информацию от неподконтрольной Мэллори части серверов DA. Вероятно в текущем дизайне Tor, утрата большей части секретных ключей DA, считается необратимой катастрофой и все попытки опираться на информацию с оставшихся не подконтрольными DA не имеют смысла. К примеру не сдавшихся DA проще изолировать (на уровне запросов клиента, и это будет правдоподобной неисправностью). Следовательно сравнивать будет опять нечего.
Ув. unknown, вы бы не знаялись этим? У вас это лучше получится :=) Я своё дело сделал (идею высказал) :)
Логично, ну и сам процесс тора должен останавливаться если StopClientIfTooMuchKeysChanged есть 1.
Видимо, да. Ну эта страница итак вроде посылается в некоторых случаях...
Скорее здесь вопрос к браузеру, чтобы он заботился о том, кто такую странцу выводит (если злоумышленники столь востры, что могут подделать адрес, отображаемый в адресной строке, например, посредством взлома, то уже ничего не поможет :)) Во всяком случае конкретно в этом я точно не специалист, в подобных вопросах...
Я полагаю, что нужно исходить с того что есть 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, в противном случае всё как раньше (для истиных самураев) :))
комментариев: 11558 документов: 1036 редакций: 4118
Её посылает Privoxy, а не Tor. Разработчики со временем хотят от Privoxy вообще отказаться.
Ключи DA намертво вшиты в клиентскую программу, дистрибутивы которой заверяются в помощью PGP.
Но это всё так... в далёком будущем и в перспективе :)