РегистрацияПростой способ атаки "в обход" 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
Здесь не о том речь, чтобы работал, а о том чтобы функционировал надлежащим образом.
Да, интересно, но в любом случае надо написать: сообщение в talk, думаю, пойдёт только на пользу (и им и нам).
Я человек тупой и кондовый, а потому прежде всего смотрю на факты. Года 2 назад я чётко помню, как экзиты путём посылки сигнала -1 тор-клиенту менялись как перчатки, при этом тор функционировал достаточно шустро. Видимо, ключевое отличие, если атаки не происходит, лишь в увеличении отношения "число_нод/число_тор-юзеров."
Раньше её нельзя было варьировать, сейчас что-то поменялось? И в каких пределах можно менять?
Кстати, это повысит анонимность?
Этим сигналом и в 2 года назад и сейчас, происходит перезагрузка конфигурации, объявляются "грязными" все построенные до сигнала цепочки (с последующим их удалением, все новые потоки потребуют новых цепочек), и всё начинаете практически с нуля.
Лишь только при этом не происходит удаления тех цепочек которые уже задействованы существующими потоками (например при кип-алив до веб-сервера, IM, и т.д.)
Вы вероятно не наблюдаете всей цепочки и судите только по последнему звену, в то время как после hup'а ничто не мешает (кроме PRNG) выбрать тот же самый узел экзитом что и был ранее, с учетом всё того-же алгоритма взвешивания скоростей. Но цепочка наверняка будет, как минимум в промежуточном звене, совершенно другой. И даже если бы звенья новой цепочки совпали (что возможно, но маловероятно), сама по себе цепочка была бы новой (как с позиции клиента, так и всех узлов).
Менять через конфигурацию длину нельзя. Вообще это вопрос и ответ из faq'а.
Включение в расчеты — параметра размерности цепочки, при выборе узла в каждом конкретном клиенте, влияет на общую картину нагрузки сети. Эти изменения позволили (в теории) повысить общую производительность сети в 4 раза.
Вероятно нет, скорее понизит, изменения в алгоритме выбора выделяют такого клиента из общей массы. Вопрос только кто сможет это заметить (не считая глобального наблюдателя, но ему и так всё ясно).
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Не проще и не надо. Так всё сразу видно где ляпы и почему. И время экономится.
SATtva, у меня претензий нет.
Вроде так наоборот лучше понять, почему что-то требует исправления. Если бы было время, то открыл бы Вики-страницу с черновиком, но работа над ней отнимает гораздо больше времени. Нужно открывать и форматировать кучу страниц, ждать пока они загрузятся, после каждой правки проверять как они выглядят. Неудивительно, что вся разработка вообще консервативным способом обычно идёт в рассылках, а не форумах даже.
Для подготовки короткого письма, чтобы исправить только ляпы и безграмотность, достаточно кидать все замечания прямо в тему.
Пока все предложенные исправления подходят и будут включены в таком виде. Жду ещё поправок, раскиданных по теме как кому нравится, в пределах разумного. Если других замечаний нет, то ещё раз пишу окончательную версию письма и можно будет его отправлять.
Так там правки к правкам :) Отослал – увидел опечатку, а как исправить? Только ещё один комментарий писать. Я итак стараюсь не плодить лишних сообщений – всё включить в одно... но порой они столь длинные, что я боюсь что браузер сглючит, потому лучше отправить что есть и не рисковать.
У меня таковых вроде бы больше нет.
комментариев: 9796 документов: 488 редакций: 5664
//Multiple Directory Authority keys compromising: a partial solution for tor clients defence.
As we know from tor specification: "2. Every directory authority was a trust bottleneck:
if a single directory authority lied, it could make clients believe for a time an arbitrarily distorted view of the Tor network."
And "There is a small set (say, around 10) of semi-trusted directory
authorities. A default list of authorities is shipped with the Tor
software. Users can change this list, but are encouraged not to do so, in
order to avoid partitioning attacks."
Unfortunately, we have really small set of semi-trusted authorities and more than half of its in one jurisdiction (US),
and we must believe: owners of these servers really protects their server keys from compromising and keep them free from
any third party evil influence ;-)
Key security and trust problem are improved in v3 authority protocol, but not completely.
If the third party agent Mallory has >50% of semi-trusted DA keys,
and has an ISP level acces to user traffic, he still can makes a MITM-based virtual network simulation for that user,
like this:
Normal client activity:
Alice -> encrypted traffic -> [real tor] -> decrypted traffic from exit -> Bob
Intercepted client activity:
Alice -> encrypted traffic -> [virtual tor network simulation from Mellory] -> decrypted traffic for Mellory ->
-> [Mellory tor agent using Alice chains] -> [real tor] -> decrypted traffic from exit -> Bob
###
We estimate that MITM tor-network simulator can be implemented simply as a program run on one mashine or claster.
Thus, tor-network simulator can be used to deface selected tor-clients.
We propose a partial (very limited, but adequate) solution: tor client with active connection and relatively "fresh" stats cache
may implement an analysis for suspicious activity of stats changes.
At most two criteria can be analysed:
1) An attempt to download the stats from all of the mirrors is blocked or gives the stats with invalid signatures.
As a result, it can be downloaded only from semi-trusted DAs.
2) Tor-nodes keys signed by DA are changed significantly (for example, >90% of all keys) during very short time interval.
(This case rises a suspicion about fake stats injection for user cache.).
Open questions:
How MANY keys have to be affected by this attack to rise a suspicion?
What's the minimal time per change?
What's about other criteria of suspicious activity or formal model of other possible attacks detection for tor clients?
We offer the next log messages for tor client as indication of attack involved:
-> Warning: a lot of tor-nodes keys were changed during a short time interval!
-> If more than one half of Directory Authoritiy keys are compromised, stats can be poisoned with a fake data.
As a paranoidal option listed in config file (client-only section) one can use
StopTorIfTooManyKeysChanged 0|1
As concerns other open questions: suppose, user enables this option.
Then, is it sufficient to stop tor-clent when suspicious log event comes or any other things should be done also?
What are the right things to do for the users who get that suspicious log event?
What's the right procedure to run tor-client for users who have a long period of inactive cache to be safe from this attack?
There is a long discussion connected with this problem in our site where we continue to discuss a lot of ideas related with the topic.
"OpenPGP-in-Russia Team"
Атака виртуализацией? (Tor для этого необязателен.)
комментариев: 11558 документов: 1036 редакций: 4118
Multiple Directory Authorities' keys compromise: a partial solution for Tor clients protection
As we know from Tor specification: "Every directory authority was a trust bottleneck: if a single directory authority lied, it could make clients believe for a time an arbitrarily distorted view of the Tor network". And also: "There is a small set (say, around 10) of semi-trusted directory authorities. A default list of authorities is shipped with the Tor software. Users can change this list, but are encouraged not to do so, in order to avoid partitioning attacks."
Unfortunately, we have a really small set of semi-trusted authorities and more than a half of them are in the single jurisdiction (US), so we are forced to believe that owners of these servers really protect their servers' keys from compromise, and operators themselves [всё-таки в оригинале здесь речь шла именно об операторах, а не о ключах] are free from any third-party malicious influence ;-)
Main [в оригинале "key". заменено, чтобы избежать двусмысленности] security and trust problems were improved in v3 directory authority protocol, but not resolved completely.
If the third-party agent Mallory possesses more than 50% of semi-trusted DA keys and has an ISP-level access to user traffic, he still can make an MITM-based virtual network simulation for that user, like this:
Normal client activity:
Alice -> encrypted traffic -> [real Tor cloud] -> decrypted traffic from exitnode -> Bob
Intercepted client activity:
Alice -> encrypted traffic -> [Mellory's virtual Tor network simulation] -> decrypted traffic for Mellory ->
-> [Mellory's Tor client using Alice's circuits] -> [real Tor cloud] -> decrypted traffic from exitnode -> Bob
###
We propose a partial (very limited, but adequate) solution: Tor client with active connection and relatively "fresh" stats cache may resort to [добавить сюда "heuristic"?] analysis for suspicious
activity ofstats changes.At most two criteria can be analyzed:
1) An attempt to download stats from all of the mirrors is blocked or gives the stats with invalid signatures. As a result, it could be downloaded only from semi-trusted DAs. (Possibility of a legitimate DA's IP substituted with a malicious one, and data authenticated with compromised keys).
2) Tor-nodes' keys signed by a DA are changed significantly (for example, >90% of all keys) during a very short period of time. (This case rises a suspicion about fake stats injection for user cache.)
Some questions remains: How many keys have to be affected by this attack to rise a suspicion? What the minimum time period threshold should be?
...) What's about other criteria of suspicious activity or formal model of other possible attacks detection for Tor clients?
We propose next log messages for the Tor client as an indication of probable attack-in-progress:
-> Warning! Warning: a lot of tor-nodes' keys were changed during a short period of time!
-> If more than a half of Directory Authorities' keys are compromised, stats could be poisoned with a fake data.
As a paranoid option listed in config file (client-only section) one may ["may" в данном случае оправдано] use:
StopTorIfTooManyKeysChanged 0|1
Another open questions: Suppose user has this option enabled. Is it then sufficient to stop Tor-client when before-mentioned log event comes up or should also be done some other things too? What are the right things to do for users who got that log event? What's the right procedure to run Tor-client for users who have an outdated cache to be safe from this attack?
There is a long discussion on this problem on our site where we continue to propose a lot of ideas related to the topic.
"OpenPGP-in-Russia Team"
P. S. Вашей шифровальщице, spinore, тоже мой горячий привет.
А что ненадлежащего делает (или не делает надлежащего) Tor без Vidalia?
речь идет о получении пользователем по его запросу информации о цепочках (текущих) от демона (системного) тора и дальнейшей обработки этой инфы. Vidalia & Tork в данном случае делают сие "из каропки" автоматом. А как это проделать в ручную – надо читать спеки.
комментариев: 9796 документов: 488 редакций: 5664
Но раз SATtva вообще предлагает эту фразу выкинуть, то можно и выкинуть. Лишний раз навязчиво убеждать, что это атака реальна не стоит.
Для атаки виртуализацией tor нужен, чтобы после дешифровки траффик проходил через реальный tor и Алиса могла бы видеть ответы на exit-node IP через https.
Вот на эти доводы и надо делать упор. На приведенные симптомы аттаки, об отравленных статусах, можно получить предложение от разработчиков ознакомиться с TunnelDirConns и их заворотом в полноценные цепочки. (опции как раз для параноиков, как и предлагаемая :) На ограничение доступа к узлам, предложат ответить своим ограничением (StrictEntryNodes).
И начало в стиле описания уязвимости дважды устаревшего протокола, скорей послужит отправкой на чтение новых спецификаций, без анализа дальнейших, хотя и спорных доводов о недоверии к DA, и попытках реализовать проверку у клиента.
Мы знаем что так было. Сейчас нет. В текущий момент одиночная DA не может обмануть клиента ни на секунду. Впрочем и "открыть" ему глаза на подделку данных с большинства других DA, тоже не сможет. Менее половины списочного состава DA могут вообще "Войну и мир" в документы со статусами записывать, и при правильных диалогах персонажей, клиент не обратит на это своего внимания :)
комментариев: 9796 документов: 488 редакций: 5664
Предлагаю тогда убрать для нашего письма цитату из спецификации вообще (они свою спецификацию наизусть и так помнят) и вместо неё придумать убедительный абзац:
"Основа проблемы в небольшом числе корневых нод и необходимости доверия к ним. Несмотря на сравнения подписанных данных, поступающих от разных DA, при наличии у злоумышленника закрытых ключей более чем от половины DA, он может производить различные атаки".
Ну и дальше, как у нас и написано, что типа в курсе мы про V.3 протокол, но проблема большинства там остаётся.
TunnelDirConns не сработает, если всё заблокируют кроме DA или испортят все другие коннекты битыми аутентификациями, то туннелиться будет не через что.
StrictEntryNodes – Пусть ответят, это параллельная и дополняющая мера. Ни одним из возможных способов полностью решить проблему всё-равно нельзя.
комментариев: 11558 документов: 1036 редакций: 4118
The core problem with Tor is the lack of directory authorities which one need to unconditionally trust. Despite the mechanisms of DAs consensus voting and client comparing signed data downloaded from different DAs, an opponent controlling more than half of DAs' keys are able to conduct a multitude of attacks.