РегистрацияПростой способ атаки "в обход" 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
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Решил проверить насколько чётко реакция работает.
Я не знаю что там на самом деле, но на subkeys ключ не появился.
Если вдруг что, то отозванная версия:
Кстати, имхо это более правильно идеологически как раз, чем силком загружать ключи на сервера. Возможно, кому-то понадобится ключ, который лучше бы лишний раз не светился на серверах...
комментариев: 9796 документов: 488 редакций: 5664
А что делать с тремя вариантами: деление-умножение (связанные C и D), сумма дисперсий (несвязанные C и D) и пересечение множеств дескрипторов? Кратко перечислять всё?
Что делать со средней статистикой за большие интервалы, которая вроде как не нужна?
комментариев: 11558 документов: 1036 редакций: 4118
Именно. Такими причинами и руководствовался.
Там достаточно взять S = (1-C)2+(1-D)2
C/D не стоит, наверное, рассматривать... хотя тоже меожете включить.
Ну поюзать его, а что? Всё сводится лишь к тому, чтоб учесть существенные замечания и всё, всего навсего.
Ничего не писать.
комментариев: 9796 документов: 488 редакций: 5664
Пусть противнику на каком-то шаге удалось довести число ложных ключей и подменённых нод до половины:
Тогда пользователь может построить случайным образом 8 видов цепочек.
(1-1-1) – полностью подконтрольная, ведущая в виртуальный Tor
(0-0-0) – полностью неподконтрольная, противник может пропустить её мимо в реальный Tor
(0-0-1), (0-1-0), (0-1-1), (1-0-1) -частично неподконтрольные, приводят к разрыву соединения – противник не может завернуть цепочки из реального Tor'а обратно в свою подставную сеть.
(1-0-0), (1-1-0) – частично подконтрольные, противник может вывести их из подставной сети Tor в реальную, но без полной деанонимизации
Итого при 50% подставных ключей:
только 1/8 цепочек деанонимизируются, а половина цепочек не работают вообще. Такие сбои в сочетании с мониториногом статистики тоже засекают атаку.
Итак, если в течении нескольких шагов подряд критерий S стабильно высокий, да ещё и глюки с работой сети наблюдаютсяя очень заметные, то это отсекает и практически любую замедленную атаку тоже.
комментариев: 9796 документов: 488 редакций: 5664
solution for Tor clients protection. v 1.05
Thanks Roger. We continue to discuss the problem on our website with our heads overheated. :-)
[...]
This issue can lead to the crisis of trust. In case of the attack 3+1 corrupted authorities + 1 controlled ISP is no more better than a single anonymizer with access to users logs. It wouldn't be "rare" when the adversary is law enforcement agency or another "political" adversary,
which is able to get DA keys and install Tor virtual network simulator on an ISP. And all this is way easier than pretend to be a "global adversary". Worse, this "hypothetical" attack will be deterministic, not probabilistic.
It's to say that ways to deter this attack is similar to thunderbolt protection. You can place a lightning rod on a house's roof, and will avoid direct lightning strike. Lightning striking an unprotected area is uncommon. In the absence of a lightning rod it's very rare for your house to be stroke too. You may think that the lightning rod is unnecessary. But if the direct lightning stroke will happen it will be devastating.
Agreed. The core problem is: We don't have a clear criteria of attack, and we don't have a simple scenario for defense.
We assume that the adversary conducts this attack against a single or a very small fraction of isolated Tor users in order to avoid disclosure of such abilities. Attack is based on creating a distorted view of the Tor network for the targeted user(s) (virtual network simulation and rerouting intercepted and decrypted/re-encrypted traffic to the real Tor network afterwards).
User can detect this attack in two ways: autonomous (collecting anomalies in the network statistics), and relative (comparing the network statistics with other trusted users by exchanging suspicious network statuses on secure off-the-band channels: encrypted email, personal face-to-face contacts). If concerned users can identify suspicious node keys (signed by rogue DAs) with the help of more users, they can publish that keys or their hashes for "peer review" as a demonstration of evidence. Concerned users will play a role of "Tor watchers".
Here we propose a very simple (and maybe a naive) approach for the first step — autonomous detection (just as an example, wasn't tested in the wild).
If the user has N_k nodes' keys from the current network status and N_k-1 from the previous network status, then
C=N_k/N_k-1 is the change in the numbers of keys (and nodes themselves).
Let I be the index of keys found in both lists of N_k and N_k-1
I_max = max I = min (N_k, N_k-1)
Let D=I/I_max -– changes of keys themselves (differences).
We can replace this with D=(I+1)/(I_max+1) to avoid zero values (not always needed, in a reality we have a big values for I).
If C>=1, then we calculate S=C/D; and if C<1, then we calculate S=C*D
The closer S to 1, the more stable Tor network is. If S changes significantly, then we have the network instability (S<1 is better than S>1). S can be easily calculated from the Tor network status file. But we can't easily count broken or blocked connection to nodes from the status list (which could be a sign of attack by itself).
More correct solution is calculate independed sum of S=(C-1)^2+(D-1)^2 and keep this value as close to zero as possible.
Another possible approach is measuring descriptors as intersections in the set M = M1 AND M2, and consider Z(M1, M2) = min( |M|/|M1| , |M|/|M2| ) as normalized and time invarianted value in the range of [0..1], 0 – most unstable; 1 – fully stable. Finally, calculate R = K*(1-Z), with K is the maximum distance in space [x, y, z].
With differences D we can calculate any values from status (consensus) file for nodes (IP, type) to avoid great changing with numbers of entry and exit nodes and other distortions.
We discuss about "delayed partial cache poisoning" from attacker: ability of avoiding any visible statistical disturbances and guess, this is impractical for attacker and can be easy detected with our criteria.
For example: if only 10% nodes keys changes per step by attacker then user have a very litle value of chance to download false status 9 times in succession: Pr=0.1x0.2x0.3*...0.9= .00036
But user have a big chance 1-Pr in one of any 9 steps to download back real Tor network status (nodes consensus) from node, not controlled by adversary (mirror) and detect attack by measuring S. Use config options [alldiractionsprivate=1] help user to do it.
Another problem for adversary is too many broken connection from mixing real and false nodes. In our another example user haves a half of false nodes and another half of real. He can select randomly 8 types of circuits:
(1-1-1) – full controlled, connection going to virtual Tor simulator, deanonimized by adversary and rerouted to real Tor without user suspicion.
(0-0-0) – full unknown and free from adversary, can be retransmitted adversary to real Tor cloud without deanonimizing
(0-0-1), (0-1-0), (0-1-1), (1-0-1) -partially known to adversary, but cause a broken connection (not working circuits)
(1-0-0), (1-1-0) – partialy known, but not deanonimizing by adversary, working if adversary reroute this from virtual Tor simulator to real Tor cloud.
With 50% falsed keys and virtualized nodes an adversary haves only 1/8 deanonimizing circuits and user haves 50% broken circuits.
Too many broken circuits or blocked connections with stable high disturbance of S in close steps of consensus refreshes is a sign of attack too.
It's possible from this examples to develop working and more corrected numerical recipe to determine the hazardous difference between two network-status documents. Such offline statistics gathering and analyzing can be performed with separate tool used by enthusiastic paranoids :)
Maybe this statistics and info about network status can be distributed for peer review by the means of web of trust – based on the existing infrastructure, not relying on Tor, thus providing one more way of external verification not requiring any changes in tor source.
Concerned users ("Tor watchers") could print diagrams of suspicious changes and publish them, or exchange and analyze data using web of trust or other ways to communicate such DA audits to the public.
We assume the problem need to have a lot of research and experiments to get an acceptable solution.
"OpenPGP-in-Russia Team"
Наиболее вероятный сценарий любого баланса, в котором мы выбираем между слишком узким но не достаточно узким есть тот, э.. э.. э.. э.. in about YEAR PEOPLE... мой парсер сломалсо :-((
time direction invarianted value (иначе можно опдумать о банальной однородности по времени, что не верно)
У нас был свой контекст, где мы проводили аналогии с n-dim, но здесь об этом не говорится, да и зачем им этим мозги пудрить. Достаточно положить K=1, ибо оно ни на что толком не влияет, либо по крайней мере сказать что K – есть аналог максимального расстояния как если бы мы были в конфигурационном пространстве. Иначе нас сочтут за сумасшедших (ввести x, y, z в торе [в тор-сети а не в бублике] :)) Скажем так, K они и сами догадаются ввести если оно им будет удобно (ибо это всего лишь рескэйлинг), а вот чем меньше лишних определений и букв, тем лучше.
В принципе мы начинали обсуждение, когда-то ещё давно, с того что противник режет загрузку статистики через тор-сеть, и позволяет её загружать только через DA напрямую. Итак, этого он делать не может, получается? Точно?
/мну уважает Dirac'а, но боится что конкретно в данном случае он не причём :-D
alldirectionsprivate
connections
In our another example user has a half of false nodes and another half of real ones.
Кроме того, здесь следует оговориться о том, что реальная вероятность будет зависеть от их задекларированной пропускной способности, так что если в качестве 10% подменённых нод будут фигурировать самые высокопропусные, то вероятность может резко подскочить :) Либо надо сказать "для простоты и демонстрации ради, здесь мы не учитываем корреляцию вероятности выбора с пропускной способностью нод".
It's possible from these examples
Ещё у меня лично есть вопрос о том, как часто клиент загружает статистику с тора. Слышал, что зависит от интенсивности трафика, пропускаемого через тор, или нет? Просто хотелось бы знать конкретные временные рамки: минимум – такой интервал, максимум – такой.
Также, мы начинали обсуждение с того, что когда пользователь после перерыва запускает вновь свой тор-клиент, атакующий может запретить ему строить цепочки по существующему статусу, чтобы заставить его обратиться к DA напрямую (вот тогда и можно ему сделать хоть 100% подмен). Вы, unknown, оговаривались, что появилась недавно какая-то опция в тор-клиенте, имеющая отношение как раз к этому, но то вроде было не совсем то. В нашем случае требуется конкретно возможность/опция загружать статистику принудительно по уже имеющейся старой статистике а не напрямую, не допускать принудительно прямого обращения к DA.
В целом, по поводу стабильности/нестабильности могу сказать что очень часто возникает ситуация, когда нельзя через тор зайти на те или иные сайты, либо вообще ни на какие, и тогда приходится использовать
.
В этом смысле даже в текущем статусе сети делать её принудительныйрестарт приходится довольно часто.
Ещё было бы интересно узнать о том, сколько в среднем в каждый выбранный момент времени одновременно работает тор-нод, тор-экситов и тор-пользователей (с упором не на всё сообщество, включающееся время от времени, а на то, сколько одновременно). В оценочную упоминавшуюся цифру (100000 пользователей тора) я могу поверить от силы как в число всех, кто за много лет хотя бы раз запускал тор, но не более.
комментариев: 9796 документов: 488 редакций: 5664
Он делает это только один раз, чтобы сразу погрузить пользователя в виртуальный Tor, подменив все 100% ключей для нод. Если он это будет делать после каждого шага по частям, то у пользователя не будет работать большинство цепочек, даже если не предпринимать блокировки, а если ещё и неподконтрольные узлы блокировать, то ещё больше. И так по много раз подряд, пока пользователь не скачает весь фальшивый статус целиком. Это также заметно, как и атака за один шаг.
Просто этот вопрос был оставлен без рассмотрения, теперь думаю надо такой аргумент привести. Может разработчики придумают (или мы сами) какие-то более хитрые адаптивные способы блокировки, но пока условимся, что по множеству приведённых причин, замедленная атака не может быть больше нескольких шагов, непрактична и детектируема.
Опции Directory Actions не в текущей, ни в альфа-версии не нашёл, хотя она была и обсуждалась у нас в теме (может название не так запомнил)?
Сейчас есть:
TunnelDirConns 0|1
PreferTunneledDirConns 0|1
но лучше убрать тогда вообще упоминание об опциях, они меняются. А основной принцип будет ясен.
Верно. Мы не анализируем механизм выбора цепочек клиентом. Пока обойдёмся без конретики, чтобы не разводить новой теории. Our conjecture is "adaptive (or selective) blocking" of connections is possible but don't gives a significant advantages to adversary.
Я нашёл у себя в кэше после длительного периода работы через Tor пять статусов. Один от какого-то умершего DA, про который писали в рассылке, что он в дауне, он не обновлялся неделю. Один суточной давности. Один часовой. Один примерно 15 минутной. И один тоже старше суток.
Вообще бардак полный :-) В третьей версии отдельных статусов не будет, будет один общий файл-консенсус, подписанный большинством DA. Думаю, что в среднем, он не чаще часа будет обновляться, а при серьёзных изменениях в сети не чаще 15 минут.
В любой момент работы. Но надо сделать 100% подмен как можно скорее (за один шаг), иначе пользователь убежит из виртуальной сети обратно в реальную, плюс будет куча неработающих цепочек при неполной подмене, хоть с гипотетической "адаптивной блокировкой", хоть без неё.
Вообще, после длительного перерыва у пользователя кэш "несвежий". Пока оставим в стороне этот труднорешаемый момент.
Про пользователей никто точно не скажет. А раскладку по нодам и их опциям можно посмотреть или в кэше или на странице xenobite, ссылку на которую я уже приводил. Порядка 1100 экситов из 2500 нод как ни странно. Только большинство похоже еле шевелятся, поэтому и адаптивные блокировки и подмены наиболее выбираемых узлов в какой-то мере возможны.
Вообще в логах что-то должно быть на этот случай: статус ещё не устарел, а после N попыток так и не смогли обновить статистику и пошли качать с DA.
И в первом письме и в этом указывается, что большое число любых битых соединений совместно с большими изменениями в картине сети – признак атаки. Что из этого следует, разработчики лучше нас поймут надеюсь.
комментариев: 9796 документов: 488 редакций: 5664
выйдет такой, что спустя примерно год люди увидят сообщения в логах безо всяких реальных атак, а мы будем думать для чего здесь нужен этот код?
Ну если они ещё заумнее нас пишут, то нас они точно лучше понимают :-)