Простой способ атаки "в обход" 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
Ссылки
[link1] https://torstat.xenobite.eu/
[link2] http://www.pgpru.com/forum/anonimnostjvinternet/strannoepovedenietora
[link3] http://puti-gospodni.livejournal.com/
[link4] http://www.kara-murza.ru/books/manipul/manipul52.htm
[link5] http://archives.seul.org/or/dev/Dec-2007/msg00029.html
[link6] https://www.awxcnx.de/cgi-bin/proxy4/nph-proxy.cgi/000000A/http/ugha.i2p/
[link7] https://www.torproject.org/svn/trunk/doc/contrib/authority-policy.txt
[link8] http://cr.yp.to/export.html
[link9] http://en.wikipedia.org/wiki/Bernstein_v._United_States
[link10] https://www.torproject.org/svn/torflow/README
[link11] http://ygrek.org.ua/files/torstat.tar.gz
[link12] http://caml.inria.fr
[link13] http://code.google.com/p/ocaml-extlib/
[link14] http://arxiv.org/abs/0802.3397
[link15] https://www.pgpru.com/proekt/poljzovateli?profile=vadim_z
[link16] https://www.pgpru.com/comment21772
[link17] https://node.xenobite.eu/mrtg.php?MRTG=day
[link18] https://node.xenobite.eu/mrtg.php?MRTG=week
[link19] https://node.xenobite.eu/mrtg.php?MRTG=month
[link20] https://node.xenobite.eu/mrtg.php?MRTG=year
[link21] http://www.noreply.org/tor-running-routers/
[link22] http://www.noreply.org/tor-running-routers/totalLong.html
[link23] http://www.noreply.org/tor-running-routers/totalMonthly.html
[link24] http://www.noreply.org/tor-running-routers/totalBiWeekly.html
[link25] http://www.noreply.org/tor-running-routers/totalWeekly.html
[link26] http://project.torstatus.kgprog.com/trac/wiki
[link27] https://www.torproject.org/svn/torctl/doc/howto.txt
[link28] http://eprint.iacr.org/2008/080
[link29] http://archives.seul.org/or/dev/Mar-2008/msg00000.html
[link30] http://ygrek.org.ua/files/torstat.png
[link31] http://ygrek.org.ua/files/torstat.bin.tar.gz
[link32] http://ygrek.org.ua/files/torstat2.png
[link33] http://ru.wikipedia.org/wiki/IRC
[link34] http://www.pgpru.com/comment21943
[link35] https://blog.torproject.org/blog/circumvention-and-anonymity#comment-518
[link36] http://www.linux.org.ru/view-message.jsp?msgid=3918549&lastmod=1249125560410
[link37] https://lists.torproject.org/pipermail/tor-talk/2013-April/027774.html
Небольшое исправление к пункту 6 Мэллори не должен отпускать расшифрованный траффик напрямую в сеть или подставные серверы. Он может его зашифровать обратно по тем же цепочкам, которые выбрала Алиса и пустить в сеть tor.
Если у Мэллори будет быстро работающая машинка, виртуализирующая соединиение с фальшивой сетью тор внутри себя, снимающая на выходе чистый траффик, а затем заворачивающая его в настоящий tor, то Алиса м Боб вообще ничего не заподозрят.
Вот так Алиса работает через обычный tor:
Alice -> encrypted traffic -> [tor] -> decrypted traffic -> Bob
А вот так с подставным:
Alice -> encrypted traffic -> [virtual tor network simulation from Mellory] -> decrypted traffic -> [Mellory tor agent used Alice chains] -> encrypted traffic -> tor -> Bob
Небольшой чёрный ящичек между Алисой и tor, в который загружен закрытый ключ сети tor.
Все недостатки системы с корневым сертификатом здесь присутствуют. Вот только у кого он может депонироваться?
Интересное исследование.
В качестве домашнего задания любителям теорий заговоров: можно ли использовать такую схему для индивидуализированной атаки на всех пользователей Tor и как долго нападающий сможет сохранять скрытность?
Из классификации Хирта следует, что все протоколы анонимной связи строятся на доверии к корневому сертификату.
Эта атака может быть направлена не только против Tor, но и cipherpunk, mixmaster и др. Неподвержены ей только непрактичные протоколы
типа "сети обедающих криптографов".
Эта даже не атака в широком смысле. Это общая неполноценность систем с корневым сертификатом, которую так интенсивно критиковал Шнайер (см "Секреты и ложь"). Но там держатель сертификата в коммерческой системе мог хотя бы потерять деньги или репутацию. А в анонимной системе дела обстоят ещё хуже.
Атака злоупотребления главным секретным ключем анонимной системы идеально вписывается в теории заговоров (хотя мы высокомерно делаем вид что они нам не нравятся, но на самом деле мы падки до сенсаций :-). Создается анонимная сеть, изначально финансируемая военным ведомством (DARPA), учёные делают свою работу даже ни о чём не подозревая, располагая серверы в университетских лабораториях, откуда "люди неприметной внешности" крадут сертификаты.
Пользователи получают чистые исходники и формально стойкий протокол. Дальше "незаконные" владельцы сертификата могут снимать траффик отдельных пользователей.
Мэллори должен потрудиться, чтобы создать виртуальную машину, загружающую реальные ключи узлов tor'a и полностью имитирующую фальшивую сеть tor внутри себя, но состоящую из фальшивых ключей и статистики из которой он получит открытый текст и завернёт в настоящий tor. Пакеты и на выходе для Боба и возвращаемые обратно Алисе должны быть подправлены так, чтобы не было никаких изменений в их полях (TTL и др.), чтобы не было заметно, что пакеты обрабатывались (если Алиса вдруг попытается их анализировать). То же он может проделать с mixminion, в mixmaster пользователи вообще скачивают никем не заверенные ключи откуда попало.
Это несложно. Возможно кто-то в рамках небольшой сети даже сможет написать программную реализацию и провести эксперимент.
Алиса может заподозрить неладное, если она переключится на другой интернет-канал или ни с того ни сего войдёт в tor через неизвестный для Мэллори VPN. Тогда он отключит свою машинку и подозрение вызовет только то, что статистика поменялась. Но tor и так часто меняет статистику при смене IP адреса. Сравнивать же весь набор ключей на предмет того, как они меняются при переключении на разные соединения Алиса конечно может, но Мэллори тоже не дурак. Он на время отключит свою адскую машинку, подождёт пока Алиса успокоится и начнёт искать подходы ко всем её интернет-каналам, чтобы поставить аппаратуру и там.
Такое прослушивание будет осуществляться довольно незаметно и можно расшифровывать траффик со многих пользователей одновременно, но только у одного провайдера (эдакий деанонимизирующий СОРМ :-). Правда если пользователей будет очень много, то машина не потянет затраты на криптооперации по процессорному времени и памяти. Но можно сделать дешифрующий кластер. Можно от многих крупных провайдеров проложить прямые линии в единый центр прослушивания коммуникаций, это не совсем глобально, но близко к тому.
Но прослушать совсем уж глобально, "на следующем неподконтрольном маршрутизаторе", в другой стране (без прикрытия) уже не получиться.
Странно, что разработчики всех анонимных систем умалчивали о возможности злоупотребления к корневому сертификату. Если к нему нет доверия (а его реально по моим прдставлениям нет), то публичные анонимные сети это не более чем игрушки для обкатки технологий, которые можно применять только в закрытых организациях, которые реально заинтересованы в том, чтобы сертификат не был украден.
Даже если случайно злоумышленник будет пойман, разработчики всегда могут развести руками и сказать, что они делали всё честно, а к краже ключа непричастны, сохранив свою репутацию. Протокол и код не содержат закладок, а начёт доверия к Root CA, ну скажут, что это же и так в соответствующих работах описано, эта такая глобальная проблема, которая в настоящее время не решена.
Не вижу причин, почему нельзя сделать такую схему распределённой по аналогии с нашим СОРМ. Машина устанавливается у провайдера, в подвале дома, зарывается поблизости от магистрального канала (нужно подчеркнуть) и функционирует автономно. Она может принимать управляющие команды по той же общедоступной сети, по какой идёт и трафик Алисы. В принципе, это даже не должен быть такой монстр в несгораемом шкафу, как сервер СОРМ: учитывая ограниченный набор функций это может быть весьма компактное (если не миниатюрное) и малозаметное устройство типа небольшого маршрутизатора или даже модема.
Что касается самой проблемы, она, на мой взгляд, чем-то напоминает известную статью, Trust Reflecting Trust (название могу путать, но вы наверняка понимаете, о чём), — такая же максима. Мы можем располагать открытым исходным кодом, и, не доверяя разработчикам, провести его аудит. Но откуда у нас уверенность в компиляторе? Даже если и компилятор собирался из исходников, то с применением другого компилятора, ничуть не более доверяемого.
Продолжать можно бесконечно, а поэтому на каком-то этапе важно остановиться, основываясь, возможно, на интуиции или каких-то других неэмпирических сдерживающих факторах. Это вопрос доверия уже скорее философского, а не криптографического. Впрочем, на этот вопрос каждый себе отвечает сам...
Ну это уже получитя тот самый глобальный наблюдатель, защиты от которого нет, как честно говорили разработчики.
Да, очень интересно, unknown :)
Тем не менее, хоть многие и доверяют тор, но если я был бы уверен, что за мной следят, я бы не довольствовался одним тором точно. Легко можно водрузить проксю до или после тора. Тогда окромя ордера на прослушивание нужно будет ещё догавариваться с абстрактными странами о том, что они должны выдать логи и т.д. + для критических вещей надоне забывать об end-to-end gpg, с проверкой фингерпринтов по независимым каналам. Если коротко: я завожу себе впн в отфонарной стране и лезу в тор с того впн. Пока такие адские машинки не будут установлены на большинстве серверов мира об атаке можно будет забыть. К тому же в силу текучести информации, данную прослушивающую систему будет сложно претворять на практике и применять для многих пользователей так, чтоб никто не знал о самом существовании данной системы. К тому же, прийдётся писать специальную программу для каждой из анонимизирующих сетей. Идеальным выходом из ситуации является квантовый канал с асимметричным шифрованием. Тогда слушать просто будет нельзя :) (или по кр. мере существенно сложнее). + нужно не забывать об массовости. Чем болше пользователей и траффик, тем сложнее следить и т.д.
Они ведь честно предупреждали: "This is experimental software. Do not rely on it for strong anonymity."
Они всё отрицают
http://archives.seul.org/or/talk/Aug-2006/msg00042.html
Но мне кажется, что всё равно эта атака сработает, наверно не так просто и примитивно, как я описал
Заговор молчания? Мне кажется, комментарии других участников дискуссионной группы тоже были удалены на этапе модерации.
Ну не всё так просто.
Кое что прояснилось. В таком виде "атака на тор" невозможна.
На основе поверхностных знаний Onion Routing протокола я сделал неверный вывод и поспешил поделиться им с разработчиками.
Зато сэкономил время, которого признаюсь у меня было мало для более глубокого изучения вопроса.
Серверы директории тоже независимы, разработчики включают в программу только их публичные ключи, а программа признаёт статистику верной, только если получит подтверждений более чем от половины серверов.
Для меня ещё кажется туманным вопрос, что если серверов директорий немного, то как происходит официальная процедура включения их публичных ключей в программу? Или отзыв скомпрометированных ключей? Не могут ли они все быть (или стать) подконтрольными кому-либо? (Разработчики считают защиту от такой угрозы нереальной). Работает ли распределённая модель доверия в таком ограниченном объёме?
Но думаю дальнейшая дискуссия в этом направлении с разработчиками бесперспективна. Если у кого есть время, силы и желание, можете копать дальше.
А со своей стороны вопрос считаю пока закрытым. Разоблачить заговор ЦРУ или АНБ не удалось ;-)
Серверы директории – это что-то типа master-нод? Сколько их кстати? И как они соотносятся с корневыми нодами?
У меня сразу проскользнула мысль, что, возможно, имело бы смысл включать в программу публичные ключи всех серверов тора (ну или сертификаты, если угодно). Поскольку цепочки строятся клиентом независимо, Мэллори сможет устроить атаку только за счёт преобладающего числа подконтрольных ей мод, в противном случае ничего не получится, так как они не могут иметь публичные ключи все нод.
В каком смысле независимы? Находятся в разных странах, принадлежат разным людям и их много? В противном случае проблема может быть переформулирована: получаем контроль над серверами директорийи осуществляем снова описанную атаку, как вы уже и сказали.
P. S.: есть небольшой позитив: раз
- До сих пор не известно достоверное ни об одном случае, когда кого-то вычислили из-под тора.
- Планируют запретить анонимные системы в Германии, а потом и во всей европе (ссылка пробегала) => не могут иначе, видимо, справиться.
- Когда всё-таки начинали расследования, изымали эксит-ноды а не тех кто что-то через них посылал.
Значит, возможно, не всё так плохо... Единственная надежда.И вобще, имхо не вредно было бы где-нить на сайте увидеть обзор всех возможных атак на tor.
Это одно и то же. "Корневые узлы (ноды)" — термин, выдуманный участниками этого форума (в том числе и мной) ради простоты и наглядности. Но он некорректен: "directory authority" не является обычным узлом, транслирующим трафик; эти серверы только поддерживают и выдают "официальный" список Tor-узлов.
Четыре. Все поддерживаются разными лицами. Правда, если не ошибаюсь, все размещены в США.
Неудачная мысль. Тогда для запуска каждого нового узла придётся выпускать новую версию программы. А ещё у оператор узла может рухнуть машина и лишить его ключа узла — опять придётся выпускать новую версию. Можно привести дюжину таких примеров.
http://www.freehaven.net/anonbib/
Когда запускали сеть, то сервер корневой директории действительно был кажется только один или несколько,
но все принадлежали разработчикам, поэтому у меня и осталось такое представление.
Сейчас, теоретически каждый желающий может запустить такой сервер.
Но, то ли желающих нашлось немного, то ли разработчики удостоили этой чести только себя и ещё кого-то,
но в файле статистики можно наблюдать только семь строчек:
Можете проверить здесь[link1], только большая страница может сделать браузер на время задумчивым.
про причину ругательства браузера на сертификат можете почитать на главной.
Из них два висят на одном IP адресе и, по крайней мере четыре из семи, связаны с разработчиками.
Так что тогда означает их фраза, что если половина директорий скомпрометирована, то игра окончена:
Ну и это я или не понял (я допускаю, что скорее всего так и есть) или это демагогия:
Неполные 7 – это что, multiply, множество великое?
Вот что они пишут в спецификации, которую отослали почитать:
То, на чём основана гипотетическая атака, относится к пункту 2, но остальные пункты тоже не радуют.
Т.е. больше десяти корневых директорий в сети иметь нежелательно из-за возможности атак разделения и
это узкое место не только в плане доверия, но и в плане масштабирования.
Далее, по тексту:
Со стороны клиента как работает тоже много написано, но естественно:
Я не буду цитировать всё, там ещё много деталей и можете сами прочитать или на сайте
или локально в консоли:
По моему, если ключи корневых директорий известны, то атака с виртуальной
сеткой tor как-то работать будет, может какие-то детали надо ещё добавить.
Но почему-то среди множества методов даже малопрактичных атак у разработчиков этот метод не описан.
А зачем раскрывать все секреты? Может какой-то метод раскрытия был использован, а для прикрытия можно параллельно
взломать компьютер жертвы или использовать информацию только в оперативных целях, а для суда представить как будто вычислили
вообще не через tor или проэксплойтили компьютер жертвы.
Ну, массово следить за пользователями они мешают, но вполне возможно что с особо вредными пользователями справиться могут.
Да потому что были заинтересованы больше в показухе, чем в реальном результате и действовали тупо по инструкции.
Ну и заодно запугать операторов экситов и подговить негативное общественное мнение, чтобы легче было принять закон против
анонимных сервисов.
Знаете историю про Черчилля и Энигму во время Второй Мировой?
Он позволил немцам разбомбить два города, хотя были разные поводы
эвакуировать мирное население и спасти несколько сотен тысяч жизней.
Но тогда немцы бы узнали, что шифр Энигмы взломан.
А несколько сотен тысяч жизней в военное время небольшая тактическая потеря
в стратегических играх военных и политиков.
Если tor очень нужен к примеру американским службам для анонимного сбора и передачи информации из любой точки
сети без организации подставных каналов и прочей мороки, то будут ли они способствовать даже раскрытию крупного
теракта, если это поставит под угрозу проект tor?
И нравится ли это немецому правительству (или лоббистам от определённых ведомств),
которое давно пытается освободиться от американского влияния, ещё со времён
той самой Второй Мировой и которое использует криптографические проекты как разменную монету в своих попытках
показать фигу Америке (то профинансируют GnuPG для борьбы с эшелоном, который используется для экономического
шпионажа в пользу США, то на tor наедет, не раскрывая своих далеко идущих политических замыслов).
На самом деле, лучше уделить внимание чисто технической стороне вопроса, а конспирология только уводит
в пустоту и не даёт получить никакого реального знания. Никаких конретных фактов для позитивных выводов пока нет,
так же как и для негативных.
Цитата с перечислением пунктов неправильно отформатировалась из-за их автонумерации :-(
В стабильной версии Tor использующей вторую версию протокола, "зашито" пять DA. Два узла находятся в Европе.
DA — полноценный узел, он также транслирует трафик (владельцы лишь предпочитают не делать его exit'ом).
Всё описание по назначению себя DA есть в документации (сам код программы у клиентов, узлов, DA идентичен — всё различие в конфигурации, torrc), только самопровозглашение ничто без координации с другими DA и информировании об этом клиентов.
SATtva, ну вы прям как ребёнок! А доработать до работающего состояния идею никак? Можно сделать репозитарии публичных ключей и тор-клиенты бы периодически скачивали их. В конце концов, можно сделать внутренню сеть доверия среди все владельцев тор-узлов. Мало ли можно способов придумать как доставлять ключи в программу... Можно ещё ввести опцию: доверять ли ключам нод, не соответствующим скачанному архиву хэшей ключей... Можно много чего сделать чтобы её "децентрализовать".
Если все в США – то эффективно одно лицо, пофиг сколько организаций... Даже не постарались разместить в разных странах... о чём это говорит?
Да, не так давно читал... Я понимаю к чему вы, в целом согласен.
Но эти пункты описывали недостатки первой версии протокола доступа к информации о узлах сети, сейчас использовать её клиентам нет необходимости (если кто-то будет реализовывать клиента с нуля по спецификациям). И считается что эти пункты сейчас решены вторым протоколом. Нерешёные проблемы масштабируемости, напрямую не касаются доверия к DA.
Увеличение числа DA во второй версии, напротив желательно (не считая масштабируемость), и только повысит надежность всей сети и клиента в отдельности (клиент всегда будет верить только информации подписанной более чем половиной списочных DA).
Для конспирологов хочется заметить, что если большая часть ключей от DA будут украдены, даже наличие одной директории-"лжеца" внимательному клиенту должны дать пищу для размышления.
Если не сложно, можно назвать конкретно страны для всех 5ти DA? Лучше с их DNS'ами.
Как это попроще пронаблюдать кроме как ставить debug-like уровень и читать кучу текста с консоли? Или на уровне grep если знать типичные сообщения обо всех вохзможных ошибках(?).
Ещё где-то видел софт для визуализации цепочек, которые строит клиент tor'а. Не подскажете ли программу?
Вы удивитесь, но Вы только что изобрели ныне используемую схему с директориями и дескрипторами. :-)
Vidalia.
Страны для DA работающих со вторым протоколом: США, Австрия, Нидерланды.
Эта информация открытая, в каждом клиенте DA прописаны, глядите и обращайте каждую запись конкретно, сами.
Уровень менять не нужно, все особо подозрительные вещи Tor собщает warn'ом и notice'ом. Кучи там точно не бывает.
Следует разделить 2 понятия: статистика нод (кто в онлайне а кто нет), и их ключи. Что касается статистики собственно ключей, хотелось бы, чтобы клиент сверял скачанные отпечатки ключей нод с уже имеющимися с пердыдущей загрузки и сообщал об изменениях. В этом случае атака unknown'а могла бы быть проведена исключительно один раз (!), если хотя бы один раз Алиса скачала правильную статистику то она не может впоследствии не заметить того факта что все ключи всех нод внезапно изменились. Такой функционал есть в программе, чтобы его осуществить встроенными средствами а не сверять всё руками/костыльными_решениями?
Да, и ещё хотелось бы иметь возможность руками обновлять статистику онлайна нод ключей, но не сами ключи, принадлежащие им. Грубо говоря, разделить эти 2 процесса, чтобы всё не выглядело так как будто мы обнавляем свою gpg-связку доверяя всем ключам только на основе одной-единственной подписи (роль которой в случае тора играет DA).
Возможно поторопился с "лжецом" несущим правду. Клиент с v2 просто его проигнорирует (очень похоже что по тихому), увы но похоже что так. У паранойиков пока остается шанс паранойить дальше :)
Стараимся. Изо всех сил!
Мне кажется это хорошее предложение. Можно даже разработчикам послать идею, только желательно в как можно более грамотно оформленном виде.
Например в логах могло бы появляться сообщение: 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, в противном случае всё как раньше (для истиных самураев) :))
Её посылает Privoxy, а не Tor. Разработчики со временем хотят от Privoxy вообще отказаться.
Ключи DA намертво вшиты в клиентскую программу, дистрибутивы которой заверяются в помощью PGP.
Конечно, вышеозвученный функционал можно написать самому в виде скриптиков, но хотелось бы не заниматься костылестроением, а видеть это в основной программе. Возможно, при надлежащей реализации вышепредложенного (не исключаю что требуется ещё много доработок к идее), получится сконструировать более-менее достойную защиту против злоупотребления сертификатом (Да, сертификат должен отвечать за то, что им было подписано недавно, за свои слова, так сказать :)) ). И в идеале сеть станет истино распределённой :)) И ещё: если идея будет грамотно доработана, то можно будет смело сделать много DA в сети и не бояться о том, что DA продестроит кого-то: я могу по своему желанию использовать 10-15 DA, скачивая с них статистику и вручную доверять/не_доверять загруженной статистике. каждый может сам интуитивно ориентироваться каким DA он доверяет больше, каким – меньше и т.д. В итоге мы получим уже давно знакомую схему сертификатов на сайтах: подтверждение разными DA ключей каких-то нод соответствует (по аналогии) тому, что сертификат для https с их сайтами был подписан разными CA. Мне уже начинает казаться что не были правы те, кто говорили, что все системы завязанные на единый сертификат, обладают защитой не большей некоторой... потому что технически такая схема вроде как дорабатываема до рабочей... Ещё есть такое понятие как онлайновое обновление статистики когда tor уже запущен: что тогда? Опять интерактивно спрашивать клиента, доверяет ли он обновлённой статистике? Или один раз спросить, а потом предложить использовать некую мнемонику допустимоого изменения статистики, которая в пределах отсутствия подозрительного? Вопрос вот в этой мнемонике, unknown уже сказал... Математически если выпендриться, нужно ввести адекватную метрику на множестве tor-статистик, учитывающую нашу модель безопасности, и потом сравнивать на каждом обновлении статистики полученную "разность" с "допустимой". И.. хорошо было бы дать возможность определять норму разности tor-статистик каждому юзверю мануально :=)) (например, для unknown'а если меньше 90% изменилось – то ничего страшного, а другие будут несогласны). В общем, метрика есть функция нескольких аргументов:
Но это всё так... в далёком будущем и в перспективе :)
Последние пункты следует читать так (опечатался):
SATtva
Это да, но здесь наполовину идёт речь о том чтобы изменить протокол :( Когда DA будет много, а степень доверия к ним будет разная, включать их все в программу не будут точно так же как сейчас не включают сертификаты всевозможных CA (очень точная аналогия), но... по желанию вы модете выбрать те DA (CA), которым доверяете, и впоследствии доверять только тем сертификатам которые подписаны не менее чем N различными DA (CA).
s/как сейчас не включают сертификаты всевозможных CA/как сейчас не включают сертификаты всевозможных CA в браузер/
soot
Следует понять почему нельзя доработать протокол до того что я предложил, и понять, даст ли это в итоге интегральное преимущество, и если нет – то почему (хотя бы примерно). Аргумент, что пользователям так много удобнее и "можно ни о чём не думать" не будет веским аргументом... для таких можно предложить какие-то умолчальные настройки по аналогии с умолчальными CA, встроенными в стандартные браузеры + дефолтные настройки барузеров.
Здесь tor-клиент = браузер достаточно точная аналогия.
SATtva
А если я не доверяю в полной мере Vidalia и предпочитаю что-то более близкое к ручному, нет ли альтернативы? Просто браузинг по инету в любом случае будет происходить без видалии... а потом ставить и разбираться с ней только ради этого не хочется.
P. S.: писать самому срикпт для визуализации цепочек не предлагать :)
Это всё уже лучше, но...
Вот SATtva уже нашёл существенную неточность формулировки:
сообщение не о том, что ключи DA поменялись (это абсурд – программа отвергнет их подписи),
а сообщение о событии, гласящее как минимум о том, что:
a) Почему то возможно скачать статистику только с DA – со всех других узлов или всё заблокировано,
или приходит что-то устаревшее или неверное.
b) Резко поменялись все или большая часть данных, подписываемых DA.
Всё это внятно формулируем по-русски, а уже затем пишем сообщение разработчикам на читабельном английском,
если будет ещё пара таких ляпов или неясный текст, то они не будут это читать до конца и вникать в наши предложения.
Нужно убедить их ещё, что от такой атаки есть смысл защищать пользователей. Это "простая" атака только для
очень "непростого" злоумышленника, они вполне могут вывести его за рамки модели угрозы, приравняв по мощности к "глобальному наблюдателю",
ну пусть хоть аргументированно скажут почему или приведут контрдоводы или укажут на наши ошибки.
Короче не стоит торопиться и второй раз морочить им голову плохо читаемой белибердой в моём исполнении :-)
Не забываем о том, что tor стараются сделать максимально прозрачным, простым для неподготовленных пользователей, автоматизированным,
а для анонимности необходимо, чтобы настройки у всех несильно различались, иначе озможны атаки разделения.
Если один пользователь будет "сильно анонимнее" других, то его наоборот можно будет легче отфильтровать на их фоне.
Все замороки с настройкой эвристик и доверия к сертификатам по умолчанию будут наверняка выключены и идти только
как advanced options, захотят ли разработчики таких сложностей, когда есть более прозаические задачи?
На самом деле, не до конца ясны возможные сценарии атаки, например Мэллори может используя фальшивые ключи DA
подписать левую статистику, в которой часть ключей серверов тора будет верной, но симулировать, перехватывая IP,
что они всегда в оффлайне или отказывают в соединении, если они входящие. Или не давать строить через них цепочки,
если они middle или exit. Т.е. банить те входящие узлы (а это просто, так как теперь есть guard'ы), у которых верные ключи
и давать на основе левой статистики возможность выбора только ущербных для пользователя (подконтрольных) цепочек.
Короче какие ещё могут быть трюки для поддержания у пользователя иллюзии того, что он работает в реальном tor'e, а
не в виртуальной сети?
Кстати, невидимый spinore, – вот Вамприходилось уже чистить кэш, потому что вас в торе "забанили", Вы проверяли что после этого
Вам пришло в качестве новой статистики?
можно воспользоваться tork, точнее его исходником, или почитать спецификации протокола управления Tor'a и получать всё нужное по telnet.
Можете сюда запостить вариант обращения к, попытаемся совместно вычистить ляпы.
Мне кажется, что здесь основная "непростота" кроется исключительно в том, что злоумышленник имеет право ставить оборудование на стороне провайдера. Однако, тор итак разрабатывается с учётом угрозы со стороны не "Васи с соседнего стола", а более серьёзной...
Где-то пробегал принцип о том, что реальная безопасность не может быть "автоматизированной, простой и элементарной для неподготовленных пользователей". Я к тому, что всё отличие между простыми пользователями и теми, кто будет использовать advanced options, будет на уровне клиента... со стороны всё будет выглядеть примерно одинаково.
Какие, например?
Это тот случай, когда следует прибегнуть к формальной логике. Указанные здесь вами атаки применимы "на ура" и к текущему протоколу тора, а предлагаемая схема усложнит их проведение, и этот факт снимает поставленный вопрос. Разговор о конструировании ещё более идеального случая от защиты от подобных атак – это уже второй шаг...
Нет, не проверял :( Более того, могу сказать что меня удивляет некоторые моменты в поведении тора (возможно, я параноик, да).
которая была зело длинной с подобной абракодаброй. Мне кажется, что подобное происходило не раз, а указанный IP был тем же (гарантий нет, не помню).
- При перестройке цепочек (может у нас так мало экситов?!) у меня чередовались IP из набора, как правило, 5ти штук. С течением времени они могли меняться. Мне бросилось в глаза что это постоянно были либо FR, либо DE, реже US, остальные страны – вообще редко.
Порой хочется визуализировать всю полученную статистику и видеть какой выбор предоставлен и что из всего этого выбирает клиент. Я всё могу понять, но если иногда доходит до того что не меняет экзит, то значит их действительно "мало" (!) либо выбор "странный". Всё это меня и смущает...Разумеется, когда я кэш стёр, против меня можно было нахаляву провести описываемую атаку :)
Ещё есть вот какая идея, по сути ваша же, но чуть доработанная :)
Предположим, что никто ни у кого серт не одалживал (не крал). Провайдер может закрыть доступ ко всем ентренс-нодам (точкам входа), которые не подконтрольны противнику. Тор будет попытается построить цепочки через них и у него ничего не получится, а вот через подконтрольные – получится. Далее есть 2 варианта:
Я тоже неоднократно замечал подобное. Такое ощущение что во всей сети есть всего лишь десяток ексит узлов.
Только писать не в or-talk, а на or-dev.
Темы про "ограниченное" число выходящих узлов постоянно возвращаются. Указаные "ограниченные" страны экзитов и составляют костяк группировки узлов, что есть то и выбирается. Не стоит забывать что выходящие узлы для трансляции во вне Tor применяют политику выхода (известную клиенту). Кроме того, клиент хранит историю (в пределах часа) по запрошенным ранее портам, для предупреждающего строительства цепочек. Таким образом клиент который серфит веб и читает почту, будет иметь меньшее число выходящих узлов для выбора при строительстве (предупреждающем) новых цепочек, чем клиент просто серфящий веб.
Алгоритм выбора такой что вероятностно будут выбираться чаще те узлы, чья скорость выше. Пример: Допустим за час работы, при заданной скорости смены цепочек раз в десять минуты (то есть всего 6 цепочек), вероятность заполучить один (из двух) достаточно скоростной узел в том же звене цепи (например 1МБ/c) дважды, трижды,... шесть раз, выше чем узел со скромными возможностями (например 100КБ/c). В действительности их больше чем два, и даже при двух, вероятность выбрать низкоскоростной узел остается. Такой алгоритм используется и для промежуточных и при отборе входящих охранных узлов (последние запоминаются и по возможности используются в дальнейшем). Плюс добавлен в алгоритм учёт длины цепочки. И в результате узел заявивший например 20КБ/c и будет выбираться пропорциональное его скорости число раз (в действительности очень редко) многотысячной армией клиентов и не будет причиной, теперь уже топиков про скорость. И если бы не качки терабайтов через Tor, искажающие картину, было бы всё совсем идеально.
Если хочется попробывать как это — когда совсем не взвешиваются скорости, можете попробывать исправить код и собрать (сохраните оригинал, наверняка на него вернётесь):
на код:
Такие же строчки можно найти для выбора промежуточных узлов. Поиск файла и строки и эти исправления, доверяю вам.
В идеале да, но в анонимных сетях желательно наличие как можно большего числа пользователей, разумный компромисс здесь всегда необходим.
Борьба за расширяемость (scalability). Борьба с Великим Китайским и прочими возможными файрволлами с помощью бриджей.
Вероятно и над немецкой проблемой разработчики тоже думают, что предложить операторам кроме middleman'ов.
Просто пока ждут что будет после вступления закона в силу, чтобы не торопить события.
Ну и слишком усложнять протокол тоже не следует. Туда уже и так много всего сложного добавили.
Думаю, идею с фактически новым протоколом, с опциональными DA пока стоит запомнить, но отложить на будущее.
остановимся на самом простом: введением опции для блокирования атаки... эээ (объявляется конкурс на самое
красивое название атаки, "unknown attack" – не катит :-). М.б. "Multiple Directory Authority keys compromising attack".
правильно, там будет самое место.
Поскольку, кроме SATtv'ы все подписываются псевдонимами или только ключами, письмо отправляем только
как коллективную анонимку от нашего сайта. Кроме того, проект tor разрабатаывается под лицензией BSD,
так что никаких копирайтов, "Non-Commercial"- или "гнутых"-копилефтов. Все высказанные идеи уходят в проект
без ограничений на использование.
Черновик письма вроде по-минимуму простой, а уже длинноватый. Существенных дополнений думаю за один раз не влезет.
Замечания? Ляпы?
Надеюсь, не придётся дописывать и отправлять, когда у разработчиков новогодняя полночь :-)
//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 authority and more than half of it in one jurisdiction (US),
and we must believe: owners of this servers really protects their server keys from compromising and free from
any third party evil influence ;-)
Key security and trust problem improved in v3 authority protocol, but not completely.
If third party agent Mallory have >50% of semi-trusted DA keys,
and have 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 propose a partial (very limited, but adequate) solution: tor client with active connection and relative "fresh" stats cache
may implement an analysis for suspicious activity of stats changes.
At most two criteria can be analysed:
1) If stats downloading from all of mirrors blocked or have invalid signatures and may be download only from semi-trusted DA.
2) Keys for tor nodes signed with DA changed significant (> 90% of all keys for example) in a very short interval of time
(suspicious for fake stats injection for user cache).
Open questions: How much keys it can be? How short interval?
...) Any other criteria of suspicious activity? Formal model for other possible attacks detection for tor clients?
After detect this type of activity tor client can log message:
-> Warning! Very significant part of tor nodes keys changed in a short interval of time!
-> If more then half of Directory Authority keys compromised, stats may be poisoned with a fake data.
Paranoidal settings for users in config file (client only section) may be:
StopTorIfTooMuchKeysChanged 0|1
Other open questions: only stop tor if user enables this setting and log suspicious event or do any other way to interaction?
What measures user can makes after that message? How to do with users with long period of inactive cache?
We have a long discussion and more noncompleted ideas on our site.
"OpenPGP in Russia Team"
Кстати, похоже разработчики думают вперёд нас,
возможно у них ещё много чего запланировано в новых фичах:
Tor прекрасно работает сам по себе, без всякой видалии и телнет-управления. :)
Насколько я помню закон запрещает все анонимные сети. Почему промежуточные узлы тора сюда не относится?
tor-simulation attack? (атака симуляции тор-сети)
Термин зависит от того что нужно подчеркнуть: что ключи DA "позаимствовали" или тор-сеть эмулируют?
Мой ник (spinore), ключ и ФИО всем известны, но
- не я один принимал участие в разработке идеи
- перемешивать сущности в одном пиьме – тоже не в плюс
так что ваш вариант, по-моему, самый оптимальный.authorities
its
these
and keep them free from any third party evil influence
Key security and trust problem are improved
If the third party agent Mallory has
and has an ISP level acces
relatively "fresh" stats вроде бы
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.
(После исправления опечаток я бы переделал так).
This case rises a suspicion about DA's IP interception authentificated with stolen keys
(Я бы написал так, но запятую перед authentificated уберите немедленно, это не русский язык. В английском запятая в этом месте эффективно играет роль начала нового предложения).
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.
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
P. S.: Товарищ unknown, исчисляемые: many, а неисчисляемые: much. Если не влазить в тонкости, мой вам совет: забудьте про употребление слова may в научно-технической литературе...
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 evil log event?
(Ну типа английская фраза не есть русская с заменёнными словами, т.е. часто буквальный перевод невозможен либо звучит не по-английски). Кстати, make – это обычно "делать" в смысле конструировать, создавать.
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" лучше, а то не так поймут :)
После ### ещё следует добавить:
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.
PPS: Под конец понял что проще было переписать с начала до конца и запостить сюда. Следующий раз, unknown, пожалуйста, пишите на русском, а я переведу. И... передайте той шифровальщице что вас учила английскому несколько ласковых слов от spinore.
s/and has an ISP level acces/and has an ISP level access/
Здесь не о том речь, чтобы работал, а о том чтобы функционировал надлежащим образом.
Да, интересно, но в любом случае надо написать: сообщение в talk, думаю, пойдёт только на пользу (и им и нам).
Я человек тупой и кондовый, а потому прежде всего смотрю на факты. Года 2 назад я чётко помню, как экзиты путём посылки сигнала -1 тор-клиенту менялись как перчатки, при этом тор функционировал достаточно шустро. Видимо, ключевое отличие, если атаки не происходит, лишь в увеличении отношения "число_нод/число_тор-юзеров."
Раньше её нельзя было варьировать, сейчас что-то поменялось? И в каких пределах можно менять?
Кстати, это повысит анонимность?
s/лишь в увеличении отношения/лишь в уменьшении отношения/
Этим сигналом и в 2 года назад и сейчас, происходит перезагрузка конфигурации, объявляются "грязными" все построенные до сигнала цепочки (с последующим их удалением, все новые потоки потребуют новых цепочек), и всё начинаете практически с нуля.
Лишь только при этом не происходит удаления тех цепочек которые уже задействованы существующими потоками (например при кип-алив до веб-сервера, IM, и т.д.)
Вы вероятно не наблюдаете всей цепочки и судите только по последнему звену, в то время как после hup'а ничто не мешает (кроме PRNG) выбрать тот же самый узел экзитом что и был ранее, с учетом всё того-же алгоритма взвешивания скоростей. Но цепочка наверняка будет, как минимум в промежуточном звене, совершенно другой. И даже если бы звенья новой цепочки совпали (что возможно, но маловероятно), сама по себе цепочка была бы новой (как с позиции клиента, так и всех узлов).
Менять через конфигурацию длину нельзя. Вообще это вопрос и ответ из faq'а.
Включение в расчеты — параметра размерности цепочки, при выборе узла в каждом конкретном клиенте, влияет на общую картину нагрузки сети. Эти изменения позволили (в теории) повысить общую производительность сети в 4 раза.
Вероятно нет, скорее понизит, изменения в алгоритме выбора выделяют такого клиента из общей массы. Вопрос только кто сможет это заметить (не считая глобального наблюдателя, но ему и так всё ясно).
Уж извините, господа, но нельзя же так засирать дискуссию. Spinore, потрудитесь хотя бы скомпилировать свои правки в единый текст, а то в таком виде даже читать не хочется, ей богу!
Не проще и не надо. Так всё сразу видно где ляпы и почему. И время экономится.
SATtva, у меня претензий нет.
Вроде так наоборот лучше понять, почему что-то требует исправления. Если бы было время, то открыл бы Вики-страницу с черновиком, но работа над ней отнимает гораздо больше времени. Нужно открывать и форматировать кучу страниц, ждать пока они загрузятся, после каждой правки проверять как они выглядят. Неудивительно, что вся разработка вообще консервативным способом обычно идёт в рассылках, а не форумах даже.
Для подготовки короткого письма, чтобы исправить только ляпы и безграмотность, достаточно кидать все замечания прямо в тему.
Пока все предложенные исправления подходят и будут включены в таком виде. Жду ещё поправок, раскиданных по теме как кому нравится, в пределах разумного. Если других замечаний нет, то ещё раз пишу окончательную версию письма и можно будет его отправлять.
Так там правки к правкам :) Отослал – увидел опечатку, а как исправить? Только ещё один комментарий писать. Я итак стараюсь не плодить лишних сообщений – всё включить в одно... но порой они столь длинные, что я боюсь что браузер сглючит, потому лучше отправить что есть и не рисковать.
У меня таковых вроде бы больше нет.
V0.02
//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 для этого[link3] необязателен.)
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 в данном случае делают сие "из каропки" автоматом. А как это проделать в ручную – надо читать спеки.
Кстати, s/mashine or claster/machine or cluster//g
Но раз SATtva вообще предлагает эту фразу выкинуть, то можно и выкинуть. Лишний раз навязчиво убеждать, что это атака реальна не стоит.
Для атаки виртуализацией tor нужен, чтобы после дешифровки траффик проходил через реальный tor и Алиса могла бы видеть ответы на exit-node IP через https.
Допустим всё верно, сравнение будет полезным инструментом при кешированной Алисе, и упорном Мэллори (запрет всех кроме своих узлов для клиента и так далее, включая учет туннелированных запросов клиента к произвольным кеш-директориям с заворотом), всё таки будет внедрена фальшивая статистика. При этом Алиса конечно должна быть очень терпеливой (а скачивая статусы через готовые цепочки, в n раз терпеливой). И не факт что большая часть пользователей не предпочтет, после 10-и минутного ожидания вообще всё переставить, или почистит кешированные документы, с итоговой нулевой полезностью новой функции.
Вот на эти доводы и надо делать упор. На приведенные симптомы аттаки, об отравленных статусах, можно получить предложение от разработчиков ознакомиться с TunnelDirConns и их заворотом в полноценные цепочки. (опции как раз для параноиков, как и предлагаемая :) На ограничение доступа к узлам, предложат ответить своим ограничением (StrictEntryNodes).
И начало в стиле описания уязвимости дважды устаревшего протокола, скорей послужит отправкой на чтение новых спецификаций, без анализа дальнейших, хотя и спорных доводов о недоверии к DA, и попытках реализовать проверку у клиента.
Мы знаем что так было. Сейчас нет. В текущий момент одиночная DA не может обмануть клиента ни на секунду. Впрочем и "открыть" ему глаза на подделку данных с большинства других DA, тоже не сможет. Менее половины списочного состава DA могут вообще "Войну и мир" в документы со статусами записывать, и при правильных диалогах персонажей, клиент не обратит на это своего внимания :)
Угу и они каждую новую спецификацию начинают с цитаты этой старой проблемы, затем пишут как они это решили, но не до конца.
Предлагаю тогда убрать для нашего письма цитату из спецификации вообще (они свою спецификацию наизусть и так помнят) и вместо неё придумать убедительный абзац:
"Основа проблемы в небольшом числе корневых нод и необходимости доверия к ним. Несмотря на сравнения подписанных данных, поступающих от разных DA, при наличии у злоумышленника закрытых ключей более чем от половины DA, он может производить различные атаки".
Ну и дальше, как у нас и написано, что типа в курсе мы про V.3 протокол, но проблема большинства там остаётся.
TunnelDirConns не сработает, если всё заблокируют кроме DA или испортят все другие коннекты битыми аутентификациями, то туннелиться будет не через что.
StrictEntryNodes – Пусть ответят, это параллельная и дополняющая мера. Ни одним из возможных способов полностью решить проблему всё-равно нельзя.
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.
protect так как множественное число
can make так как после can идёт инфинитив
can implement, ибо tor-client... да ещё и may... не... слишком большая честь. Я вам уже написал выше: на данном уровне познания английского в научно-технических текстах, включая компьютерную тематику, забудьте про may. Если вам нужно подчеркнуть смысл "делать с позволения" то пишите allowed. Ну в конце концов... есть понятие стиля речи. (Пример: в официальном стиле речи пишут "здесь", а ещё лучше "в расссматриваемом случае" вместо "тут", так же и здесь...).
Я написал большими буквами чтоб вы запомнили а не для официального текста!
s/MANY/many/
an opponent is able
И вашей шифровальщице тоже низкий поклон! "1:1"
Это нормально?! Имхо, это более чем вопиющая борзость! ... и подлежит немедленному исправлению.
Обменялись любезностями. :-)
Что не нормального, если по форме документа со статусами будет всё верно (про диалоги это преувеличение конечно). Допустим можно встроить функцию в клиента, сообщающую что DA создал (v2) документ содержащий какойто процент статусов совершенно неизвестных ранее узлов (вопрос как это отличить от факта более свежего документа с этого DA и ввода в строй кем-либо множества узлов разом, и какой должен быть порог), или исказил статусы большего чем нужно процента узлов (и опять вопрос в большей свежести документа и порога). Мэллори зная это, просто не будет отдавать документы данного DA, опять информировать клиента? А если DA реально не работает? Даже при редких действительных неисправностях и такой функции оповещения, рассылка и разработчики будут засыпаны почтой.
В текущий момент v3 (в альфа версиях) вообще отбирает право у клиентов выбирать статусы для узлов опираясь на документы составленные DA. Вместо этого создается документ-консенсус под которым подписывается каждый DA и который единственный, выкачивает клиент. С одной стороны теперь клиенту проще бы проверить подписал или не подписал, но в спецификации и коде не заложено отказа DA подписывать консенсус (он полагается на правдивость большинства). Проще говоря все те статусы что рассчитывал каждый клиент локально, теперь рассчитывают только DA. Но даже если бы DA перестал подписывать консенсусы (у Мэллори бы не было его закрытого ключа) по соображениям не согласия, отсутствие подписи можно было бы представить его неисправностью.
Думаю, в таком случае Мэллори просто будет отравлять не все дескрипторы одним махом, а станет делать это постепенно, стараясь не превысить пороговое тревожное значение большинства пользователей (итоговую картину можно будет списать на регулярную замену ключей узлов). Т.е. атака растянется по времени, но будет иметь тот же самый эффект, оставаясь необнаруженной. Адекватна ли в таком случае предложенная схема защиты?
Вот поэтому, по моему, единственного DA или меньшую половину списочного состава — проще игнорировать, чтобы они не документировали (даже если они единственные содержат настоящую информацию).
Для сравнения информации от большинства DA (или сравнения консенсусов, во времени), вопросы уже заданы.
Вот и надо выяснять, можно при особом желании и изменения за месяц (полгода, но кроме ключей надо учитывать процессы ухода старых и появление совершенно новых узлов) сравнивать. Поздно будет, но единственная цель сравнений это выявление катастрофы (если Мэллори разрешит Алисе это рассказать кому-то).
Узлы периодично (раз в неделю) меняют только onion-key, но signing-key по которым их идентифицируют менять не принято (операторы меняют их только при подозрениях в утрате).
Против этого пользователь может скачивать статистику через зеркала по туннелированию через
старые цепочки и сравнивать с более новыми версиями, и решать вопрос тоже
голосованием, если он будет часто получать блокировки или расхождение в голосованиях... то.
Короче про "замедленный вариант атаки" типа "delayed partial cache poisoning" разработчикам лучше пока вообще голову не морочить.
Может он неработоспособен. Спросим, если хоть как-то на простой вариант отреагируют.
В новой спецификации (v.3, а она в черновике и неполная) разработчики озаботились о том, что раз ключи DA имеют такую большую ценность,
то, как я понял, они решили, что хранить их на сервере опасно из-за возможности взлома.
Поэтому они предусмотрели относительно короткоживущие ключи, которые меняются примерно раз в неделю, а сами в свою очередь подписаны
долгоживущими ключами, которые используются для подписания короткоживущих ключей только в оффлайне (через дискетку они что-ли на сервер
это дело загружают?). Это уменьшает риск компрометации ключей путём взлома сервера, но никак не устраняет проблему гипотетического сговора
большинства владельцев корневых нод с третьей стороной.
Косвенно изложенную нами проблему разработчики признают (против компрометации более половины ключей протокол не защищает, корневых нод мало,
четыре из них фактически связаны с разработчиками, проблема их масштабирования до конца не решена, всё это они не скрывают, хотя и не афишируют).
Ну и что мы им в итоге хотим предложить? Ограниченное решение, которое пытается бороться со следствием, но не с причиной и ещё не известно
насколько успешно. Они могут проигнорировать всё это, поскольку в первую очередь надо подумать об улучшении расширяемости протокола,
чтобы не быть каким-то образом
привязанным к ограниченному числу корневых нод. Может у них какое-то мнение отложится и что нибудь сделают в далёкой версии абсолютно нового протокола.
Технологии типа peer-2-peer они конечно прикручивать не будут, хотя кто знает. И правильно p2p – это популизм,
на самом деле это только кажется, что это лёгкий способ увеличить
анонимность, а как выбрать правильный баланс между распределённостью и централизованностью неясно.
Главное, убедить, что проблему решать нужно и поставить все вопросы и сомнения, а они чтобы озадачились и что-то вероятно более грамотное, чем мы, придумали.
Слово "may" считаю уместным, поскольку это предложение к развитию и обсуждению идеи в весьма свободной форме, а не готовая инструкция
к действию и не приказ.
А у шифровальщиц мы похоже все чему-то не тому учились ;-)
V 0.03
Если не остановимся, то мы тут скоро весь протокол заново пересмотрим :-)
Multiple Directory Authorities' keys compromise: a partial solution for Tor clients protection
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 is able to conduct a multitude of 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 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 can resort to "heuristic" analysis for suspicious stats 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 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"
Схема защиты против этого дорабатывается элементарно. После каждой скачки статистики вновь полученное должно сравниваться не только с тем что было на предыдущем шаге, но и со статистиками полученными ранее. Нужно вывести эмпирический закон (этим лучше разработчикам предложить заняться): сколько в среднем новых нод появляется за период (например, 2 месяца) и сколько их низ меняют свои ключи, а затем сравнивать только что скачанную статистику на предмет удовлетворения этому закону. Если закон не удовлетворяется, то спрашивать клиента о доверии (можно опционально).
Ну почему. Прочитайте топик: я предложил несколько другой протокол, если стремиться к идеалу. Различных DA должно быть много, они должны синхронизированно иметь одну и ту же статистику, а клиенты – доверять некоторым из этих DA либо скачивать статистику со всех из них и потом оценивать вероятность подмены. Аналогия:
Моё глубокое имхо состоит в том, что протоколу тор ещё очень и очень далеко до совершенства, так что пересмотр протокола – дело обыденное.
Я прочитал. Условимся считать, что возражений не имею (разрешаю отсылку). Видно, ваш текст прочитала какая-то шифровальщица, и внесла свои правки, судя по тексту (которые явно не сводятся к моим и SATtva'овским) :)
Или просто пишем в спешке, оставляя глупые ошибки... К тексту замечаний не имею.
Напомнило "молекулярную агрессию в культурное ядро"[link4] Антонио Грамши.
Other open questions, поскольку Another – еще один
to raise a suspicion
Ладно, всем спасибо, думаю какие-то оставшиеся мелкие ошибки всё-равно неизбежны.
Поскольку принципиальных возражений нет, последний вариант уже отправлен:
http://archives.seul.org/or/dev/Dec-2007/msg00029.html
К сожалению, строки не отформатились по длине :-(, надеюсь они все письма из рассылки всё равно читают через mail-client, а не через браузер.
Чё-то ничего не пойму.
Никого не заинтересовало что ли?
Новых сообщений вроде БЫ нет в той[link5] ветке.
Вполне возможно, что не заинтересует.
Или не поняли и решили, что это повторение старого и известного.
Или озадачились и быстрого ответа сейчас нет, да и может он будет через месяц, если будет и
войдёт в какую-нибудь более глобальную работу, которую они пишут.
Или может просто в новой спецификации протокола черкнут пару строчек на эту тему.
А может, к концу года они решили отдохнуть. Вариантов масса.
Зато в пользовательской ветке, начиная с 30 декабря появились сообщения от пользователей
с массой странных ошибок в логах тор-клиента вида:
Утверждают, что этих ошибок раньше ни у кого не было (какое удивительное совпадение), а убедительного ответа
тоже нет. Хотя скорее всего это связано с ошибкой при введении третьей версии протокола и неправильно
обновлённым конфигом.
Раз уж я закрывал 2007 год в рассылке, то я же и открою 2008:
Вот исправленное по формату строк сообщение в качестве новогоднего поздравления:
http://archives.seul.org/or/dev/Jan-2008/msg00000.html
Но думаю более навязчивым быть смысла уже нет никакого, а то забанят ещё и в рассылке нафиг! Если проигнорят и на второй раз, то будем считать вопрос нерешённым и окончательно оставленным без внимания.
Это действительно ошибка владельца DA (он из США). И такие ошибки уже фиксировали ранее (для европейского DA). Кроме всяких технических ошибок с размещением сертификата и проблем на пути его доставки (вообще рано делать громкие выводы из поведения альфы), у клиента неудачно (это только мое мнение) выбран формат сообщения об этой ошибке, поскольку при отсутствии сертификата клиент не может знать signing_key (которым подписываются консенсусы), он знает только отпечаток долговременного identity ключа DA (которым подписывают сертификат). В результате и наблюдаются "пугающие" нули.
В любом случае, мы своё дело сделали. Я думаю, что если никто не ответит из разработчиков, то хотя бы кто-то из читающих рассылку отпишется (есть же там наверняка соображающий народ). В противном случае всё будет очень странным... скорее близким к тому что либо
- нас не поняли
либо- мы не понимаем как работает тор.
Первое означает неясное изложение проблемы в письме, когда все дружно решили что это сто раз обсуждавшаяся уже и замусоленная проблема, на которую есть тандартный ответ, а второе означает что ответ очевиден для тех кто знает протокол тора (то есть атака не пройдёт). Ладно, подожжом ещё, может что появится.По моему сеть i2p[link6] заслуживает не меньшего, чем Tor, внимания.
В новой нестабильной версии tor добавлена такая опция:
Судя по описанию, позволяет подкладывать старую статистику, если tor к примеру долго не использовался, для того чтобы иметь возможность скачивать новую всё равно по зеркалам, а не с корневых узлов.
Если использовать при этом скачивание статистики с шифрованием через TunnelDirConns, то значение DA для прямой манипуляции падает.
Да, но не панацея.
Мне сам дух не нравится: нет никаких принципиальных запретов строить распределённую архитектуру для сети, однако не торопятся, а скорее считают нормальным положением дел ограничить себя предположением о непогрешимости DA.
Roger Dingledine извинился за задержку
с ответом, но дал полностью
развёрнутое мнение по вопросу.
http://archives.seul.org/or/dev/Feb-2008/msg00003.html
Пока моя первая реакция:
* Нам удалось их слегка удивить
своими изысканиями.
* Со сценарием атаки они
практически полностью согласны.
В целом, если отбросить наиболее
параноидальные моменты, они
подвердили все наши идеи
* Почему тянули с ответом полтора
месяца
при активных ответах на другие
вопросы можно считать неясным
и даже подозрительным, как кому
угодно.
Но вежливо извинились и не
оставили без внимания, мы не зря
старались.
* Сомнения в связи с ничтожно малой
вероятностью атаки и бОльшим
ущербом в репутации от ложных
срабатываний можно считать
отчасти демагогическими, но как
разработчиков их тоже понять
можно.
* Они открыты к конструктивному
диалогу и интересуются нашим
мнением
Предлагаю обсудить будущее письмо
спокойно, не торопясь.
Мои только пожелания: на форуме
можно свободно высказывать любые
и резкие, и недоверчивые точки
зрения,
но в письме они должны быть
отражены в конструктивном и
дипломатичном виде.
Пока общая идея такая: да опция
"не для всех", недефолтная, для
особо продвинутых, но и активно
привлекающих
в сеть других пользователей. Её
наличие будет иметь
дополнительный, сертификационный,
репутационный характер, для
поддержания доверия к проекту со
стороны "параноиков" и как пример
того, что надо думать о
максимально независимой
реализации .протоколов.
После этого будем совместными
усилиями опять также переводить
послание на English, ok?
В качестве меры противодействия "глобальному заговору против Tor" ещё бы опциональные задержки пакетов в протокол добавить...
Вполне понимаю Роджера в его оценке возможных последствий от реализации подобной схемы. Здесь порочный круг. Реализация опции и её включение по умолчанию способны в ряде случаев привести к существенному наплыву обеспокоенных пользователей, не знающих как реагировать на сообщения, возникающие в логе. (Эти опасения особенно обоснованы, учитывая экспериментальность всей сети Tor и её перманентный бета-статус.) Если же реализовать опцию, но не включать по умолчанию, это снижает саму ценность схемы — обнаружение атак через DA. Тогда какой смысл её вообще реализовывать? Думаю, у разработчиков достаточно пунктов, требующих внимания.
Может быть стоит оценить предложение: написать скрипт, наблюдающий за состоянием кэша и сигнализирующий о его аномальных изменениях? Какие преимущества это даст:
При успешном результате эксперимента на скрипте нам будет куда проще убедить разработчиков Tor в действенности данной меры и в необходимости её включения в программу.
Я поначалу как глянул... подумал: unknown захотел описать ситуацию стихами! А только потом вижу что рифмы нет – лишь форматирование полетело :)
Поскольку оппонент всегда сможет понизить скорость передачи данных, задержки, имхо, не помогут. Идея хороша, если у вас есть гипотетический канал строго выдерживающий скорость передачи, которая не падает ниже минимума, и тогда вы что-то мостите... Хотя может я вас не так понял. Это типа полумеры в стиле закоса на покрывающий трафик или что?
Я предлагаю на будущее, чтоб текст переводил Зелёный :) Он иняз знает существенно лучше меня, судя по предыдущим правкам к тексту, а я потом скажу опечатки каких он не увидел. Больше у нас желающих кадров вроде нет.
Можно для начала принять аргумент "пусть только для параноиков будет" – это увеличит при прочих равных систему защиты. Далее судя по опыту её использования, отладки, можно будет в будущих версиях придумать и грамотную эвристику и азщиту уже "для всех". Порочного круга, то есть, нет. Это не окончательное мнение, если что придумаем разумное-умолчальное, то можно будет предложить и сразу как дефолт.
Аргумент очень разумный, но один момент меня оталкивает: кэш будет нас извещать постфактум, то есть после включения такого скрипта мы только начнём накапливать опыт по статистике завязанной на функцию, но не получим сразу же инструмент хоть какой-то мануальной защиты. Собственно, я выдвинул предложение больше с целью как можно быстрее обезопаситься от, и получить гарантии, а не только заниматься "научными исследованиями" статистики.
Новая конспиративная кличка? :-)
Проблема в том, что, в конечном счёте, решение о включении или не включении такого механизма защиты в Tor принимать разработчикам (самым параноикам они скорее всего предложат написать реализацию защиты самостоятельно). Чтобы они с большей охотой его всё-таки включили, нам таки придётся выполнить некоторую научную работу с целью хотя бы эвристики оценить. Наверняка это проще сделать на реальных данных, чем брать какие-то цифры из головы.
Да ладно, у нас ещё Красный есть! Ценный кадр :)
Мой ответ пожалуй распадётся на следующие 2: предложения по будущему дизайну сети тор и предложения по усилению защиты клиентов тор. Начну с более простого (прочитал снова весь топик, попытался сжать покопактнее всю идею):
Предложения по дизайну самой сети тор
Для рассмотрения эффективной надёжности анонимных сетей определим понятие "секрета сети", которым условимся называть минимальное число публичных ключей, обладание которыми позволяет полностью скомпрометировать сеть. В случае тор-сети секретом является совокупность ключей DA-нод. Мы понимаем правильный дизайн надёжной анонимной сети как тот, который
- обладает свойством как можно более равномерной распределённости "секрета" по хостам сети (принцип максимальной децентрализации), и который
- при разрастании сети имеет своим пределом случай "интернета поверх интернета".
В контексте тора мы имеем ситуацию с сотнями хостов, принадлежащих сети, но "секретом", распределённым лишь среди малой части его узлов – DA-нод. Возникает перманентное желание повысить надёжность сети, распределив её секрет по всем включённым в неё хостам. Аутентификация хоста происходит на основе асимметричной криптографии, для которой известны только два метода проверки валидности: "принцип доверия корневому сертификату" и участие в "сети доверия". Поскольку мы заинтересованы в максимальной децентрализации сети, возникает естественное желание организовать сеть доверия среди всех узлов сети. Здесь можно воспользоваться аналогией с сетью FreeNet, в которой все хосты равноправны между собой, и каждый доверяет только своим соседям. Предлагается организация схемы PGP-доверия в которой бы были обязаны участвовать владельцы нод сети тор, загружая свои подписанные ключи на DA-ноды. Условимся называть связку ключей PGP-сети доверия, в которых участвуют владельцы тор-нод, "статистикой ключей", чтобы отделять её от "статистики статуса", показывающей списки онлайн- и оффлайн-нод. Если опция проверки изменения статистики ключей и статуса, основанная на реальных эвристиках сети тор, будет встроена в тор-клиенты [примечание: смотрим секцию по предложениям для клиентов сети-тор, которая будет ниже], компрометация сети будет ограниченна только случаем атаки со стороны оппонента, так или иначе получившего контроль над большинством обычных тор-нод.Число DA-нод может быть сколь угодно велико при большом разрастании сети тор, при этом владелец каждой тор-ноды может иметь возможность сам выбирать свой список и число DA-нод, которым периодически сообщать свой онлайн-статус в сети, как и каждый тор-клиент может выбирать свой список и число DA-нод, с которых обновлять статистику статусов и ключей. В конечной перспективе такой тип сети будет напоминать "интернет поверх интернета", где каждый пользователь сам выбирает список CA-центров, подписи которых он доверяет, и список PGP-ключей, глубина доверия которых (в PGP-сети доверия) считается им удовлетворительной. Заметим, что сейчас доверие к ключам тор-нод основано лишь на единственной подписи, созданной DA, в то время как в предложенной схеме весь файл статистики будет представлять собой связку PGP-ключей сети доверия для тор, а сам DA будет играть роль и локального сервера PGP-ключей в общепринятом смысле.
Простейшей мерой может быть возможность указать, сколько пакетов пропустить вперёд себя перед отправкой. Это не потребует дополнительных ресурсов, и увеличит скорость у тех, кто предпочитает скорость, за счет тех, кто предпочтёт большую безопасность – затруднение корреляции. На случай малой нагрузки на узел, когда долго нет пакетов, имеет смысл указывать максимальную допустимую задержку. Задержку можно указывать относительной к времени передачи между узлами – для предотвращения указанной вами атаки искусственного понижения пропускной способности сети. Может быть имеет смысл указывать и минимальную задержку, которую можно будет и не соблюдать при переполнении очереди.
Да, самое важное найти правильное решение. Но надо ещё думать о том, как его представить разработчикам, что верно подметил SATtva.
- Надо убедить (отчасти это удалось), что проблема реальна. Да, разработчики не сталкивались с такими атаками, да такой атакующий может быть слишком гипотетичен. Но если он появится, то это будет плохо. А поскольку часть пользователей об этом уже знает, то есть недостаток доверия. Пусть разработчики покажут пользователям, что они делают какие-то шаги в сторону прозрачности и децентрализации.
- Решение ограничено, это ясно с самого начала. Вопрос "это лучше чем ничего?" или "Защита хуже чем сама опасность?". Как бороться с эффектом ложных срабатываний сигнализации, когда злоумышленник нарочно изводит пользователя ложными срабатываниями, а затем ждёт, пока он отключит или станет игнорировать сигнализацию? (это как редкий, но иногда эффективный способ ограбления или угона авто).
- Опция для параноиков не имеет ценности? Параноики могут предупредить остальных. Правда их можно перед этим многократно дискредитировать по пункту 2. Как этого избежать? Если у них не было перед этим работы с контентом, подрывающим их анонимность, они могут сохранить подозрительный кэш для проверки и последующего предъявления и доказательства того, что кто-то ставит левые подписи. Кроме того, есть же отключенные в некоторых дистрибутивах по умолчанию или ограниченные опции в ядре Linux (boot selinux=0), чтобы не смущать большинство пользователей. А есть наоборот укреплённые версии для защиты от особо сильных атак. и они тоже дают много ложной тревоги в логах. Если есть "hardened kernel", почему не может быть "hardened tor"?
- Что делать пользователю? При малейшем сбое в сети выдёргивать шнур и думать о конспирологическом заговоре против сети TOR, как иронизирует Роджер? Или действовать по принципу "Вроде опять какая-то атака. Нажмём OK и продолжим работу". Это зависит от уровня параноидальности пользователя. Например в первых протоколах квантовых каналов связи считалось нормальным при обнаружении аномалий в канале, подозревать худшее – атакующего и прекращать согласование ключа. Затем были разработаны более сложные протоколы: можно без риска согласовывать ключ при потере или умышленном искажении параметров части фотонов, только снизив пропускную способность канала – "квантовое согласование ключа в присутствии злоумышленника". Почему бы не ввести пока первый вариант для желающих?
- Вынести это всё в виде сторонней утилиты? Получать данные по статистике через контрольный порт tor? Но у параноиков он выключен. тем более, после уязвимости с ним связанной. Выключен он и в конфиге по умолчанию (кроме установки в связке с Видалией на Windows).
Анализировать кэш скриптами? Во первых, после того как изменили формат статистики и разбросали её по разным файлам это сложно, во вторых он большой и анализ всех файлов (их около 3 Mb) будет проиходить медленно, даже если написать утилиту парсер-анализатор. С чисто исследовательской точки зрения это конечно полезно. Но возможно ещё более непрактично. А вот сам клиент получает данные порциями, которые и может анализировать по частям, сопоставляя с тем, что уже получено.Похожее решение есть в дистрибутиве Debian GNU/Linux:
пакеты можно скачивать с сотен зеркал, проверяя их подписи. Зеркала иногда взламывают, иногда они падают и т.д., но security обновления можно скачать только с центрального кластера. Если с ним что-то случиться, больше шансов это заметить.
В TOR аналогично: DA удостаиваются чести намертво вшить свои сертификаты в пакет. И можно пытаться отловить ситуацию если с ними что-то не так.
От чего строить доверие, если каждый может быть DA? Злонамеренный exit-node может что-то делать с проходящим трафиком, это ещё можно как-то пережить, но DA может участвовать в атаках на раскрытие анонимности. Сколь угодно много этих DA бы ни было, но рано или поздно на такого DA пользователь наткнётся.
Если проблему доверия DA вынести ещё на один виртуальный уровень, можно сконструировать новую атаку, наподобие изначальной, тоже на новом уровне. "Reflection on Trusting Trust" problem.
Судя по этому сообщению, spinore, Ваша идея о множестве DA поддержана не будет:
http://archives.seul.org/or/talk/Feb-2008/msg00150.html
Их не{на}много увеличат, но они все будут держаться на репутации известных в коммунити владельцев, так чтобы их было немного и они все были на виду. Запустить свой и для себя никто конечно не мешает, но вы выделите себя в анонимности среди общей массы. Плюс где-то раньше у них говорилось об опасности атак разделения.
Новые правила ужесточают требования к владельцам DA:
authority-policy[link7]
Обратите внимание, что лично Роджер является главным арбитром. Доверие во многом строиться вокруг него.
[offtopic]
"Бешеные псы" Квентина Тарантино: Mr. Green, Mr. Red, etc. :-)
[/offtopic]
[offtopic]
;-) А spinore кажется когда-то кирпичём был, а сейчас находится в состоянии неопределённости и квантовой спутанности, как "кот Шрёдингера": не поймёшь то ли он есть, то ли его нет.
[/offtopic]
А если включить debug-уровень, разве в нём не будет содержаться вся нужная нам информация? Тогда работа выглядела бы как
Где unknown-analyzer делал то что предлагалось делать скрипту и выводил сие на панель, ну напару писал бы и типичную информацию, что пишет
Каждый может стать CA и начать выдавать сертификаты, только вам многие поверят? Но заметьте что раличных CA (рассмотреим только те что встроены в браузер), много больше чем 7. Здесь – ты же штука. Каждый DA может заработать себе репутацию, потенциально... а пользователь волен выбирать кому он доверяет больше (видимо, в зависимости от задачи и от того, от кого он анонимизируется).
Естественно, вы меня предвосхищаете :) Я хотел написать но забыл. Да, получим
фрактальнуюпирамидальную систему: от доверия к тор-нодам к доверию для DA, от доверия к DA к доверию super-DA и т.д. Но реальный интернет обошёлся пока что одним слоем – CA. Видимо, его почти достаточно.Опять же, я не хотел сказать что это предложение по поводу ближайшего будущего. Скорее, это моё видение того во что должен превратитсья тор по прошествии длительного времени, если ему дадут ходу. Да, они боятся атаки разделения, я их понимаю, но когда сеть станет очень большой такая атака рано или поздно произойдёт. В конечном счёте тор-team будет лишь группой, отвечающей за исходники. Мне так кажется. Что касается в целом атаки по дискредитации анонимности будучи злонамеренным DA-узлом, можно упомянуть про обязательное участие в сети доверия для тор-нод. DA, конечно, сможет сказать что ключи для части тор-нод сменились, но на них не будет покрывающих подписей других узлов тор-нод, а грамотный клиент настроенный с учётом разумных эвристик сразу скажет "баа!! 50 узлов новых враз появилось, никем их ключи незаверены... откуда бы они так?". Или ещё "О! Ключи все ОК, только почему то вдруг DA говорит что 97% хостов вдруг оказалось в дауне, чё правда что ли?". Схема многоуровневая просто... и в общем-то я её продумывал. Начинаем с разделения статистики ключей и статистики саттусов – это важный момент. Таким образом теперь есть только 2 атаки:
В идеале можно представить себе много анонимных групп в интернете, каждая из которых прячется от своей угрозы. Это и определяет список DA. Для малых сетей – да, лучше то что предлагает Роджер. Я всего лишь хочу чтобы он в рамках хотя бы своей тор-сети перевёл протокол на тот, который кастрирует права DA и уменьшает число атак основанных на злоупотреблении авторитетом DA. В конечном счёте, если я нигде не ошибся, если пользователь скачал правильные исходники тор, то единственная остающаяся атака – постепенное введение (!) [враз ввести не получистя при грамотной диагностике] в сеть тор подконтрольных оппоненту узлов пока их число не достигнет уровня, достаточно для проведения атаки. Ну и атака на корреляцию трафика – это уже классика :)
P. S.: ещё можно пофантазировать насчёт протокола, в котором общеизвестны лишь exit-узлы тора, но не знаю реализуемо ли такое хотя бы теоретически [это в целях нейтрализации атаки на корреляцию трафика].
Да и все их вшить в tor, как в браузер?
Они не голосуют между собой за единый результат аутентификации. Сайт аутентифицирует любой из них. Это как в старых версиях тора, подписать статистику мог один любой DA.
Пожалуйста, хоть сейчас – запустите свой DA и уговорите его прописать кого-нибудь в конфиг. Такая возможность есть. И выделяйте свою группу.
Идея существующего протокола в том, чтобы все пользователи с минимальной рассинхронизацией получили одинаковую статистику, иначе их можно будет разделять.
Какая может быть сеть доверия между DA? Вы с ними в форуме задушевные беседы ведёте? Их можно только мониторить предлагаемым способом на предмет отклонений. Но Роджер справдливо отмечает, что ситуация когда куча ключей поменяется разом, может возникнуть запросто: поставили новую альфа-версию, там баг, откатились назад и др. ситуации. Вот в чём проблема то ещё. Сеть сама по себе нестабильна и её может лихорадить из-за всяких сбоев.
Роджер мог бы подписать ключи тех DA которым он доверяет. Самому тору достаточно иметь ключ Роджера, а пользователи могли бы сами доставлять ключи DA. Моя идея в этом плане возможно бредовая, это всё так, на уровне "мысли". В принципе вы справедливо отметили что никто не мешает поднять сейчас свою тор-сеть если кто-то восхощет.
Ну откатились так откатились, а почему при этом ключи тор-нод-та должны смениться? Да и их статус, в массовом порядке... Не вижу связи.
Вот эту идею пока только и можно продвинуть. Пусть в логах пишутся при максимальном уровне настроек сообщения о подозрительной сетевой нестабильности. И пусть будет возможность выключиться и сохранить кэш со статистикой. Для желающих. По аналогии "hardened kernel" – "hardened tor".
Вот ещё идея, родилась прямо в этой строчке: пусть DA ведут публично доступные логи с хэшами всех когда-либо подписанных ими ключей. Ну или за год хотя бы. Пусть желающие эти логи зеркалят. Чтобы или можно было заметить, что DA подписал ключ, которого никогда в сети тор никто не видел. Или чтобы кто-то хотя бы по прошествии времени мог убедиться с помощью другого компа, или через PGP переписку с друзьями из другой страны, что ключ тор узла извлечённый из кэша клиента, который подписан верной DA подписью никогда ни у кого не встречался и ни разу не проходил в логах ни одного DA.
Хотите уменьшить полномочия DA? Надо ставить задачу о введении системы аудита! Распределённого криптоаудита всем сообществом, если угодно. Думаю пару заинтересованных человек наберётся :-)
Кстати не знаю, меняется он при переинстале или нет? Наверное всё-таки нет.
Обратите внимание на последний абзац[link7] и дату создания документа (она была 13 февраля).
Роджер уже и так обеспокоился насчёт DA, рапределения юрисдикции и предпочитает всех владельцев знать лично (или видимо пристально смотреть им в глаза на коференциях).
Зачем подписывать их ключи, когда они есть в исходниках, которые естественно подписаны всеми разработчиками?
Откуда?
Типа свободного выбора вместо авторитарного метода назначения DA?
Чтобы спастить от сговора DA против пользователя?
Но как проверить, что ключи принадлежат доверенным и неподконтрольным владельцам?
Как согласовывать результаты голосования групп, выбранных разным методом?
Так мы можем обвинить в чём-то DA, а при свободном выборе может набежать куча самозванцев и саботирующих элементов, которые будут тыкать друг на друга пальцем: "это он виноват".
Это допустимо для обычных узлов. Но для корневых DA нужен полный консенсус и слаженность. Поэтому их и не промасштабировать. А то мы придумываем какую-то "Кащееву смерть" в виде спрятанной иголки :-)
Могут просто потребовать сдать ключики с 50% DA и участвовать с честным видом в сети доверия. А ключики и подставной узел будут применяться только против одного пользователя или нескольких несвязанных. В чём сеть доверия? Как пользователь докажет своё недоверие, как он может исключить DA из этой сети? Только предъявив левые ключи, подписанные DA (если успеет это сделать). Если 50% DA нельзя доверять, то можно ли доверять остальным?
Ключи украдены или начался заговор против tor?
Мне кажется разработчики тоже об этом думали и озадачились :-)
Мне кажется нужно предложить идею аудита логов DA. (См. выше).
Токмо ради истины:
Ноября. Но сам документ был написан в октябре (странно но найти правки за ноябрь не смог, непонятно почему дата изменилась с октябрьской), тогда же были описаны условия к DA боротья до последнего, и быть из "свободного" государства.
Спасибо. Вы только что могли наблюдать первоначальные проявления параноидальных глюков :-)
Я пока думаю над идеей, скоро озвучу что предлагаю написать им в ответ.
Понял. Поддерживаю. В письме про это напишем.
В юникс не принято при сносе/переинсталляции изменять настройки, хранящиеся в домашней директории. Насолько я помню, тор также смотрит на наличие файлов настройки предыдущей версии, в "/usr/pkg/etc/.../" и то ли по датам смотрит, то ли по изменениям... и если видит что изменялись то не переписывает на новую версию. Вообще, это типичное поведения для unix-программ.
Я его понимаю и поддерживаю. На данный момент видимо это самое разумное решение. Но Роджер не будет жить вечно, и т.д. Все мои рассуждения строились на аналогиях DA с CA. Я не вижу столь концептуальных отличий. Заметим, что последнее время с CA пришли некие изменения к пониманию: доверять CA нельзя, так что можно свой серт не подписывать ничьим сертификатом, зато своим юзверям сообщить правильный сертификат своего сайта, чтобы они его прописали в браузере.
Ну типа да – это как использование CA cert которым подписан сертификат pgpru.
Полностью неподконтрольных не бывает ибо все мы люди, но есть эвристики, как и с сертами. Вот, авторитет Роджера – одна из таких эвристик :)
В любом случае подразумевалось что DA будет не так много и т.д. Человеку с улицы, то есть, естественно, не поверят.
И давно это у нас Америка и Европа стали свободными государствами? Америка прослушку своих граждан активно ведёт, Европа собирается запретить все анонимные сети... ЬI?
Моё рациональное внутри меня мне говорит что халява с тор не может длиться вечно. Во время когда вместо большей и большей свободы внедряются повсеместно всё более и более тотальные типы контроля анонимным сетям не место. Если бы кто-то слил инфу по поводу того что там в высших ешелонах думают по поводу тор, можно было бы жить спокойнее. Про мрос вот, и про рельную безопасность браузеров правда, например, более-менее уже известна.
Во-первых, чтобы атаку которую вы описываете, можно было провести, нужно долго и постепенно вводить новые виртуальные подставные тор-ноды для тора. Если ввести сразу из в вашу ацкую машинку (тор-симулятор), то детектор подозрительной активности загноит сей косяк. Таким образом, надо чтобы машинка применялась к выделенному пользователю втечение долгого времени, постепенно добавляя всё новые и новые подставные хосты. Но тогда атакуемый может хотя бы раз в неделю скачивать статистику по третьему каналу и сравнивать её с тем что у него в логах – не появилось ли много лишних нод и не сильно ли сменились ключи нод. Сеть же доверия нужна для хоть какого-то дополнительного контроля за ключами тор-нод. Если я знаю хотя бы несколько людей которые тоже поддерживают тор-ноды, если я хотя бы общался с ними в сети, я могу подписать их ключи засвидетельствовав этим, что в некоторой мере доверяю им (что такие тор-нод хотя бы РЕАЛЬНО существуют, а не только в машинке симулятора).
Основная суть в том, что скачав верные ключи для всех нод и статистку онлайн/офлайн, уже можно надолго забыть об атаке подмены ключей/статистики, ибо там идут малые колебания вокруг некоего "среднего". Надеюсь, понятно изъяснился.
"ибо там идут только малые колебания вокруг некой "усреднённой" статистики" имелось в виду.
Да, жду с интересом, надеюсь не только я.
Аналогия – Л. Торвальдс или Theo de Raadt
Свобода относительна. Проще там хотя бы об этом узнать. Как власти делают это в других странах узнать сложнее.
Плюс хотя бы иногда слабый может выиграть судебный процесс против сильного: например Hepting против AT&T или даже можно выиграть судебный процесс против государства, см. дело криптографа Bernstein vs USA[link8] или хотя бы здесь[link9].
Хотя эффект от таких процессов не очень велик, прослушивание продолжается и т.д., но наиболее грубые злоупотребления это предотвращает.
Что-то мне трудно представить даже показушных процессов "Слушается дело: Вася Пупкин против России".
Может это естественная уравновешивающая сила?
Тупо фигеют. Или борются разными группировками по поводу разных вопросов. У них и более сурьёзные проблемы есть. Думаете какая-нибудь Ангела Меркель что-то знала про ремэйлеры, когда в Германии принимали закон ограничивающий анонимные сервисы?
Так это вручную будет делаться, напишите письмо, пообщайтесь, у них abuse-адрес есть. Как ключ поменяется, спросите в чём дело. Только ещё и это придётся делать анонимно. А то вдруг вычислят и их ключи подменять не будут, не будете же вы только через них ходить. Кстати, это в чём-то близко к входящим guard-нодам, только тут вы их выберете сами.
С другой стороны для кого важна ваша подпись? Для тех кто знает вас? А кто не знает. Кто-то без репутации может наподписывать кучу ключей нод, а затем отозвать подписи. И что это будет значить? Вообще тор для скорости работает с относительно короткими ключами и не считает никаких сетей доверия. Сети доверия ещё подобны социальным сетям, а они потенциально подрывают анонимность.
Можно ли переносить в TOR какую-либо модель, изначально рассчитанную для privacy, но не для anonymity?
Какой Вы добрый, spinore. Но даже если формально; действительно думаете, что подобные по структуре анонимизирующие сети, переживут и Вас в том числе?
Уверен что будем наблюдать еще 3-е и 4-е и n-е поколение, хоть бы и с прежним названием. Каждый узел будет посредником (bridge) и DA (функции изменятся конечно), и будет сеть бескрайней и не будет видно с одного края другой (clique mode) — ляпота.
Специально для вас и взято в кавычечки. На самом деле именно фразы про свободу в документе нет. Будем считать что вычитал между строк (там где спецслужбы будут гуманны и разрешат, что-либо владельцу DA разгласить).
[offtoпег]
Раадта знаю, а Торвальдс – это кто такой? :)
[/offtопег]
Я не вижу никакой особой деанонимизации в том что кто-то подписывает ключи кого-то. Многие, имхо, на это бы пошли. Есть такое понятие как фринет – там делается тоже самое в нынешнем протоколе – я выбираю себе соседей, даю им свой адрес и IP, а они мне – свои. В идеале соседи по фринет – это мои знакомые которым я доверяю (из разряда вопросов "откуда мнея взять надёжных "пиров"?"). Владельцы многих тор-нод могут быть выявлены – они не анонимны, анонимна лишь сама передаваемая информация по сети. Я согласен что это некий эффект деанонимизации, рассказывать каким тор-нодам я, как владелец тор-ноды, допуситим, доверяю. Вопрос даст ли это существенные преимущества в защите тор, и стоит ли эта деанонимизирующая поправка выделки. Вопрос открыт. Я не говорю что этому должны следовать все владельцы тор-нод, это должно быть опциональной фичей, но рекомендуемой. Например, если Роджер лично знает массу владельцев нод, почему бы ему не подписать их ключи явно? Подчёркиваю, что вопрос пока вполне открытый касаемо сети доверия и перекрёстных подписей – я просто хотел сделать "заверение статистики ключей" эффективным метанаблюдателем – всей сетью, то есть сетью доверия, вместо того чтобы поручить всю ответственность одному лишь DA. Клиент может проверять перекрёстные подписи не каждый 15 минут, а хотя бы иногда... хотя бы только при старте тора.
Мне это напоминает аналогию между PGP и OTR. Когда генерируется otr-ключ для шифрования по DH, PGP используется для заверения отпечатков, вроде бы, но тем не менее доказать что я говорил именно то что говорил нельзя, несмотря на участие PGP как компонента схемы. Я тонкости не понимаю, но мне так объясняли.
Когда обсуждается дизайн сети, иногда нужно думать на много лет вперёд, чтобы не оказываться перед проблемами типа ipv6 вместо ipv4 и т.д. Там где-то в инете была целая подборка смешных "прогнозов" на будущее, которые утверждали чего в будущем заведомо хватит. Следует понимать, что ошибившись с дизайном потом можно долго растить костыли и платить куда большую цену чем за грамотное начальное проектирование. В этом смысле рассуждения о том что будет "когда ..." не столь глупы. Всё-таки не серьёзно привязываться к конкретному человеку в проекте. Проект должен быть устойчив и без его создателя. Например, как недавно сказал Линус Торвальдс, проект Linux сейчас практически не почувствует ничего если он уйдёт из проекта – он там один из многих и вполне заменяем, и это верно. Если мы хотим проект, который бы был надёжен, он должен быть поминимуму зациклен на человеческий фактор. Само начинание (тор-проект) мне нравится, и я не вижу причин почему оно должно умереть (если только ему очень "помогут").
Все тонкости только в том, что: доказать нельзя, отследить можно. Вы можете только утверждать, что подписанное после завершения аутентифицированного сеанса могло быть подделано кем угодно, начиная от вашего собеседника, которому вы можете не доверять, что он вас не сдаст с подписанными вами запретными заявлениями. Как это перенести на тор или сети доверия не понял. Сети недоверия пока ещё не изобрели.
Кстати, тут есть какой-то тонкий момент. Какого типа ещё специальные проверки разумно было бы осуществлять на старте? Или раз в сутки при полном устаревании кэша, если периодичность обновления его была невелика?
Чтобы выбрать наиболее надёжные пути получения статистики?
А не надо переносить. Просто на уровне аналогий вспоминилось.
Мне нравится предложение unknown'а о системе аудита DA. Да, в "академических" криптопротоколах принята концепция упреждения: если вы раз облажались — вам хана. Практическая криптография, однако (в основном в финансовой сфере), зачастую полагается именно на средства обнаружения.
Я не поддерживаю переделывание протокола. Во-первых, сейчас это вообще бессмысленно, сеть слишком мала. Во-вторых, я сильно сомневаюсь, что разработчики Tor'а, изучающие анонимные сети на научном уровне, не задумываются над такими вопросами, как масштабирование доверия. Мне кажется, мы тут просто будем изобретать велосипед.
Если же исходить из текущего положения дел и пытаться улучшить конкретную ситуацию, в которой мы находимся, аудит — это первый шаг. Он не должен приводить к ложным срабатываниям, а значит и наплыва пользователей не будет.
Только в реализации этой системы на уровне DA, мне кажется, есть проблема. В специальной функции публикования заверенных ключей и зеркалирования этих списков нет особого смысла. В сущности, каждый клиент и так собирает все ключи, заверенные DA, в статус-документах. Так что это дело каждого клиента накапливать эти записи и сохранять до лучших времён, чтобы потом сверить их с аналогичными записями других клиентов.
Решение, в общем, уже продумано, осталось лишь всё внятно непротиворечиво изложить и отдать на суд читателей. Стоит отметить, что только что высказанное пожелание SATtva'ы оно учитывает. Единственное что мне не очень нравится, прийдётся ввести около 10ка новых дополнительных опций для конфига и это число особо не ужимается.
Они указывали, что число DA не будет больше примерно десяти.
Нужна лог в виде базы данных с поиском по хэшам ключей. Мы исходим из того, что клиентам могут подбросить ложные ключи. И это не те ключи, которые DA раздают массово всем. Клиенты могут проверить при подозрении их соответствия (теряя при этои часть своей анонимности на текущий сеанс). Но тот же Мэллори может заставить изменять записи в этой базе, а если клиенты будут сливать туда свои ключи, то там будет полный трэш из верных и неверных ключей. Подмену могут сделать и на зеркалах.
Единственное на что можно опираться – на метки времени, которые должен отправлять на DA каждый tor узел, тогда записи в логах будут соединены этими метками и задним числом править отчётность будет нельзя. нужно поймать DA на том, что они не раздавали в какой-то момент времени ключи, которые в этот момент существовали у пользователей.
Вот что у меня вырисовывается, как краткий
вариант письма, не перегруженный далеко
идущими планами
(метки времени оказались не нужны):
пользователей тора делим на две группы:
простых и продвинутых (advanced).
Advanced пользователи могут помогать простым
пользователям, популяризировать tor и т.д.
Они могут также научить обычных
пользователей использовать (open) PGP для
организации
сети доверия.
Для advanced пользователей предназначены advanced
options. Между advanced-пользователями существует
сеть доверия на базе (open) PGP. Эта сеть
используется для аудита деятельности DA и
обмена информации как
между собой, так и между простыми
пользователями.
Таким образом предлагается концепция
наблюдателей (tor watchers).
Итак их задачи: детектирование атак, аудит
работы DA, координация.
Вот как выглядит аудит
В обычном случае для отправки статистики
сети DA подписывают весь список ключей tor-узлов
целиком.
Подписывать каждый ключ затратно. Но раз в
сутки
DA обязан подписать каждый ключ по отдельности
и выложить в общий доступ в отформатированном
виде.
(Публичный отчёт работы за сутки).
Tor watchers проверяют, что список корректный (в
нём не содержится ключей, которых бы не было
в общей статистике),
подписывает своим PGP ключём и размещает
на своей странице или просто хранит у себя
список за те числа, когда они
были в Интернете.
Раз в сутки также каждый tor watcher экспортирует
принятые тор-клиентом за корректные
публичные ключи тор узлов из своего кэша и
сохраняет их,
сверяет со списком от DA.
Периодически tor watchers связываются друг
с другом и пытаются выявить ключ, не
содержащийся в статистике.
Особым поводом к этому является срабатывание
детектора атак.
Tor watchers могут попросить поставить опцию
включения детектора атак озабоченных данной
темой обычных пользователей
с которыми у них есть доверие, чтобы они могли
задетектировать атаку. В случае срабатывания,
они просят высылать им по (open) PGP
списки ключей DA для сравнения. Если
пользователь не находит полученных
ключей, они считаются подозрительными и
отправляются
наблюдателям на дальнейшее выяснение, после
многократных обменов, сверок списков DA можно
установить и скомпрометированный DA и
выявить посторонние ключи как
доказательство.
Таким образом проблема решается не беспокоя
разработчиков, а между пользователями и
наблюдателями и возможно владельцами tor узлов
и только при обнаружении серъёзных
доказательств выносится на обсуждение.
P. S. Это как защита дома от молнии с помощью
громоотвода – если она есть, то молния скорее
всего не попадёт и кажется что она не нужна.
Она ведь и так редко попадает. Но последствия
попадания могут быть разрушительными. Проект
"ThunderTOR"?
ммм... можно ссылку?
DA всегда обязан отдать список с дескрипторами, подписанный своим ключом. Но, это v1 протокол директорий, и там никогда не подписывают каждый дескриптор каждого чужого узла в отдельности. Очень подозреваю что этот протокол будет выведен из обращения вскоре после удачного нового релиза. Надо опираться на v3 в котором DA подписывают консенсус-документ содержащий отпечатки идентификационных ключей узлов и дайджесты опубликованных ими дескрипторов (клиенты выкачивают дескрипторы адресовав запрос с этим дайджестом к зеркалирующим директориям). Сами дескрипторы проверяется на целостность и просто хранятся в кешах директорий.
С unknown'ом по большей части не согласен. Громоздко всё. От pgp-сети доверия видимо надо будет отказаться, ибо преследуемые цели можно достичь без неё – есть более простое решение. В педелах часов 2 напишу, сейчас просто занят.
Для начала обсудим схему безо всяких перекрёстных PGP-подписей и сетй доверия. Также, опустим принуждение DA к аудиту. Ограничимся лишь доработкой функционала тор-клиента. При введении нового термина я буду брать его в кавычки.
Предложения по улучшению диагностики тор-клиента
Я не очень хорошо понимаю протокол тора, потому буду использовать следующую ограниченную модель: клиент каждые несколько минут (15?) скачивает "статистику", где находятся ключи всех нод ("статистика ключей") и информация о том кто онлайн/оффлайн ("статистика статусов"). Технически эта статистика может быть записана в некоторый файл ("файл статистики"). Если мы выкачиваем статистику время от времени, её можно сохранять в разных файлах: каждой статистике – новый файл. Предполагается что есть сторонний скрипт, который может выполняться как тором [ниже будет описано] так и вручную пользователем, и который умеет строить условный "tor-diff" между статистиками (показывать как изменилась статистика ключей и статусов, подробнее – ниже).
Отдельно следует упомянуть про беспредел в протоколе общения тор-клиента с DA. Во-первых, в файле статистики должна храниться, естественно, информация, каким DA они подписана. Нужно писать полностью: к каким DA был послан вопрос, от каких был получен положительный овтет с подписью статистики, от каких получить ответ не удалось, и какие DA подписали статистику не верно (или не подписали вообще). Вся эта информация должна писаться в логах уровня notice и в каждом файле статистики, чтобы была возможность задним числом ловить за руку.
Введём понятие "средней статистики" – это та статистика, которой тор-пользователь доверяет. Внешне она будет являться одним из файлов статистики. В качестве методов её получения можно предложить стандартные: получить по разным интернет каналам какие-либо текущие файлы статистики, скопировать их у друзей и т.д. Если tor-diff-скрипт не выявляет аномалий в различиях между скачанными файлами статистики при их сравнении между собой, мы можем условно принять эту статистику верной и впредь в будущем ориентироваться на неё.
В тор-клиенте предлагается ввести "advanced-options against DA key compromize atack", который предлагается разделить на две секции: "диагностика" и "действия".
Advanced-options against DA key compromize atack
[здесь вставить краткое описание атаки, в том числе не забыть про ацкую машинку – тор-симулятор unknown'а]
Diagnostics
[секция отвечает только за опции включения диагностики статистики и её запись, никаких дополнительных действий в логику работы тор-клиента она привносить не должна]
Опция указывает на то, сохранять ли выкачиваемую тор-клиентом статистику или нет (по молчанию – нет). Значение булево. Если не указано куда сохранять [смотри след. опцию] по умолчанию создастся каталог ~/.tor/advanced-stats и каждая скачанная статистика будет помещаться в новый файл в указанном каталоге. Имя файла – время в формате годд.мес.число.часы.минуты.сек.милисек, например два разных файла будут именоваться как 20080231153012456 и 20080231154534678.
SaveAdvancedStats yes
Опция указывает на то, в какой каталог сохранять файлы статистики (по умолчанию отключена). Если опция не указана – сохранять в ~/.tor/advanced-stats.
PathToAdStatsFolder ~/.tor/advanced-stats
Опция показывает какой файл принимать за среднюю статистику (по умолчанию выключена).
FileOfTrustedStat ~/.tor/advanced-stats/trusted_stat
Выводить диагностику в output. При включении опции в логах тора, которые пишутся на output, начиная с уровня verbosity равной notice и более, писать вывод срикпта tor-diff для каждого вновь скачанного файла статистики, сравнивая его с средней статистикой. Формат вывода будет описан ниже. Значение опции булево, по умолчанию – нет. Включение опции имеет действие только если предыдущая опция (FileOfTrustedStat) корректно задана.
DisplayStatsOnOutput yes
Actions
[секция отвечает за опции, заставляющие клиент реагировать тем или иным образом на диагностику, которая записывается опциями выше, то есть предпринимать действия по остановке работы тор-клиента]
Здесь указанные опции дают эффект лишь при включении FileOfTrustedStat.
Максимально допустимое число ключей нод (в процентах), которые уже имеются в файле средней статистики и которые могут измениться согласно только что принятой статистикe (возможные значения: от 0 до 100). При превышении этого числа клиент завершит работу (за диагностику, которая пишется в output отвечает опция DisplayStatsOnOutput). По умолчанию отключена.
MaxKeyToChange 30
Максимальный допустимый процент новых нод, предъявленных скачиваемой статистикой, которые не указаны в файле средней статистики. При превышении числа клиент завершит работу. Процент считается по отношению ко всему числу нод, которые указаны в файле средней статистики. По умолчанию опция отключена.
MaxNodesToBeNew 30
То же самое что и предыдущая опция, но для процента умерших нод – ушедших в оффлайн. По умолчанию опция отключена.
MaxNodesToDie 30
[наверное, каждая статистика содержит список нод, которые онлайн в текущий момент, и их ключи, я псиал с этим расчётом]
Последнее, с чем осталось определиться, это с форматом вывода tor-diff. Предлагается вот что (это будет выводом в output если опция DisplayStatsOnOutput включена, а также диагностикой при ручном выполнении сравнения когда пользователь будет запускать скрипт в виде Мы здесь сравниаем статистику stat_file с "опорной" статистикой trasted_stat, в качестве которой в общем случае может выступать любой файл статистики):
1. stat_file: DA которым был после запрос о статисике: список
2. stat_file: DA которые положительно ответили: список
3. stat_file: DA которые подписали статистику не верно либо от них не удалось получить ответ: список
[эти 3 опции хранятся как история происхождения каждой статистики в её файле статистики. Далее идут те же опции по своему смыслу что и в секции Actions]
4. Ноды, ключи которых в stat_file и в trasted_stat разные (детекция смены ключа): список, процент числа.
5. Ноды, которые появились в stat_file но которых не было в trasted_stat (детекиця введения новых нод): список, процент числа.
6. Ноды, которыx нет в stat_file и которые есть в trasted_stat (детекция искуственного вывода в оффлайн нод): список, процент числа.
[под списком понимаются имена нод в тор-сети или их IP]
Естественно, надо будет приудмать более разумные имена опций, поправить диагностику с учётом критики и т.д. Здесь я написал вывод для tor-diff когда применяем для двух файлов руками, и что-то похожее должно писаться при соответствующих условиях в output.
P. S.: играясь с этими опциями можно настроить клиент под свой уровень "защиты". Если заподозрено неладное, у вас есть файл статистики, ключи DA которым она подписана, врремя и т.д. Если несколько озабоченных параноиков будут сохранять всю статистику в своих файлах, они могут обмениваться между собой файлами с аномальной активностью. В принципе, сам факт что DA вам предъявит список левых нод, которых не было никогда в сети будет засечён, по крайней мере его можно будет выслать разработчикам тор для анализа. Чтобы защититься самому можно выставить указанные опции из Actions в нужные значения. Правильные значения можно получить после изучения статистики, и анализа того как она меняется со временем. Когда средние значения отклонений для опций будут ясны (те, которые почти никогда не превышаются), их можно по умолчанию включить уже для всех.
Как говорят на лоре, "всё, пинайте" :)
Так это предложение делать раз в сутки. Т.е. предлагается, что должен будет для отчётности. И список всех ключей за сутки. А выше написано, что отдаёт целый список как сейчас есть.
Хотя в самом упрощённом варианте, пользователи действительно как говорит Sattva, могут просто обмениваться данными, извлечённых из своих кэшей и вести аудит без доп. требований к DA.
Но если у spinore есть ещё более простое решение, то было бы ещё
интереснее.
P. S.: стоит добавить, что местами логика чуть слетела. Сначала я думал что скачиваемая статистика содержить ключи всех имеющихся тор-нод в сети, а также отдельное указание к каждой ноде её статуса. Потом я решил что она содержит только список онлайн-нод с их ключами. Это всё от незнания формата и спецификаций :) В иоге опции были написаны под случай логики, когда при каждой скачке статистики клиент банально получает онлайн-список нод и их ключи, и ничего более [ни о каких других нодах скачанная статистика не говорит, а частности о том кто ушёл в оффлайн – если только по сравнению с предыдущим файлов статистики это можно продетектить]. В общем, если итоговая логика сильно несоответствует спецификации, то предложенные опции надо немного пофиксить, возможно, на другие.
Что касается PGP-сети доверия и прочих инструментов – это вопрос обсуждения. Пока мой вариант самый лёгкий – ничего не надо менять в протоколе, – только диагностиику самого клиента. Со временем можно будет видимо ввести и какие-то более драконовские меры, чем я предложил, только надо сначала будет понять: какова атака, от которой мной предложенное не защищает, новые меры защитят. Моё имхо, хорошо если протолкнуть хотя бы такой, облегчённый формат, для начала :) А то Роджер испугается и скажет что "атака малореальна", "не есть основная угроза" и прочее. В моём понимании, больше стоит бояться атаки на корреляцию трафика. Единственное, чем лучше атака с ацкой машинкой – она позволяет детерминистским образом деанонимизировать полностью (а не вероятностно как в кореляции трафика), и читать надёжно весь транслируемый в тор от конкретного лица трафик.
ЫЫЫ, фактически я сделал то, что SATtva сказал изначально, просто облекши в техническую форму :))
Да, забыл добавить важное: по прошествии какого-то времени (месяца, недели?) пользователь меняет свой файл "средней статистики" на новый. Он берёт самую свежую статистику, на которую ему указывает клиент, сравнивает её со статистиками своих знакомых/соседей/собутыльников, и возводит в ранг "средней", прописывая к ней путь в конфиге. Таким образом, вкратце схема защиты такова:
Все стадртуют с доверяемого среднего, накладывая ограничения на эволюцию статистики. Время от времени средняя статистика между пользователями синхронизируется (вручную), и обновляется.
А вот тут бага. Дело в том, что для того чтобы гарантировать что у тор-клиента есть все ключи тор-нод, которые подписал DA за сутки, ему надо сутки держать запущенным клиент, как минимум. Иначе DA сможет сказать, что те ноды, ключи которых он подписал, были в точности в то время онлайн, когда все тор-вочеры сидели незаконнекченными к тору. это если тор-вочеры – тор-клиенты (для тор-нод это не так критично, как аргумент). Идея в том что объединение некоторого числа тор-вочеров даст строго обоснованную претензию к DA лишь в случае если те постоянно online.
Как я уже высказался, лучше для начала воздержаться от беспокойства владельцев тор-нод – им итак достаётся проблем.
Кстати, очень действенное сравнение. Поддерживаю написать об этом в письме в качестве красивой аллегории.
В целом набор опций выглядит хорошо.
Только по моему у нас у всех не до конца ясное представление о работе сети.
Всё что подписано DA лежит в /var/lib/tor/cached-status
Каждый список – от своего DA, можно узнать каким DA подписан ключ.
Там есть отпечаток каждого ключа и время. Принуждение DA к аудиту, как заметил SATtva не нужно.
Но это пока в версии 2. В версии 3 не так? И подпись какого-то хэша в начале списка относится
к последующей части файла? Или он не подписан и предъявить его в качестве доказательства нельзя?
Дальше, по этим отпечаткам ключей скачиваются сами ключи по мере возможности и складируются
в /var/lib/tor/cached-routers и /var/lib/tor/cached-routers.new. По методу разностей (диффа), но не побайтово, а по секциям,
как я понимаю.
Выяснить что в списке от DA есть ключ от несуществующего узла нереально: кто-то может включить узел ненадолго и тут же
вырубить. Кстати можно даже вызвать ложное срабатывание, если запускать и отрубать после авторегистрации в DA много tor серверов умышленно.
Единственное, что можно это после срабатывания выделять подозрительные ключи и переписываться с кем-то или связываться по
иному защищённому каналу и выявлять левые ключи.
Сомнение Роджера было не только в том, какие опции нужны для регистрации подозрительного,
но и в том, что делать пользователю, если сработал детектор на скачок статистики, чтобы кто-то параноидальный не
включил этих опций, а потом не морочил всем голову в рассылке, создавая панику,
не выяснив по-возможности предварительно сам в чём дело.
Ну не будет такого никогда. Какие-то шутники собирались ставить серваки с тором незаметно на флэшках в какой-то университетской библиотеке.
Кто-то ещё что-то придумает.
Узлы теперь не регистрируют вручную. Каждый может стать узлом. Через время не больше 3 часов кажется он попадает в статистику DA.
По какой-то причине куча серваков исчезает (сбой), затем снова запускается, некоторые держат серваки на CDR генеря ключ после ребута в памяти.
Т.е. регистрация такого рода атаки очень опциональна, это не автоматическое детектирование, а скорее действительно аудит для особо желающих.
P. S. Кстати, китайцы в рассылке пару раз просили выслать статистику по
почте – у них были заблокированы только DA, но не вся сеть и после
подкладывания чужой статистики они могли работать.
Не совсем. Я исхожу из того, что группа скомпрометированных DA не будут настолько наглыми, что подпишут кучу левых ключей для всех.
Левые ключи будут поставляться лишь отдельным изолированным клиентам. А не по всему миру, не во всех странах и не во всей сети.
Кто-то, устроивший сговор с 50% DA не захочет это так публично выставлять, чтобы обнаружить было легче.
Пусть DA в списке подписывает время действия полученных ключей.
Важно, есть ли там сама подпись от DA, или её клиент проверяет и уничтожает?
Были торокопатели класса лыжы_асфальт и soot. Они бы могли точно сказать что к чему.
Видимо, cashed-routers и есть пример собственно файла статистики...
Что касается этой атаки и беспокойства самого Роджера:
- Опция для параноиков. Кто хочет – включает лишь диагностику, никто никого не заставляет включать Actions.
- Если будет предпринята массовая атака по подключению большого числа тор-нод на короткое время, то не вижу ничего неадекватного в том что тор-клиенты на это среагируют и известят пользователя. Далее уже тор-team будет думать что с этим делать, я пока ничего предложить не могу.
На следует исходить из очень простого тезиса: от заметания мусора под ковёр сам мусор никуда не исчезает, так что опциональную (по желанию) диагностику включить надо – она делает лишь лучше. Далее: есть группа параноиков, она хочет хоть какую-то защиту – для них Actions. Атаку с массовым подсоединением новых нод к сети можно провести и сейчас, но это вряд ли кто обнаружит и никто толком ничего не сможет предпринять (банально нет инструментов) – так лучше что ли? Не стоит сразу хвататься за звёзды, давайте для начала протолкнём Diagnostics и Actions для параноиков и для диагностики возможных атак тор. Далее, может быть сам Роджер выскажет идеи что можно сделать против тех ддос атак.Кстати, что приходит в голову против такой атаки: можно установить квоту – число возможных подключений тор-нод к тор сети за единицу времени исходя из реальной статистики (чтобы очередь не накапливалась и атака не проканывала). – почему бы и нет? Сейчас все сайты устанавливают счётчики на скачку файла например – это чем-то напоминает то.
Всё это, как я понимаю, можно делать сторонним скриптом, зачем беспокоить разработчиков? На чём нынче принято писать межплатформенные скрипты?
Секцию Diagnostics, возможно, и можно (пока ещё не ясно до конца).
Секцию Actions нельзя написать (скрипт может реагировтаь лишь постфактум, а это может уже оказаться поздно).
Там предлагается скрипт, но он кроме того должн быть ещё и интегрирован в функционал tor'а (tor его должен запускать). Кстати, если узлов – сотни, не факт что это будет делаться достаточно быстро.
Кроме того, действия скрипта в стиле "перехватить статистику, успев создать её бэкап в другом каталоге" я считаю извращением.
Это всё-таки базовые вещи, потмоу сам tor тоже надо допиливать.
Другое дело, что можно самим попатчить тор-клиент, так как протокол совершенно не меняется. НО... я не программист.
Да, именно это для меня не ясно.
Именно soot говорил в этом треде, что в v.3 клиент получает уже согласованный между нодами список,
если я правильно понял. У меня клиента с поддержкой v.3 пока нет. Если это так, то это плохо
для аудита. Они там по тихому между собой голосуют, что затрудняет обнаружение
атаки :-)
Смотря что называть статистикой.
Раньше всё было в одном файле, теперь это просто разделили, чтобы разгрузить DA и равномернее
распределить нагрузку между зеркалами.
отпечатки ключей в cached-status, а сами ключи и подробности об узлах в большом файле cached-routers.
Причём файл cached-routers скачивается и обновляется постепенно. Так что анализировать его труднее.
И обмениваться им нежелательно в отличие от cached-status, который у всех примерно одинаковый
(различия по времени некритичны и не указывают ключей каких узлов не хватало клиенту, каких он
не использовал в цепочках на какой-то определённый момент времени).
Если в v.3 действительно клиенту поставляется готовый cached-status с отпечатками, уже подписанный всеми DA,
то это ещё больше разгружает и DA и зеркала на узлах, но для нашего предложения это хуже :-(
Поэтому и хорошо хотя бы раз в сутки с каждого DA требовать подробный отчёт по каждому подписанному ключу
тор-узла с указанием времени появления и исчезновения его из статистики.
В cashed-routers есть для каждого узла opt write-history и opt right history.
Про это и про многое другое хорошо бы почитать в спецификациях, прежде чем нас опять вежливо отправят это делать.
Если будет время, предлагаю примерно в течении следующей недели выучить почти наизусть спецификации
и v.1, и v.2 и v.3, чтобы было можно обсуждать более предметно.
Это они и так мониторят без помощи клиентов, собирая и анализируя статистику с DA.
Им возможно бы интересно только знать что у отдельных клиентов картина tor-сети отличается от общей.
Может это уже есть? DA регистрируют узлы почему то через неодинаковые промежутки времени, может есть и очереди и квоты.
Надо спецификации читать, учитывая ещё что они местами и устаревшие и неполные.
Нужны подробности, в один-два абзаца о том как это всё происходит, протокол обновления статистики. Без этого говорить о конкретике невозможно.
А там вообще есть какие-нить подписи кого-нибудь из DA?
Блин, как всё не просто... А по какому протоколу сейчас работает большинство? Я не уверен что это спецификации, подробные и внятные, на каждый протокол есть (в терминах ИДЕИ а не в терминах программистских выпендрёжов). Мне например пох как называется та или иная функция, я бы хотел видеть, меня интересует сама научная идея организации доставки статистики, и мне кажется что прийдётся изучать всю рутину чтобы это понять, но на рутину у меня к сожалению уже нет времени (pgpru.com съедает много времени, да...).
Можно перевести вопрос в плоскость "есть пример атаки" на то, то и то – сделайте что-нибудь. Мне не нравится сама идея, что они полагаются на то, что ключи DA никем не будут похищены и DA всегда можно доверять. Это сродни доверию что владелец сервиса-анонимайзера не сдаст ваши логи когда его прижмут. В общем, есть вариант объяснить вкратце идею решения в рассылке, а уже как её конкретно согласовать с
протоколомроем протоколов – оставить Роджеру. Сразу честно скажу что спецификации читать не буду, я итак оборзел – нифига не делаю по учёбе. Если кто-то поймёт логику работы со статистикой и кратко, внятно её изложит – можно будет ещё пообсуждать, иначе, видимо, ограничимся "вбиванием кола" что "проблема существует".Стабильные на втором. Третий только в альфа-версиях и он в стадии разработки.
Там изложено именно так как вы хотите. На уровне идеи.
Я Вас понимаю. Предлагаю сделать перерыв примерно на неделю, если ничего революционного в голову не прийдёт.
Надеюсь у меня будет свободное время за неделю подробно осмыслить все спецификации. Там совместными усилиями двинемся дальше.
Они думаю лучше нас понимают чего можно придумать, если иметь ключи от DA. Того что было изложено в новогоднем письме было достаточно.
ну мы и так уже много чего придумали.
тезисно кратко пока:
Так или иначе всё что нужно для защиты от атаки это определение того, что клиент видит искажённую картину tor-сети что выявляется или автономно или относительно к другим источникам.
Может разработчики могут предложить совершенно иной способ решения.
Ясно. Хорошо.
Собственно, чтение спецификаций не дало ничего интересного.
Статистика состоит как и говорилось выше из двух частей: статуса сети /var/lib/tor/cached-status и дескрипторов узлов (/var/lib/tor/cached-routers и /var/lib/tor/cached-routers.new).
Статус сети – это то что подписывают DA, там в основном отпечатки ключей узлов и очень краткое их обозначение. В версии 2 каждый отдаёт список порознь, пользователь скачивает все списки и сам по ним голосует.
В версии 3 готовый консенсус с подписанным всеми DA статусом голосования (консенсусом). В консенсусе есть подписи всех согласных нод.
V3 не только разгружает сеть, но и даёт всем пользователям одинаковые данные без рассинхронизации между DA (рассинхронизация нежелательна из-за возможных атак разделения). В статусе содержатся только отпечатки и краткое описание узлов.
Дескрипторы – это уже подробное описание узлов, их ключи, политики и т.д.
Они могут скачиваться по частям.
Если что то анализировать, так это файл статуса сети.
Собственно все опции укладываются просто в разность уникальных ключей и их количества в предыдущем и текущем статусе.
Вот что на основе ваших опций, spinore, придумалось:
Если имеется N_k ключей нод и N_k+1 за интервал обновления, можно сравнивать увеличение/уменьшение их количества:
C=N_k+1/(N_k) – изменение общего кол-ва ключей (на самом деле это показывает число нод)
I – число совпадающих ключей между списками N_k+1 и N_k (индекс совпадающих ключей)
Его максимальное значение не может быть больше размера меньшего из списков:
max I = min (N_k+1, N_k)
Чем ближе C к единице, а I к своему максимуму (т.е. меньшему значению между N_k и N_k+1), тем стабильнее tor-сеть.
Пусть D = I/I_max – индекс изменения ключей. Тогда и D будет стремиться к единице при стабильной сети.
D <=1 (всегда); C<1 при уменьшении числа узлов, C>1 при увеличении.
Увеличение числа узлов опаснее. Также как и уменьшение числа совпадающих ключей.
Тогда можно подсчитать стабильность сети в самом примитивном виде как некое S=C/D
Чем больше единицы значение S, тем опаснее. Ну и чтобы D не равно было нулю, а то вообще хана :-)
Только как отслеживать данные между интервалами? Например часть нод пропала из статистики, а затем
появилась снова, но не с новыми ключами, а с теми которые и были? (Некоторые тор-ноды работают по крону:
только по ночам или по выходным).
Другие подозрительные параметры, о которых мы писали в письме не вытащить из статистики: это верная
статистика (статус сети), но неверные ключи, заблокированные ноды и т.д. Само по себе это об атаке
не свидетельствует, но в сочетании с повышением индекса S усиливает подозрение.
Таким статистическим анализом можно выявить подозрительные ключи (чем их больше и чем быстрее они вброшены,
тем это будет эффективнее).
Затем их можно прдъявлять как доказательство, сравнивая с данными по индексу S за определённое время и с ключами у других пользователей.
К индексу S (а также к C, D и всему остальному) можно прикрутить построение графиков, вычисление их собственной статистики "хи-квадрат" и прочее.
Но всё это трудно автоматизировать и похоже требует вынесения в отдельную утилиту.
Возможно это следует внести в проект torflow[link10]
Если на нём обкатают, тогда только можно думать о какой-то автоматизации и включение в сам tor. А так маловероятно.
Такую утилиту не слишком сложно написать на Питоне, но себя в качестве добровольца предлагать боюсь — занят с openSpace.
Да, нам хотя бы очередное письмо осилить :-)
Кстати, вот что неправильно:
Пусть было 100 узлов, стало 50 и из них половина поменяла свои ключи:
тогда C=50/100=0.5
D = 25 / 50 = 0.5
S=0.5/0.5=1, что совсем нехорошо.
Надо: если C=>1, то S=C/D, если C<1, то S=C*D
Т.е. для S и увеличение больше 1 и стремление к нулю будет свидетельствовать о нестабильности.
А D считать как D = (I+1)/(I_max+1), чтобы никогда не равно было нулю.
Ну что, вот такой черновик пока, вроде кратко и основные идеи есть. Больше опасаюсь за грамматику :-)
// Multiple Directory Authorities' keys compromise: a partial
solution for Tor clients protection. v 1.01
Thanks Roger. We continue a discussion on our site and our minds is overheat :-)
never going to get feedback that the code is still working.
This issue can cause a crisis of trust. In the case of this attack 3+1 corrupted node + 1 controlled ISP is no more better than single anonymizer who owns users log. It's will not be "rare" when the adversary is law enforcement agency, or another power adversary,
who can owns DA keys and install virtual network tor simulator on an ISP. And this will be easier than pretend to be "global adversary".
Worse, this "hypothetical" attack will be deterministic, not probabilistic.
We guess about protection of this attack, like a thunderbolt protection. You can install a lightning rod on a house and you avoid direct lightning strike. Lightning prepend an unprotected area. But if you don't install lightning protection it's very rare case to your house to
be striking too. You can think, that lightning rod is unnececary. But if the direct lightning strike will be happen it will be devastating.
yes, we agree. The core problem is: we have not a clean criteria of attack and we have not a simple scenario to defense.
We assume, that adversary start this attack against single or very small part of isolated tor users, to avoid disclose he's power.
Attack based on creation distorted view of the tor network for user (virtual network simulation and rerouting intercepted and decrypted traffic to real tor network again).
User can detect this attack in two ways: autonomous (collecting statistics anomaly) and relative (by comparition network status with
another trusted users exchanging suspicious network statuses on the secure channels: openPGP mail, private contact). If concerned users can isolates suspicious node keys, signed by DA with help of more users, they can publishes that keys or hashes to "peer review" as demonstration of evidence.
Concerned users will be play a role of "tor watchers".
We propose a very simple (and may be naive) approach to first step (autonomous detection).
If user have N_k nodes keys from network status and N_(k+1) to next network status, then
C=N_k+1/(N_k) – changes of number of keys (and nodes itself).
Let I – index of similar keys between lists of N_k and N_(k+1)
max I = min (N_k+1, N_k)
Let D= I/I_max – changes of keys itself. We replace that to D=(I+1)/(I_max+1) to avoid any zero values.
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 TOR network more stable. If S changes singificant, then we have network instability.
S can be easy calculated from tor status file. But we can't easy count broken, or blocked connection to nodes from status list (it's may be a sign of attack too).
Concerned users ("tor watchers") can makes a graphs of suspicious changes and publish it, or exchange and analyze data using web of trust or another ways of communication to DA audition.
We guess, the problem need to have a lot of exploration and experiments to get an acceptable solution.
"OpenPGP-in-Russia Team"
Проверяйте, особое внимание обратите на формулы, надеюсь ничего там не попутал (Nk+1 я заменил на Nk-1: всё-таки будущего статуса у пользователя никак не может быть, а предыдущий может храниться).
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 nodes + 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 hit. Lightning hitting 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 unnececary. 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 publishes 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.
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 of number of keys (and nodes themselves).
Let I be the index of keys found in both lists of N_k and N_k-1
max I = min (N_k, N_k-1)
Let D=I/I_max -– changes of keys themselves. We replace this with
D=(I+1)/(I_max+1) to avoid zero values.
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 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).
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"
Да, спасибо, что указали на формулы, так корректнее.
Грамматику привели к приемлимому виду, уже не стыдно отправлять, но как-то интонационное восприятие незначительно поменялось. Зачем заменили словосочетание "Lightning strike" на какой-то вялый "hit"? Именно "Lightning strike" близко к типично американской идиоме и наиболее сильно показывает на внезапную грозящую опасность. См. сайт переживших удар молнии http://www.lightning-strike.org.
Мы конечно не художественный рассказ пишем, но strike и кое-что другое мне нравилось больше.
А вот указание на политически мотивированного атакующего очень удачно, проблема именно политическая.
C=N_k/N_k-1 is the change of number of keys
Имеется ввиду количества, может уместнее quantities или оставить номеров?
numbers?
Let I be the index of keys founded, найденных может быть так или получится ерунда, типа основанных фондом?
Let D=I/I_max -– changes of keys themselves (differences)-это я просто добавил в скобках.
could print diagrams – я вообще-то графики предпочитаю, с точным временем, их накладывать и сравнивать легче, но диаграммы это может быть более красочно и увлекательно для пользователей :-).
Подождём, что spinore скажет.
с ЭБУ ОБРЙМУП, ФБЛ ЮФП ОЙЮЈ ЛПОЛТЕФОПЗП УЛБЪБФШ ОЕ НПЗХ. оП ЪЧХЮЙФ ПЮЕОШ ХНОП. пЮЕОШ ФТХДОП РПРБДБФШ РП ЛМБЧЙЫБН. ъБЧФТБ ЧУЈ РТПЮЙФБА Й РПДХНБА. уРБУЙВБ.
Я щас напилсо, так что ничё конкретного сказать не могу. Но звучит очень умно. Очень трудно попадать по клавишам. Завтра всё прочитаю и подумаю. Спасиба.
Да, заметно :-)
Всвязи с этим можем добавить к фразе:
Нечто вроде:
And one of us in a hangover condition :-)
in the case of this attack 3+1 corrupted authorities
а не nodes
Моя ошибка.
Написать утилиту которая реализует указанный алгоритм по оффлайновой статистикие – несложно. Предлагаю сначала получить рабочий прототип и проверить формулы на практике, а потом писать в or-dev, чтобы не зашумлять свой же сигнал. Тем более что отношение Роджера к этой идее довольно пассивоное, а дел у него и так выше крыши.
Окей, вернём обратно:
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.
Тогда лучше так:
C=N_k/N_k-1 is the change in the number of keys
Правильно всё-таки found для прошедшего времени. Типа "search process has found 7 docs".
Diagram тоже можно перевести как график, а с graph возникает двусмысленность: график или граф?
Я не удивлюсь, если он ответит именно так, слово в слово :-)
Пусть это ответит лично он, тогда быстрее желающие найдутся, мы пока лишь даём идею для примера, он же интересовался нашим мнением в более конкретном виде.
2 SATtva: со всеми правками пока согласен
И об этом надо написать тоже! И обяснить ему причину, по которой всё-таки он получил это письмо:
Это письмо в рассылку для всех разработчиков и возможно заинтересовавшихся проблемой. То что S легко посчитать из файла мы написали и это и так ясно.
То что это возможно слишком наивно и недостаточно, мы упомянули.
Пусть он или ещё кто-то из разрабов оценит пока хоть это. Или скажем всем: "флаг вам в руки, считайте". Думаю всех изложенных причин и объяснений достаточно пока.
По-моему не читая развёрнутое русское описание понять английское – сложно.
max I = min (...) – это что – уравнение? Если max то по какому множеству? Что такое I_max?
Когда мы считаем число "неизменившихся" ключей – берётся просто размер пересечения множеств identity ключей?
Вообще для каждого значения надо описать его смысловую нагрузку словами, чтобы было понятно откуда что берётся.
Последнее условие какое-то странное, а точнее неинвариантно к течению времени :)
пусть N2 > N1
C := N2/N1 > 1
S := C/D = N2/(N1*D)
теперь пусть время течёт назад: N2' = N1 и N1' = N2
C := N2'/N1' = N1/N2 < 1
S := C*D = N1*D/N2
D очевидно константа в обоих случаях и коэф. S получается связан обратной зависимостью. Некрасиво. Искусственно.
Логично ожидать что S будет грубо говоря мерой на пространстве состояний сети и S(статус1, статус2)
это расстояние (количество изменений) между двумя точками этого пространства.
Можно рассужать так :
M1, M2 множества дескрипторов которые мы сравниваем
M = M1 AND M2 – пересечение (в качестве ключа множеств – identity key) – т.е. все неизменившиеся дескрипторы.
Очевидно M меньше M1 и меньше M2
Теперь просто сравниваем размер общей части с каждым из множеств и выбираем худший показатель
Z(M1, M2) = min( |M|/|M1| , |M|/|M2| )
Z принадлежит [0..1], 1 это полное совпадение множеств (лучший вариант), 0 – абсолютно разные множества.
Z – мера?..
Свойства меры (для любых x y z) :
неотрицательность: r(x, y) >= 0 и r(x, x) = 0
коммутативность: r(x, y) = r(y, x)
треугольник: r(x, y) + r(y, z) >= r(x, z)
простым линейным преобразованием – возьмём R = K*(1-Z), где K это какая-то большая константа -
максимально расстояние.
Очевидно первые два свойства выполняются.
Третье сходу доказать не получилось..
А время строго не определено. Да, за уши притянутая, чтобы было просто видно отклонение. Чтобы выделить ситуацию с уменьшением числа нод. Хотя главное значение имеет изменение только числа ключей.
Можно конечно всё строго самим доказать, утилиты написать, работу в /LaTeX оформить с прилагающимися графиками. Но думаю энтузиазым делать это ради очередной коллективной анонимки иссякнет быстро.
При том, что авторы сделали бы это всё равно лучше. Наше дело пока – краткое письмо с идеей, чтобы их и возможно кого-либо ещё заинтересовать.
ygrek, если можете довести кратко до ума, так чтобы это можно было перевести и отправить в рассылку, тогда хорошо.
Да так во многом лучше. Мне тоже хотелось, чтобы величина была нормализованной.
Только как здесь различать когда число нод уменьшилось (и кол-во ключей уменьшилось допустим ровно на столько же) и увеличилось (пусть кол-во ключей увеличилось ровно на столько же – но это потенциально опасней).
Причина всех бед – преждевременныя конкретизация. Оставьте формулы на потом, просто пишите словами основные идеи.
Another possible approach is a measure of descriptors as multiplies intersection M = M1 AND M2 and explore Z(M1, M2) = min( |M|/|M1| , |M|/|M2| ) as normalized value in the space of [0..1]
0 – most unstable; 1 – full stable. And compute R = K*(1-Z), when K is maximum distance in space [x, y, z].
и пока на этом может пока остановимся? Просто хочется уже письмо отправить.
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 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].
На самом деле, смысл формализации далеко не очевиден из текста. Может и правда "своими словами"?
По-моему нет смысла приводить формулы "от фонаря" – их надо проверить на практике или хотя бы обосновать подробно теоретически. Можно в этом письме не приводить конкретный алгоритм, а описать лищь общий план действий, а в это время проверять разные подходы.
We plan to develop a 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.
numerical => step-by-step?
я имел ввиду численный. лучше numerical criteria
Я привёл свой вариант, как пример того, что посчитать можно для начала относительно просто. Инвариантность по времени и нормализация не требовалась, т.к. не планировалось сравнивать состояния из разных источников в один промежуток времени, а только разность состояний между двумя измерения с учётом не только изменения, а и уменьшения/увеличения.
S<1 это один тип нестабильности (менее вероятный в качестве признака атаки и не такой опасный), S>1 – другой .
предлагаю отправить оба варианта как примеры, пусть их даже не поймут без подробного объяснения, но поймут, что можно в принципе считать.
Идеи мы привели, черновик тоже.
Может не стоит пока давать обещаний? Отправить просто образец. А дальше всё может зависить не только от наших действий, но и от действий разработчиков. Если у нас что-то выйдет – хорошо, а может у нас на сайте этим будут заниматься три с половиной человека и энтузиазм спадёт, вы уверены, что там не вылезет куча тонкостей на полгода работы? Нужно еще тогда уж и модельную атаку проводить. Письмо отправлять надо.
другое дело может быть этим всё-таки заинтересуются и займутся сами разработчики, плюс на torproject.org повесят в списке задач (потенциально ведь возможно). Может какому студенту вместе с руководителем группы – хорошая тема для диплома. По крайней мере нам ничто не мешает заниматься дальше изысканиями, просто может кто-то сделает это быстрее.
// Multiple Directory Authorities' keys compromise: a partial
solution for Tor clients protection. v 1.03
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 publishes 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 (for example only, correctnes in real work isn't tested).
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 changes 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 replace this with D=(I+1)/(I_max+1) to avoid zero values.
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).
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].
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"
unknown:
Других замечаний не имею. Если коллеги не против, можно отправлять.
не против
На досуге написал тулзу для парсинга network-status'а версии 2. Пока только считает коэфициент совпадения двух status'ов по "моей" формуле. Можно будет добавить другие формулы, статистику и использовать для анализа.
Исходники[link11]. Для компиляции требуется ocaml[link12] и extlib[link13]. В Makefile исправить путь к extlib (недоработка, надо будет подключить ocamlfind). Должно работать и на Windows и на Linux. Запускать torstat -diff file1 file2
Вы бы не могли подсказать как понимать такой ворнинг и следует ли о чём-нить беспокоиться? Весь остальной вывод в норме.
Заметим(!), что я не зря ввёл понятие средней статистики, обновлять которую нужно лишь время от времени и мануально. Проверка ключей на шагах k и k+1 легко обходится противником – позволяет монотонно дестроить сеть. Скорость дестроя будет ограничена лишь максимальным допустимым отклонением для I и D за один шаг (интервал времени).
Поскольку ключи сравниваются каждый раз только с предыдущим шагом, позвольте мне привести пример взлома: пусть у нас на шаге k и k+1 одно и то же число совпадающих ключей, например 10. Тогда D = I/I_max = 1 (вообще никаких подозрений). Пусть на шаге k и k+1 мы имеем одно и то же общее число ключей, пусть 100. Пусть у нас 10 ключей, как уже оговорено, остаются теми же, а 90 остальных меняются от шага k к шагу k+1. при этом индекс C = 1 (также никаких подозрений). Однако, при этом клиенту полменили 90% ключей всех нод. Или я что-то попутал?
C меняется от 0 до inf (в идеале равно 1), D от нуля до 1 (в идеале равно 1). Так?
Пусть C мало (куча нjд одновременно ушла в оффлайн по ср. с предыдущим шагом), и D мало (совпадающих ключей мало) – тогда S орядка 1, а атака сканала. Или я не прав?
P. S.: unknown, я же протрезвею – я выведу вас на чистую воду! Или вы думали что вот так вот просто всё с рук сойдёт?
Да, проглючило меня с определениями. Атака не сработает.
О! Предвосхитили :) Зря объяснял.
Ужас! Так, срочно учим математику. У нас есть 2 случайных величины. Для простоты забъём на то, зависимы они или нет. Нам нужен случай, когда обе из них отклоняются не сильно от некоего среднего. Вводим стандартное отклонение и используем МНК.
Поскольку
Поучаем: S(pinore) = (C – 1)^^2 + (D – 1)^^2.
В идеале таким образом определённое S будет стремиться к нулю в случае стабильной сети. И чем оно больше, тем нестабильнее сеть.
Вики меня не правильно поняло, имелось в виду ^ а не ^^ (я думал оно так их напишет сверху, как и подобает степеням тому быть).
Вроде только я пил, у вас-то почему мнения перегреты?
Всё-таки фиксим формулы с учётом того, что должны равняться не на предыдущий шаг а не некую предполагаемую среднюю статистику. Подробнее я описал раньше что это такое и зачем нужно.
И чё, привязываться к изменениям файлов статистики? Как мониторить-та? Или как дибилы-программеры мониторить "не появилось ли что нового" обращаясь к файлу каждые n секунд?
Сразу скажу что я дилетант в прогерстве, но мои представления таковы что без интеграции с самим клиентом по уму это не реализовать.
С посылом согласен.
Вообще, ygrek в рамках рассматриваемой модели сказал всё важное и по-существу – я согласен (сразу видно, что человек с образованием). Только модель осталось пофиксить, ибо сранивнение двух соседних шагов по времени ничего не даст, нужно сравнивать каждый шаг(t=t1) с одной и той же средней статистикой при t=0 (с шагом(t=0)). Я в своё время об этом пол дня думал, тоже не сразу догадался что срагивать соседние шаги коряво.
В общем, не буду вдаваться в подробности, но можно показать, что замечание ygrek'а по этому поводу имеет смысл (ломает думать над контрпримером, когда ваше определение съежит, а вот его определение будет физичным).
Коллеги против. Предлагаю убирать свои сравнения статистики между двумя соседними моментами времени и мерить отклонение от некоего, приятого за среднего. Среднее апгрейдить лишь равняясь на дианмику статистики у других пользователей. Иначе между шагами k и k+1 далем выпрыскивание новых нод, какое бы не превысило срабатывание защиты программы, потмо такое же впрыскимвание делаем между шагами k+1 и k+2, и всё... "схема пошла в разнос".
С формулами пока сильно не мудрите – берите базовые отклонения:
inStability = (C? 1)^2 + (D? 1)^2, где C и D на k-том шаге по времени считаются не относительно шага k-1 а относительно шага k=1 (трастед-статистика, она же средняя).
И так, и так. Помните, что всё правильное всегда выглядит просто и описывается простыми формулами. Если начинается перегруз обозначений, значит далеки от истины (формулы не те).
Имхо, здесь максимум 3-4 формулы надо-то...
А формулы должны быть такими, чтобы они допускали такое сравнение, как и сторонняя утилита. Только тогда можно понимать что за метрику мы определили на множестве состояний и что мы сраниваем. Ну никакой культуры! Математически мы делаем очень простую вещь. У нас есть множество статистик (файлов статистики). Мы вводим метрику (это даст "расстояние" на мат. языке) между двумя статистиками. Расстояние – это такая функция, которая принимает два аргумента (две статистики) и возвращаем нам число. Вспоминаем, что расстояние в векторном пространстве, это функция которая каждым двум векторам сопоставляет число – расстояние между ними.
P. S.: в общем, вроде уже почти все ошибки совершены, на все грабли наступили, так что теперь можно формировать итоговое. Мои мысли вкратце сводятся к тому что
- Пишем правильную формулу для S.
- Вводим измерение относительно нулевого момента времени (средней (доверяемой) статистики).
Я ушёл спать, смогу ответить ещё что-нибудь уже только вечером.Тогда надо так: x^^2^^.
s/minds/heads/ (или brains), но, на мой взгляд, это не принципиально. И если есть замечания к переводу, критикуйте, пожалуйста, последнюю версию перевода, а не первую.
Файл статистики не меняется ежесекундно. Внешней программе достаточно каждую секунду проверять время последнего изменения файла и запускать алгоритм сравнения, если файл был изменён после последней такой же проверки.
Тогда, наверное, t=tn.
Да я понимаю к чему Вы spinore и ygrek клоните, вы хотите получить красивый нормированный и симметричный критерий, который бы укладывался в "правило трёх сигм" (нам бы одной хватило для 90% вероятности) и т.д. Как будто сеть стабильна хотя бы в некотором временном интервале и есть некоторый критерий, по которому пользователи не должны сильно отклоняться.
Во-первых, я не уверен вообще может ли он существовать и будет ли он иметь смысл.
Можно ли будет доказать, что он показывает оптимальным образом все атаки?
Во-вторых, я хотел применить другой подход: пользователи сравнивают показатель для одного и того же времени. Если у них (у всех) был скачок в одно и то же время, то скорее всего никакой атаки нет (или у них всё равно нет шансов её обнаружить путём нахождения различий). Далее могут статусы сравнивать. Кстати, статусы выдаются голосованием в V3 не чаще раз в 15 минут (про исключения не знаю).
Я не говорю, что мой подход лучше (может хуже): мы на разные аспекты упор делаем. Сравнение отклонения от некоего "правильного" значения или сравнение любого отклонения, которого у пользователя не было до этого и больше упор на синхронность его измений между пользователями.
C и D зависимы, если вы хотите их просто так считать по отдельности, то не проблема. C можно считать не только как изменение количества ключей, но и IP-адресов, имён.
Просто реально, есть разные случаи:
Вероятность с частичным отравлением кэша статуса невелика – это слишком рискованно для противника. Пользователь может соединиться с реальным узлом и снова скачать нормальную статистику, если при этом он будет мониторить ситуацию, то он зафиксирует ещё более подозрительные колебания параметров. Для этого противник оставлять в статусе часть реальных узлов, но блокировать соединения с ними, что из файла статистики вообще не отследить. Это хорошо бы выводить из самой программы и тоже учитывать как некий коэффициент.
Неправильно выразился. Планировалось получить скачок между шагами, который был бы одинаков у пользователей в тот же промежуток времени.
По-моему письмо можно отправить и сейчас как есть – с описанием идеи. С чистого листа придумать "хороший" критерий мы всё равно не сможем (даже ориентируясь на математическую красоту) – нужна практическая проверка – это потребует много времени.
unknown, наверное вы правы, красивый идеальный критерий скорее всего работать не будет, т.к. мы имеем дело с неидеальным грубым реальным миром :) – но ведь интересно..
Хочется в общем посмотреть статистику сети, не обязательно с точки зрения этой атаки.
Мне тоже интересно, а статистику можно изучать, никто не мешает.
Можно наизобретать массу разных моделей и все визуализировать. Вполне возможно, что совершенно разные способы построения критериев будут работать (или не будут вообще). Вот у нас уже почти три есть. Можно было бы все три чисто навскидку сравнить.
Возможно моя идея с одним критерием действительно неосуществима и порочна изначально.
Просто заставить даже очень интересующихся пользователей смотреть больше чем на один график и сравнивать более одного параметра малореально.
Я не ставлю чёткий таймлайн (с идеальными критериями можно полгода провозиться), но хочется отправить то что есть (и так уже много).
Если что-то получится ещё, будет повод о себе напомнить и следующее письмо отправить.
Я даже не знаю что есть критерий трёх сигм, но предполагаю что речь идёт о неравенстве Чебышева и вероятность отклонений больших трёх сигм. Собственное, речь не об этом. Мы можем всего лишь заменив одни формулы на другие существенно улучшить качество оценки – так почему бы это не сделать?!
Для начала, нужно получить список всех атак. Потом уже ставить подобный вопрос. Пока что я увидел только одно существенное нарекание в треде: куча нод систематически включается только на определённое время суток и т.д. Касаемое конеретно этого обстоятельства нужно просто оценить: куча – это сколько процентов? 50? 5? Если на фоне общего числа нод это не великое колебание, то проблем нет, всё решается лишь выставлением ограничителя на S, который бы допускал такие суточные изменения, но не пропускал бы атаки.
Вот... Только теперь-то я вас понял, могу уже конструктивно повозражать по поводу подходов :) Вы, unknown, смотрите на мониторинг этой атаки как на обычное исследование скорее, а не как на нечто, что тут же должно давать конкретный технический продукт защиты. Я же смотрю на неё скорее как практик которому нужна защита от неё и как можно скорее. В нейтральном анализе смысле различия между подходами вот каковы:
Вы включаете "дебаг-уровень отладки" статистики и пишете пошаговые сравнения. Вы надеетесь, что задним числом сравнив свою статистику (куча фйлов, так как они обновляются относительно часто) в соответствующие времена со статистикой соседа выясните правду. Во-первых, минусы:
- Реакция исключительно постфактум, но никогда не до.
- Слишком много файлов и объёмов данных, которые прийдётся сравнивать.
- Будет сложно найти кучу народа, кто согласился бы писать все скачки статистики втечение длительного промежутка времени, всего лишь ради одной-единственной атаки (а атак на тор кучу можно придумать).
- Поптыка синхронизовывать статистику с сстатистикой соседа влекёт за собой трудности (чё, будем каждые 15 минут друг с другом файлами статистики перекидываться?).
Вы уж меня извините, это может быть всполедствии включено как дополнительная мера "дебаг-уровня", но с практической точки зрения она пока мало чего не даёт. Мы должны думать во-первых о других и технической стороне дела, в идеале должна быть одна конопка которая будет загараться на атаку и справшивать у пользователя "что едлать? Идти или не идти дальше?" либо будет действовать в рамках заданных для неё ограничений. "Любите юзера", что называется :) Он должен выставить 2-3 разумных числа-переметра в конфиге и забыть про эту атаку – ему нужно пользоваться тор-сетью а не изучать статистики(!).Теперь смотрим то что я предлагаю:
- Сравниаем друг с другом только среднюю статистику. Её можно сравнивать иногда, например раз в месяц (не думаю что за месяц сильно меняется число узлов в сети тор). При попытке мониторить атаку заранее нам уже не нужно каждые 15 минут обмениваться файлами статистики – достаточно раз в месяц этого сделать. А это уже куда легче технически.
- Когда происходит атака, я её могу засчеь в реальном времени и остановить программу, я её обнаруживаю до, а не после.
- Предложенная схема не сложнее вашей, но она уже технически дорабатываема до уровня конкретной реализации и будет реально давтаь разумную защиту при небольшом геморрое.
Поэтому я предлагаю начать с простого: сделаем сравнение с "трастед-средним", а уже потом будем смотреть на динамику (это что вы предлагаете).Самый концептуальный момент – в том, что равняясь на среднее всегда самому уединённо видно, есть лиатака и что происходит с сетью, а равняясь на предыдущий шаг, видно лишь малое отклонение, из которого ничего толком заключить нельзя (ибо надо смотреть уже на совокупную динамику за массу предыдущих шагов по уму, я по сути предложил лишь упрощённый вариант – сравниваемся с начальным моментм времени). Вы поймите, что атака не обязательно есть марковский процесс (на шаге k всё ништяк а на шаге k+1 противник ввёл все свои фиктивные нод или что-то подобное), проивник может сделать её немарковской, и предполагая что вы включили защиту от неё заранее, постепенно впрыскивать ноды пока не доведёт вашу итоговую статистику до до уровня нужной для атаки (а поскольку в реальном времени вам не удобвно сравниться с сосдеями каждые 15 минут, вы вообще ничего не заметите. Я уж не говорю о том, насколько легко/трудно противнику будет понять, с кем вы сравниваете статистику а с кем нет, а то он может прдделывать её для группы связянных друг с другом пользователей).
Давайте ближе к Земле и практике:
Какая из этих атак не отлавливается посредством измерения S = (C – 1)2 + (D-1)2?
Грамотное замечание, но всё начинается с деления общей задачи на часть независимых модулей. По моему мнению, указанное вами дополнение относится к дополнительной усложнённой атаке, и его слеждует рассматривать как второй шаге приближения к идеалу, а пока мы рассматриваем 1ый, и нам нужно 1ый шаг что можно сделать втолковать Роджеру.
Чего бояться, дорабатываем до нормально состояния письмо с учётом поправок и отправляем. Предложив хотя бы что-то мы упрощаем задачу разработчикам тор. В добавке укажем: "Это наше предложение, может быть вы увидите ошибки в его конструкции и придумаете что-то своё, лучшее".
Можно строго показать что почти для любой куйни достаточно одного числа для оценки и оно называется МНК. Самих величин может быть хоть миллиён (просто надо будет в общем случае понять как сконструировать правильные случайные величирны из того что наблюдаем а потом применить уже к ним МНК).
Spinore дело говорит. Средние всегда надёжнее чем значения случайных величин, в том числе и в динамике.
Тот метод, который предлагается, называется средним по скользящему окну (sliding window average).
Идея в том, что усредняются характеристики за время от T-dT до T, где dT-ширина окна. Такие методы применяются
также в техническом анализе (статистика рынков валют и акций). Метод работает потому, что в большом количестве случаев
системы эргодичны (т.е. среднее "по ансамблю" совпадает со "средним по времени").
Кроме того, spinore предлагает брать средние на нескольких временных масштабах (разных dT). Это связано с тем,
что система узлов сети Tor имеет несколько характерных времен (суточные колебания, и т.п.). Поэтому это тоже здравая идея.
Естественно константы (ширины окон, пороговые значения отклонений средних) надо выбирать аккуратно. Здесь место и для
теоретических исследований, и для экспериментов. Есть где unknown-у развернуться :)
Да, я думаю, что можно считать не только средние, но и дисперсии. Аномальные значения тоже могут свидетельствовать об
атаке.
spinore, Вы уже пытаетесь мне втолковать тоже, что и Роджер, я это понимаю прекрасно. Я согласен, это идеально было бы.
Но он высказал и свои сомнения по поводу этого: слишком чувствительные настройки – много ложных срабатываний, слишком грубые – можно пропустить атаку.
Я предлагаю паралелльную идею – временно отказаться от построения реальной защиты и заменить её на коллективный аудит, основанный на сообществах заинтересованныхх пользователей. В расчёте, что дурить многих пользователей одновременно противник не сможет и не сможет предсказать каким окольным путём пользователь попытается прорвать изоляцию и узнать правду о сети (кстати это obscurity и слишком большое перекладывание отвественности на пользователя, что согласен плохо: пользователь вынужден думать и действовать также изворотливо, как и атакующий, а это потенциально проигрышная позиция).
Тут важно то, что можно выявить "левые" ключи и после сравнения статусов от всех добровольцев за один период времени выявить у кого есть "левые" статусы и предъявить этот "обвинительный" документ как доказательство нечестности DA. Что-то вроде наблюдателя на выборах.
Ещё одно рабочее упрощение: атака проводится только за один шаг (максимум несколько). В расчёте, что "delayed partial cache poisoning" почти невозможен, если пользователь может на следующем шаге снова скачать правильный статус с правильного зеркала.
Ну допустим, две тысячи узлов. Противник вбросил или заменил 200 виртуальных фальшивых и "разместил" на них "более свежие статусы", в расчёте, что пользователь их скачает и в каждом новом статусе он будет заменять по только по двести узлов, а не все сразу.
Теоретически он может тогда вообще гладко обойти вообще любую статистическую диагностику, укладываясь в погрешность естественных колебаний.
Но: существет вероятность, что пользователь скачает правильный статус из оставшихся узлов (он ведь их сам выбирает случайно, если их не блокируют) и получит как раз большой скачок при откате статистики назад к правильному значению.
Вот здесь у меня есть одно скептическое соображение, которое могут подтвердить только разработчики ну или мы сами путём долгих наблюдений. Понятно, что есть динамика, но я не верю, что trusted-среднее за любой разумный промежуток времени реально есть.
2 Vadim_Z, я об этом тоже подумал. Только в этом реально можно увязнуть.
Сеть tor статистически ближе к поведению толпы людей, а то что мы можем померить – это как биржевой курс. Мы посчитаем среднее, а он возьмёт и скакать начнёт, или обвалится, или офигенно стабилизируется в зависимости от чьих-то настроений или обстановки в мире. Завтра в Германии или где-то примут новый закон, все операторы перепугаются и куча нод отрубится. После завтра закон понаставят кучу новых нод с новой альфа-версий. После-после завтра в этой версии найдут баг, узлы отключаться, наши средние критерии опять уедут.
Да мне Ваш S чисто внешне больше нравится, я понимаю, что он формально более правильный, универсальный и в него при необходимости можно понапихать сколь угодно много параметров.
Не учесть таким универсальным способом, что когда C и D сильно скачут это плохо, но ещё хуже когда есть определённые корреляции между ними в этих скачках. Причём некоторые корреляции – "хорошие" или "смягчающие" друг друга (немного увеличилось число узлов, но и количество изменившихся ключей возросло на столько же, а если C и D одновременно в сторону уменьшения, то это ещё лучше, а снижение ниже некоторого предела – опять плохо, это вообще отдельный параметр должен быть), а некоторые корреляции "плохие" (если C и D ползут в разные стороны, то это хуже; уменьшение D – это в принципе хуже, чем увеличение C и т.д.).
Т.е. при разных соотношениях C и D мы имеем разные состояния системы. Причём смену IP адресов тоже надо учитывать (не знаю как).
Если вам ближе физические аналогии (тут меня можете смело поправить если слишком наивно): Вы пытаетесь просто рассмотреть все параметры, как независимые, не имеющие взаимосвязи или конкретного смысла.
Я же попытался представить некую модель системы, на которую действуют разные факторы, ну как например температура и давление. Как если бы мы ожидали, что при опредлённом давлении будет опредлённая температура внутри какой-то установки или реактора, которые мы полностью не контролируем (не зная точного закона изменения, а только на основании предшествующих на один-два шага данных), а если получается слишком большое и резкое расхождение c ожидаемым, значит система стала нестабильной.
Только, это также неблагодарно как считать прогноз экономический, политический, поведенческий когда все факторы работают только приблизительно.
СПАСИБО ВАН ЛЮДИ)) НО? Не могли бы вы сделать типа статистики? За-тор безопасен! Против-нетЯ и многие юзающие ТОР не так просветлены как многие тут! И очень много НАРОДУ желает всеж выслушать ВАШЕ мнение! Если есть подозрения то? КОМПЛЕКС МЕР по защите от знающих людей ТУТ бы не помешал бы я думаю)
Уже обсуждали много раз. Опция для параноиков, и после исследований средних и дисперсий возможно включим уже для всех. Для начала она в любом случае будет как для параноиков, какая бы она не была.
А нафига?? Если то что я предлагаю не сложнее, но зато сразу заземляется? А куда ваш аудит пришить? Кто этим будет заниматься? Ну и по сути, "случайная величина"... её ни к чему не пришить, и она легко обходится.
Так не вопрос – добавляем ещё одну дебаг-опцию в конфиг и пишем: сохранять все скачанный статусы, с пометкой их времени. Потом заним числом можно понять, какие ключи что и у кого.
А что, delayed partial cache poisoning это что-то слишком экстраординароное? И покажите мне почему мой подход её не отловит, а то я это в упор не вижу. Повторяю – среднее апгрейдится время от времени мануально. Ща по пгп обращусь к тому кого знаю лично, попрошу запустить тор и скачать, или ещё чё-нить подобное сделаю. И буду изучать, действительно ли статистика за это время поменялась так как как мне предъявляет сервер.
Если кого ввёл в заблуждение, "средняя статистика" – это не усреднение в обычном смысле по статистикам. Это просто одна какая-то статистика, которую мы проверили по разным каналам и стали ей доверять. Правильнее было бы её называть доверяемой статистикой. Но посольку если бы мы знали истиное среднее в отсутствие ататки, можно было бы сравнивать с ним (но мы его не знаем и знать не будем), вот потому по аналогии я и гвоорю что "среднее". В письме лучше напистаь trasted конечно, чтобы не вводить никого в заблуждение.
Меня ещё поправили что S в моём опредлении не есть дисперися, а всего-навсего "отклонение" от trusted-статистики, которая по опр. полагается верной для t=0.
Ну и почему мой метод не сработает? Изучим статистику и поймём праивльные коэффициенты которые в норме никогда не превышаются.
Нет, не обойдёт :) Пример в студию. Коэффициенты подбираются так, чтобы суточные колебания пропустить а атаку – нет.
См. определение выше. Я очень аккуратно описал что я понимаю под этим термином в том посте где писал конфиг для, опираясь на моё понимание того ка как работает тор. Жалко, что никто внимательно тот пост вы не прочитали. Она не имеет прямого отношения с реальным средним по релаьной сети(!), потому что мы не можем гарантировать что "ататки не было".
И что? Я не думаю что сеть тор до такой степени нестабильна. Или под предлогом того что всё можно обойти, вообще опустим лапы и перестанем бороться?
Мы измеряем не корреляции, в вероятность атаки. Уклонение от trusted всё это прекрасно ловит.
Они физически разные, но с точки зрения вероятности атаки несут угрозу с одинаковой вероятностью.
ЦПТ и ЗБЧ ещё никто не отменял ©
Пока он ещё в процессе обсуждения :)
2 SATtva: мы должны прийти к единому выводу, тогда и приверим ещё раз ваше письмо на предмет как соответствия "физике", так и "языку". Пока я хочу успокоить unknown'а :) То ли я запутал всех своими терминами (сорри если что), то ли кто-то упорно тупит, не могу понять.
Ладно, я попытаюсь кратко просуммировать то что предлагал и попытаюсь использовать адекватные термины, чтоб без заблуждений:
Я уже очень устал переливать из пустого в порожнее, так что критику просьба пистаь конструктиную: конкретная атака, которую предложенная выше схема не ловит, и она не оговорина в спике того, что пока я осталяю за кадром.
Это ответ Гостю на
Насколько я понимаю, реальные системы управлением реактора строятся на сравнении измеряемых параметров с проектными. Строить реактор с заранее неизвестными характеристиками — самоубийственно.
Ув. Spinore невольно ввёл меня в заблуждение своим определением "средних". В действительности он не предлагает "скользящее среднее", а просто "скользящую точку отсчёта".
Трудность усреднения понятна. Для того, чтобы использовать статистику и моменты от неё, нужно иметь период, за который можно ручаться, что статистика верна. Поэтому на первом шаге вместо усреднения можно использовать сверенную независимым способом статистику в начальный момент времени, по методу spinore. Когда пройдёт определенный период времени, т.е. размер окна усреднения, можно уже переходить на "скользящее среднее" (и высшие моменты). Далее положение окна будет плавно сдвигаться, по мере обновления данных о серверах tor-сети. Периодически статистика должна кросс-верифицироваться между пользователями.
Преимуществом усреднений будет меньшее количество ложно-положительных срабатываний системы. Недостаток является продолжением достоинства — будет меньшая чувствительность к немонотонным вбросам, впрочем, на монотонные вбросы оно не повлияет. Нельзя забывать и о большей технической сложности критерия с усреднением по сравнению с предложением spinore. Можно поэтому рассмотреть схему с усреднением как следующий этап.
P. S.: Да, кстати vadim_z по роду основной деятельности занимается реакторным материаловедением (хоть и не теплогидравликой, на которую указал unkown), так что комментарий уместен :)
spinore, думаю Ваш вариант можно принять пока за основной, про пошаговое измерение динамики и многопользовательский аудит постфактум упомянуть более коротко, как альтернативу. Всё-таки интересно: подход с двух сторон.
Разработчики неоднократно говорили, что собирают статистику сети, они могут наверное сразу сказать насколько реально то или другое.
Я не подразумевал брутального соглашательства... если есть существенные недоработки в схеме, которые стоило бы учесть в первом шаге на пути к истине, то пишите. Может быть я просто не вижу ряд других возможных атак.
Ну чё, мне тогда попытаться доработать итоговое письмо с учётом всех правок?
Как бы связность C и D между собой внести?
Можете всё письмо или хотя бы внести абзацы с описанием Вашего метода.
Нам в первом приближении вообще всё равно – скоррелированы C и D или нет. Общие формулы это не отменяет.
Завтра будет. Сегодня уже – баиньки :)
Ох большая тема. В кратком изложении Spinore я согласен с его моделью – без перекресной проверки ключей и статусов остальное будет полумерами удаляющими от грамотного решения.
А что под этим будет пониматься:
оппонент оставляет доступ для подключения к ентри-ноде только к подконтрольным нодам, остальное блокирует на стороне провайдера
или
оппонет банально досит (или закрывает ноды использую административный ресурс) неподконтрольные ноды так что цепочки строятся через вражеские ноды.
В первом случае это сразу обнарудится по статусам (для всех ноды работают для вас нет).
Во втором не знаю как грамотно сделать. Допустим ориентироваться на график работы каждой ноды на прошлый период, например если пойдет массовое отключение нод раньше никогда не отключавшихся, но нереагировать на появление/пропадания ноды если это укладывается в ее средний график работы (днем работает ночью выключена или наоборот) + стараться "разумно" использовать в цепочках спонтанно появляющиеся ноды (в масштабе всей сети нода должна наработать себе статистику, неделю-месяц, после чего ей условно можно доверять и использовать в цепочках) – во всякомслучае это избавит от вброса большого колич вражеских нод (например зарядили ботнет).
Вообще, строго говоря это терминология unknown'а – он лучше ответит что подразумевал, но мне казалось что вот это:
хотя, мб вы привели более общий случай.
P. S.: задача пока бьётся на модули и мы разбирамеся с самым первым из них. Далее судя по ответу Роджера будем думать как доработать схему. Не надо сразу за звёзды, надо постепенно, а то замахнувшись на всё, не получим и малого.
Теоретически звучит хорошо, но как это будет выглядеть технически мне совершенно не понятно. Лично изучить несколько сотен нод и их график? А насколько он устойчив/меняется?
А вот эта идея очень интересная.. мне нравится :) Выглядит как тривиальная защита от атаки которую мы рассматриваем (только для начала всё равно прийдётся с нескольких различных площадок набрать статистику тора, чтобы потом было на что ориентироваться). Если бы нод было очень много, то ваш критерий работал бы и был разумен для всех (выкидывание малоизвестных нестабильных нод не повлияло бы на анонимность). Что же касается текущего статуса сети – это может привести к катастрофическому снижению числа нод и, соответственно, падению анонимности (но точно я здесь не скажу, может быть кто из наших торокопателей ответит). Кстати, если стабильных узлов – подавляющее большинство, то как первая контрмера можно внести их список в конфиг (в список узлов, разрешённых для цепочек и запретить все остальные).
Тогда уж вы придумайте как детектировать такую атаку apriori, а не aposteriori.
spinore, разница, как я уже отмечал, в степени привязки к Tor-клиенту. Ваше решение обязано быть реализовано только в коде клиента. Я сомневаюсь, что разработчики за это возьмутся: в лучшем случае скажут "send a patch", в худшем проигнорируют. Другое дело, если сейчас отправить это предложение, самим реализовать утилиту для аудита, как сделал ygrek, собрать статистику при разных вводных величинах (изменения в статистике ведь можно и вручную в офлайне моделировать, вставляя и удаляя собственные записи в status-файле дополнительным скриптом) и затем уже представить её разрабам: хотели доказательства эффективности? вот они. Если подобный аналитический подход (независимо от конкретной модели — Вашей, uknown'а или ygrek'а) реально сможет детектировать аномальные изменения в статусах узлов, разработчики сами закодят его в Tor. А так нам остаётся только бить себя в грудь, мол, прислушайтесь к нам, мы дело говорим.
Всё, что Вы далее описываете, можно (и нужно) реализовать в виде сторонней утилиты. Это называется dry-run, когда программа только имитирует своё реальное поведение: собирает статистику, выводит в собственный лог сигналы об обнаружении аномальных с её точки зрения случаях и т.д. Это именно то, что следует передать разработчикам для анализа. Пока всё, что мы здесь рассматриваем — чистая теория. Будь я на месте Роджера (в разработке я немного понимаю), я бы не включил это даже в нестабильную ветку (тем более, что писать реализацию, будь я на месте Роджера, пришлось бы мне ;-).
Замечу, я не критикую ни одну из предложенных моделей, они на мой взгляд просто разные и предназначены для разных целей; могли бы и дополнять друг друга; возможно, на их основе можно было бы вычислять и некоторую "мета-оценку"... Моя критика направлена только на избранный spinore'ом подход: первостепенную реализацию в Tor-клиенте. Я не вижу это реалистичным.
Остаётся: небрутальное соглашательство, брутальное несоглашательство, небрутальное несоглашательство ;-)
причём последний вариант самый бредовый.
Вот тоже четыре варианта. Представим, что C и D – это нечто вроде спроса и предложения на рынке, которые в идеале должны
быть стабильны и сбалансированы и немного плавно расти.
Спрос падает и предложение падает: застой, замораживание.
Спрос растёт и предложение растёт: экономический бум, перегрев.
Спрос растёт, а предложение падает: дефицит, кризис производства (самый худший вариант).
Спрос падает, а предложение растёт: кризис перепроизводства (самый абсурдный вариант).
Имеет ли смысл изучать такие величины отдельно друг от друга?
Мне чего-то тоже кажется, что они там между собой тоже подумали (более вяло чем мы) и решили, что мороки много, толку мало.
Всё равно это полумера или костыль, не устраняющий недостаток самого протокола.
А так, оба варианта в урезанном виде можно смоделировать и вне tor-клиента. Просто не будет готового к применению решения, а только исследование.
К сожалению кроме идеи у меня ничего нет :( Оформить это в формулу (каламбурчик), чтобы набрать начальную статистику для предметного обсуждения я не могу. Но если всем идея покажется не бредовой, можно начать обдумывать реализацию. Вопрос ко всем: стоит этим заниматься или нет?
Проблему начальной статистики присутствует во всех предложенных схемах. Здесь имхо прийдется придумывать мехинизм отденый от тора.
Почему?
Нестабильность я рассматриваю как появление ноды с новым ключем на небольшой промежуток времени – появилась нода, поработала пару дней и пропала. Потом на том же ip может появиться нода с другим ключем.
Если же нода в течении месяца работает по 2-3 часа в вечернее время, то условно такую ноду можно считать стабильной, со своим определенным коэффициентом стабильности во времени.
Если нода в течении месяца работает в хаотическом режиме, то она тоже считается стабильной, со своим коэф стабильности.
Основная идея, это прежде чем использовать ноду присмотреться к ней самостоятельно! А не слепо ориентируясь на информацию с DA.
Это никак не защитит от наличия в цепочке вражеских нод (уж наверно они изыщут возможность поднять стабильные ноды!) Идея – не дать возможность сделать это быстро, только для выделенного человека, и с минимальными затратами.
Связываться с анализом работоспособности ноды во времении я вижу смысл только если есть задача определить целенаправленно выведение из рабочего состояния нод в масштабах всей сети. Иначе перекресной проверки вполне достаточно.
В идеале допустим у нас есть график доступности ноды за весь предыдущий период ее существования. Из этого графика вытягиваем статистику:
1. как часто включатеся/выключается нода
2. среднее и максимальное время недоступности
3. корреляцию времени работы (нода может постоянно работать, нода может работать в строго определенное время, нода может работать хаотически)
Можно обрабатывать изменение режима работы ноды – если нода раньше работала только в опр часы а начала работать постоянно это нужно как-то учесть.
Можно предложить людим поднимающим ноды указавать референсный режим работы и обрабатывать отклонение от этого режима.
Я понимаю, все эти действия могут привести к непредсказуемым результатам, но они не будут сказываться на работе самой сети тор! Это будут действовать только на клиента решившего самостоятельно настроить для себя модель анализа поведения нод.
Я все понимаю но у нас нет другово выхода, мы можем только констатировать что такая то нода стала для нас недоступна. А дальше обработать эту информацию (сравнить со статусами других нод, сравнить со своим "коэф стабильности" для ноды).
А можно так посмотреть на это в клиенте тора уже есть возможность работать как DA, все что нужно для обмена статистикой и статусами есть. Положим врикручивать "эвристический" анализ работы нод во времени это бесперспективно для самих разработчиков пока не будет хотябы работающей можели. НО перекресную проверку нужно сделать ОБЯЗАТЕЛЬНО!
Еще у нас не получится показать работу модели при реальной атаке, тк мы рассматриваем теоретическую атаку какие еще не было, и максимум сможем показать на реальных данных что наши формулы не дают ложных тревог при обычной работе сети. Готовый код для клиента тор думаю никто из нас не напишет.
Можно долго и нудно что-то доказывать человеку, приводить статистику, аналитические выкладки и тд, и все равно не убедить если ему не понравится идея, соотв реализации не будет.
С другой стороны если он проникнится идеей и она покажется ему интересной и нужной, то убеждать не прийдется.
Я не программист, к сожалению, и написать рабочий код не смогу – хотя могу прочесть чужой код и даже написать что-то для обсчета своих данных на уровне институтских знаний :( но показывать другим такое нельзя ;)
PS Прошу прощения за несвящанность мыслей, месагу набирал урывками в течении трех часов :)
Я писал выше, как смоделировать атаку. В конце концов, как Tor-клиент, так и гипотетическая утилита берут входные данные из статус-файла. Целенаправленная модификация этого файла (вручную или автоматически) с петтарнами, примерно соответствующими модели атаки, должна показать эффективность защиты (ну, или неэффективность). А без тест-кейсов даже готовый патч для Tor-клиента не сможет показать свою эффективность.
...+k*(C-D)2 ?
Да, отмечал окончание работы над которой работал последний год [можете поздравить :)] – только что появилась в свободном доступе[link14]. Кстати, vadim_z[link15] в соавторах :)
SATtva, вы невнимательно вдумывались. Необходимость жёстко вшивать этот код в код клиента возникает лишь когда юзер захочет априорную реакцию тор-клиента на подозрительность в сети. Если такая реакция не требуется, этим может заниматься сторонний скрипт (да, написанный через заднее место, ибо будет куча накладных расходов и по уму так скрипты не пишут – сторонняя утилита должна в реальном времени получать информацию с тор-клиента а не стучаться каждый фиксированный интервал на предмет "есть ли что новенького").
ent1 уже ответил. Давайте напишем так, как будто это атака важна и попытаемся внятно что-то предложить. Далее можно поглядеть на реакцию разработчиков.
Какой бы ответ разработчиков не был – он не помешает нам написать такую утилиту и анализировать траффик, на данный же момент обсуждает что им говорить. Я не вижу ничего предосудительного в том, чтобы грамотно изложить свою простенькую теорию и метод защиты от атаки. Неужто вы предлагаете вообще ничего не отвечать и ждать пол года пока наберётся статистика и кто-то оформит всё в виде красивых графичков в pdf'ке с объяснениями? Нас никто не заставляет выкабениваться перед разработчиками: есть идея – пришли, сказали.
Это не разные "модели", и не надо делать явных подмен. Я предложил некую вещь, котрая реально будет работать если протокол таков как сказал unknown. Пока я не вижу ни одного поста после опубликования короткой сводки, где бы мне написали пример атаки, которую он не ловит. Есть претензии – пример атаки в студию. Что же касается unknown'а и его сравнений соседних шагов, в этом нет ничего физичного – по кр. мере я на данный момент не вижу как придать разумный смысл таким сравнениям. Благо, что сравнения соседних шагов пропускают замедленное инфицирование тор-кэша, а тем самым и соответствующую атаку от которой мы пытаемся защититься. Всё что остаётся от модели unknown'а после выкидывания сравнения соседних шагов – это дебаг-уровень – писать всю статистику для возможности последующего её сравнения, но это и я предложил – одна опция в конфиге и делов-то... Заметим, что изначально я предлагал написать старонний скрипт, который сможет сравнивать любые две статистики – хоть соседние, хоть в год разницы между ними. тор-клиент лишь должен вызывать подобный скрипт после скачки статистики для того чтобы уметь априори прореагировать на атаку.
Если мы априори примем модель "разработчикам наплевать на собственный проект" – то да, можно вообще ничего не писать – вы правы.
Вначале письмо, а потом – всё остальное, продолжение, так сказать. Следует работать в кооперации с разработчиками – это продуктивнее, а не показывать свои "предъявы" когда нет на то никакой реальной необходимости.
Для начала они могли бы реализовать хотя бы часть предложенного – пусть тор-клиент выводит сравнение скачанной статистики с трастед-статистикой, но не реагирует. Хотя бы что-то для начала.
SATtva, я уже ответил: приведите пример атаки, котора не ловится моим методом+включение дебаг-уровня, когда ппишется вся статистика. А потом мы поговорим о взаимном дополнениии того что не ловит мой метод, зато ловит метод unknown'а (когда будут конкретные примеры). Вообще, вам уже стороние люди написали что надо сравнивать всё действительно с нулевой точкой отсчёта а не между соседними шагами по времени.
А вот это уже зависит от того, насколько грамотно и лакончино удастся изложить то, что мы предлагаем в письме.
В первом приближении? Думаю, нет. А до следующих приближений мы пока не добрались. Если есть подозрения что что-то не так – пишите реальный пример атаки которая должна ловиться алгоритмом и не ловится и тогда будем дорабатывать модель снова. Я пока такую атаку не вижу.
Всё нормально. Сейчас самое то изложить свои наработки, только надо постараться по-максимуму понятно это сделать.
Вроде устраняет. Цитирую[link16]:
Возражений на этот пост не последовало. Где они?
Я привёл только теоретическое обоснование. Далее уже можно думать как сделать обмен статистикой между юзерами удобным и практичным и т.п. – а пока мы пишем письмо только.
ent1, то что вы предлагаете в первом приближении нефизично. Такой подход можно использовать в умозрительных построениях, но на практике он работать не будет. Если сильно глубоко копать, может быть можно будет далеко впоследствии на основе протокола обмена тор-статистикой между пользователями сооррудить нечто, что в реальном времени будет вычислять то что вы хотите – само, автоматически. Но это отдельный протокол, отдельный огромный геморой, свои оценки, куча сложных случаев и т.п. Здесь на одно обсуждение тривиального сравнения двух статистик ушло уже 13 страниц форума, а ведь эта задача на порядка 2 просче. В общем, как идея такое есть, но "явно не для 'сейчас'".
В принципе на этом сайте есть люди которые это могли бы сделать (квалификации хватает), но пока не будем о пожарных случаях – начнём с обсуждения с разработчиками.
Подписываюсь.
Естественно. Такие тесты лишь часть разработки функционала для тор-клиента. Пока наше дело – изложить теоретический базис и показать: что можно предпринять, как это теоретически могло бы работать и что бы это дало. Далее, либо они сами напишут скрипт, либо предложат нам его напистаь, либо впараллель. Следующим шагом будет умение тор-клиента после скачки статистики вызывать такой скрипт и принимать решения об останове на основе ограничителей выставленных в конфиге.
поздравляю :)
По поводу стаистики:
Вот статистика одной ноды (будет ругаться на серт.):
https://node.xenobite.eu/
график за день[link17]
за неделю[link18]
за месяц[link19]
за год[link20]
Это по пропускной способности, но общее впечатление о стабильности сети составить можно.
А вот на что стоит внимательнее посмотреть:
вот необновляющийся с 2007 года график за большой промежуток для всей сети Tor по количеству узлов[link21]
число узлов за год[link22]
число узлов за месяц[link23]
число узлов за две недели[link24]
число узлов за неделю[link25]
Что за неделю, что за месяц число нод менялось в интервале примерно 10-15%.
К сожалению только число узлов, а не графики изменения их ключей, которые никто не мерял.
Если даже разработать на основе этого какой-то эффективный средний критерий, то замедленную атаку он и регистрировать будет тоже замедленно, когда число изменений ключей превысит ожидаемое за месяц.
проект torstatus[link26] – не совсем то что нужно.
tor control protocol[link27]
Опция NEWDESC – это то, что нам нужно или нет?
Возможно, но м.б. в той опции ещё и много лишнего, что нам не нужно.
А что есть тогда C=N_k/N_k-1 и D=I/I_max=I/(min (N_k, N_k-1))
если это мерять не за один шаг?
Пусть имеется некоторое количество узлов.
За месяц их число изменилось на 15%, допустим часть нод тоже сменилась по ключам (пока прикинем от фонаря) на 15%.
Т.e. что будем считать просто, что не должно выходить за эти пределы и в следующий месяц?
А если все меняют ключ в среднем раз в месяц? В две недели? Кто-нибудь это знает точно?
Эти формулы следует переопределить как
C=N_k/N_0 и D=I_k/I_max=I/(min (N_k, N_0))
Где N_0 – число ключей в трастед статистике, а N_k – в статистике на текущем шаге по времени, который мы и анализируем н вшивость.
Я уже раз 15 объяснил. Условно говоря,
Если не учитывать тонкости, то в вашем случае через месяц на каком-то k=10000 мы получим что-то вроде S = (1.15-1)2+(1.15-1)2= 0.045
Если все будут менять ключ раз в месяц то I_k = 0 (ноль совпадающих ключей), и тогда сразу D = 0, значит S = (C-1)2+(0-1)2>=1 (гипотенуза больше каждого из катетов потому что). Как видите, число S сразу подскочило с 0.045 до большего 1, перепад существенный :)
И в конце концов, это элементарная математика которую частично учат в школе.
Уменьшая промежуток с месяца до двух недель мы увеличиваем противодействие атаке, но тогда и тщательно сравниваться с соседями прийдётся в два раза чаще. В этом смысле "месяц" я взял условно для наглядного объяснения, пока я не утверждал что это оптимально. В пределе можно сравнивать каждые 15 минут, только вот насколько легко и анонимно это можно будет делать – другой вопрос (иначе противник сможет подделывать статистику для всех пользователей, следящих за статистикой).
Вопрос именно в том, что в данный момент, пока никто из здесь обсуждающих точно не знает как часто в среднем меняются ключи. Это надо проверить просто.
Если ключи меняются раз в месяц или чаще, то мы и будем получать S=1 и не сможем пользоваться месячным средним.
Но допустим (и скорее всего так), сеть гораздо стабильнее.
Но, даже если в месяц в норме меняется 20% ключей, противник может месяц подсовывать нам старый файл со статистикой,
меняя в нём по одному ключу туда-сюда, а на 29 день дать файл, где 20% ключей поменялось, но на его фальшивые.
С трастед-средним расхождений, я так понимаю не будет, но каждый пятый узел в сети будет фальшивым, а это уже кое-что.
Это при условии, что пошаговые скачки не регистрируются.
Кстати, противник может подменить в первую очередь стабильные для пользователя адреса entry guard, входящих узлов, это существенно облегчит его задачу.
Мои поздравления обоим участникам! Хотя для меня что название работы, что резюме — китайская грамота.
Я тоже только "за". Только консенсуса пока нет, что именно излагать разработчикам.
Я этого не говорил. ;-)
А вообще, spinore, тяжко Ваши посты читать. Многабукаф...
Пока участников мало это разрулить легко. Можно изложить все точки зрения по пунктам.
Первый пункт по любому общий – описание параметров. Другие – построение доверенной статистики и сравнение с ней;
альтернатива – пошаговое сравнение, координация возможных действий пользователей (варианты с упором на "до" и "после", понятно, что
"до" желательнее).
Кстати, вот ещё что.
Модифицированная версия атаки для обхода контроля статистики (более вероятностная, недетерминированная).
В фальшивом файле статуса противнику можно не менять много ключей узлов.
Достаточно поменять всего несколько для исходящих узлов, например выбрав их 10 штук.
И несколько для входящих.
А всем остальным узлам ключи не менять, но поменять для исходящих в их описании опцию с exit на middleman.
Также нужно немного фальшивых middlemano'в
Из этих исходящих 10 узлов половину сделать виртуальными, входящие – все.
Если траффик идёт через настоящий middleman – делать фальшивый exit недоступными отпускать его в настоящий Tor
неперехваченным. Как только клиент выберет ещё и фальшивый middleman из списка (пусть даже вероятность такой ситуации мала),
то соединение пройдёт через [фальшивый entry guard]-[фальшивый middleman]-[фальшивый exit] с вероятностью 1/2.
Защититься просто: кроме C и D для предотвращения подобных атак (вероятно возможны другие варианты) надо по типу D контролировать разность (difference) между описаниями нод, айпишниками и вообще всеми параметрами, которые можно извлечь из файла статуса сети.
Другое дело, что противник всегда может подсмотреть используемый юзером список guard-узлов и не меняя их описание принудительно, поменять хотя бы только им ключи. Виртуальный фальшивый Guard – тоже штука малоприятная – противнику не нужно фильтровать трафик от этого узла в цепочке, юзер в нём один. И можно блочить соединения, имитируя что это происходит уже за этим узлом, заставляя пользователя лишний раз когда нужно противнику перестроить цепочку.
Ну и атака с задержкой или подсовыванием устаревшей статистики, но с новым таймштампом позволяет профилировать юзера (уже тоже вероятностно, а не детерминированно).
Всё-таки предполагаемый противник такого уровня обладает слишком большими возможностями для контроля.
Спасибо :) [раскланялся на обе стороны]
Ничего сверхъестественного в работе не было. На этом форуме все слышали про пресловутую "квантовую криптографию", что более точно есть всего лишь "квантовое распределние ключа". Так вот, когда Алиса передаёт ключ Бобу или ещё кому-то, она использует нечто, что математически описывается понятием "квантового канала". В работе как раз был рассмотрен один из типов квантовых каналов и было показано, что можно при определённых условиях увеличить скорость передачи по нему за счёт специфических квантовых корреляций ("энтанглемента") между используемыми квантовыми состояниями. (Сорри за офтоп :))
Да, замечание справедливое. Я интуитивно предполагал что довольно редко (в среднем так же редко, как обычные пользователи меняют свои PGP-ключи).
Да, uknown, вы молодец, атаковали систему с неожиданного для меня направления :) © SATtva. В этом случае я бы модифицировал вашу атаку для пущей определённости вот каким образом: оператор тор-машинки знает верную статистику, а значит он в реальном времени может детектить смену ключей для тех или иных нод. Как только нода меняет свой ключ и репортит сей факт на DA, оператор устраивает атаку стиля MITM, предъявляя пользователю не истиный новый ключ той ноды, а свой, и далее предъявляет уже только "инфицированную статистику" в которой со временем будет всё больше и больше фальшивых ключей. В этом случае через какое-то время злоумышленнику удастся подменить ключи ровно такого количества нод, которое меняло свои ключи за данный период. Атака сработает. В то же время если пользователь сделает "перекрёстную проверку" ключей с соседями ранее момента своей деанонимизации, он засечёт эту атаку. Видимо, Ваша атака устанавливает одну из границ на максимально допустимый (ещё секъюрный) период между двумя перекрёстными сверками(!!!) статистики. Красиво :)
Что же касается дословно вашего описания атаки – она конкретно в таком виде не сработает. Если оппонент попытается "расшатать" статистику, введением левых ключей не учитывая "расписание" их смены для соответствующих нод, и конкретно сами ноды, то он добавит шума, что можно бдует обнаружить (+20% от естественной смены ключей +20% от смены ключей злоумышленника и -n% ключей из-за перекрывания множеств ключей, который менял злоумышленник и которые реально потом сменились).
Сама по себе информация об этих скачках всё равно ничего не даст для априорных действий. Выявить атаку можно будет только после перекрёстной сверки, но если вы возьмёте в какой-то момент времени свой последний файл статистики и сделаете эту сверку для него, также получите результат. Я призываю в первую очередь не к сравнению соседних по времени статистики, а к перекрёстной сверке. Сравнение соседних по времени важно только когда постфактум вы будете расследовать саму атаку и выявлять кто, когда и чьи ключи подменил.
Вроде уже движемся к концу, или нет? Может быть мы взялись за сильно амбициозную задачу, которая очень сложна, и постепенно будем находить всё больше и больше способов обойти алгоритм? Фактически это есть задача децентрализации доверия в сети тор, и к месту можно вспомнить про децентрализацию прав рута в системе – последняя задача отнюдь не из простых :)
Местами много повторений, которые можно было бы сжать (на что понадобилось бы больше времени для формулирования), но так не везде. Сложный баланс: если коротко без подробностей – не поймут, если с подробностями – много воды, оптимум достигается лишь при долгом и тщательным обдумывании каждого предложения перед опубликованием :)
Не знаю есть ли такое уже или нет, а я бы сделал так: ключ ноды + её описание + всё остальное касающееся этой ноды + её ключ ">" файл, и берём от него ХЭШ. Вот хэши тогда и будем сравнивать между собственно ключами нод (будет статистика хэшей нод в изложенном ранее фигурировать а не статистика ключей).
__Суммируя, 2 важных момента можно добавить к краткому описанию:
Ну что, ломаем дальше – я, вродь, отбился :)
В принципе меня больше привлекает топорное предложение Гостя, основанное на том, что все мониторят статистику тор-нод, и выявляют стабильные ноды. Далее, отъявленные параноики используют в своих цепочках лишь те стабильные ноды. В пределе довольно стабильной сети это было бы подалуй самым изящным решением, правда остаётся вопрос о том как достоверно получить информацию о том, какие ноды стабильны а какие нет, когда ключи DA уже украдены.
На совсем пожарный случай – заставлять ноды участвовать в PGP-сети доверия ещё можно. Это, конечно, неудобно и грубо, но зато надёжнее :) Впрочем, моя интуиция кажет что и в этом случае мощный оппонент, хорошо продумывающий свои шаги вперёд и владеющий ключами DA и в совершенстве знающий статистику тора, всё равно умудрится обмануть пользователя, просто атака будет выглядеть намного сложнее. Правда, это уже обсуждение атаки "глобальный наблюдатель", когда действительно у каждого провайдера кроме собственно сорма будет стоять ещё и антитор-машинка (возможно, как часть функционала сорм), и все такие машинки у разных провайдеров смогут общаться друг с другом.
P. S.: мне иногда кажется, что зря это обсуждение ведётся в открытой дискуссии – пока мы говорим, бб может "взять, да и сделать...".
Чем-то эта тема напоминает практикум по ИБ: сами создали – сами сломали, сами защитились – и снова сломали, и снова придумали защиту... и так ad infinitum.
Стараюсь :-)
Вы просили придумать новую атаку, я это сделал, на уровне идеи по крайней мере, причём видно что их может быть несколько.
Слишком ультимативно вопрос был поставлен: "придумайте атаку, которую не ловит мой способ". А если бы не придумал?
Это же не значит, что система безопасна.
Если мы все упускаем что-то ещё?
Зачем? Можно каждое поле брать как параметр и поехали по вашей формуле: (A-1)2 + (B-1)2 + ... (Z-1)2.
Вы же сами утверждали, что параметров может быть дофига.
Если уже не. По хорошему пишут полную работу с действующими примерами, уведомляют и дают время разработчикам, после чего публикуют.
Но никто из нас заниматься этим не будет. Мы можем только поднять проблему.
Или лишний раз дать всем повод подумать, что из себя представляет Tor, не заложен ли в него такой скрытый функционал изначально.
Потому что у нас нету уровня знаний для создания "provable security".
А для анонимных протоколов "proof" вообще редко используется. Tor не является "provable secure". И вообще это "experimental software. Don't rely on it for strong anonimity". Вот мы и экспериментируем.
Думаю, всё-таки чаще. Смена ключа PGP связана с серьёзными затратами на введение нового ключа в сеть доверия. Для Tor-узлов такой проблемы не стоит. Практически, смена ключа вообще ни на что не влияет (ну, guard-узлом "новичок" не станет, нужен определённый срок стабильной работы).
Мне кажется, это приведёт ко множеству ложных срабатываний. Есть, скажем, такая вещь, как exit policy — список сетей/портов, куда экзит разрешает или запрещает исходящий трафик. Так вот этот список может редактироваться оператором узла довольно часто.
Проблему можно решить, прибегнув к идее unknown'а и выбрав разные пороговые значения для срабатывания тревоги для разных полей:
Ну как сказать... безопасность – это очень текучая формулировка. Можно, например, сравнить 2 системы: у одной сорс открыт, баги все активно ищут, известны сплоиты (например, FF), и оперу – код закрыт, сплоитов нет, известных багов меньше. – Что проще сломать? Тонко тут всё. Мы нашли атаку и рассказали об ней людям => злоумышленникам теперь проще атаковать. Ранее им понадобилась бы ещё изобрести саму атаку... С другой стороны можно подойти в лоб и сказать что об этой атаке злоумышленник мог знать уже давно, а потому мы никак не повлияли на защиту тора. В общем, я пока строгого определения "безопасности программного продукта" не читал чтоб сравнивать :-D
Это всё можно, но надо понимать, что чем больше параметров тем громозче система и сложнее в управлении, менее чувствительна к возможным атакам, и более уязвима. Именно поэтому лучше сводить число используемых параметров к минимуму. Можно в лоб построить функцию хэшей: если они меняются действительно часто, то да, прийдётся рассматривать кучу параметров независимо. Мне хэши казались брутальней и надёжней: если они не порождают естественной большой дисперсии, то есть их достаточно для отлова атаки, то, имхо, оно самое то для нас. Хороший пример – недавняя новость про cold boot: были ли компьютеры ранее защищены больше лишь потому что широкая общественность не изнала о подобной возможности?
Согласен... Была ба хорошая работа для студента :-D – написать такую тор-машинку.
Ага, и еще ключи попросить, для сего агрегата. Похоже этот ключевой момент как-то начинает подзабываться.
Ну, а в остальном-то да:
Вместо "срабатывания" лучше непрерывный индикатор, например от зелёного к красному.
Для студенческой работы достаточно эмулировать на своей машине свою собственную тор-сеть со своими ключами и моделировать атаку на неё с помощью другой машины, на а уж бб может поиграться по-настоящему :)
Имено! Мы точно не знаем как меняются ключи в среднем, но есть ноды, которые загружаются с CDR и не хранят ни логов, ни изменяемых настроек. При каждом ребуте генерят ключ заново. Через час-два их снова регистрируют в сети.
и кстати:
Почему все так легко подхватили идею замедленной атаки? Изначально предполагалось, что подмена может быть осуществлена только за один шаг.
Вот как объяснялось:
1) Противник блокирует или нарушает доступ ко всей Tor сети, кроме подконтрольных DA: пользователь не может построить ни одной цепочки в сети.
2) Пользователю не остаётся ничего другого, кроме как скачать статус с DA.
3) Если он случайно выбрал неподконтрольный DA, то переходит к п.1
4) Если он выбрал подконтрольный DA, то соединение проходит (имитируется) успешно, но уже с виртуальным DA, от которого есть ключ у противника.
5) Пользователь скачиваем фальшивый статус с виртуального DA, где ключи всех Tor нод подменены, статус подписан большинством подконтрольных DA (от которых тоже есть ключи) и сразу оказывается в виртуальной сети.
Задача противника выполнена за один шаг, за один шаг она и выявляется.
Ну а как реально осуществить замедленную атаку?
Пусть п. 1-4 будут теми же самыми. А что дальше?
В п.5 противник даёт скачать статус, где подменено только 10% ключей? (Это для простоты примера, в реальности это уже слишком заметно).
дальше, если он не снимет блокировку, то пользователь сможет работать только с 10% подконтрольных нод, что тоже будет заметно.
Значит блокировку он снимет. И на что ему после этого надеяться?
Что пользователь с вероятностью 10% с подконтрольных узлов скачает очередную порцию "отзеркалированного с DA" фальшивого статуса? Ну там ему подменят ещё 10%. И того на следующий раз вероятность будет 20%. Но чтобы дойти до 100% нужно будет совместить девять событий с произведением вероятности П=0.1*0.2*0.3*0.4*...*0.9=.00036...
Не маловато ли? А если подменять на каждом шаге только 1% ключей для пущей незаметности, то можно и вообще не дождаться.
Гораздо больше вероятность того, что на каком-либо из шагов пользователь скачает с неподконтрольного узла настояющий статус и откатится назад. Ещё хуже для противника, если пользователь включит опцию alldiractionsprivate=1,
когда скачивание статистики идёт не только в подписанном, но и зашифрованном виде. Тогда противник вообще не сможет понять, когда пользователь скачал реальную статистику и с какого узла, а когда подставную, может он работает уже с реальной статистикой?
Получаем: или только атаку за один шаг (которая за один шаг и выявляется) или крайне неэффективную замедленную атаку, или если у противника есть способ осуществить замедленую атаку подменяя только часть узлов, но каким-то неведомым образом заставляя пользователя скачивать статусы только с подконтрольных (тогда он может обойти в принципе любой статистический контроль, если умеет так ловко работать с частично изменённой сетью).
А для нестуденческой с изобретением нового TOR-протокола можно получить исследовательский грант[link28]
Это, интересно, каким таким образом заметно? Вы же сами объясняли, что если польхователь выбрает неподконтрольные ноды, то они проследуют только через реальный тор, а если подконтрольные ноды, то через виртуальную машинку + итиный тор.
Если предположить, что параметр S работает лишь как ограничитель на сравнение соседних скачанных статистик, а с исходной трастед-статистикой мы не сравниваемся, то через 10 скачиваний мы получим что противник подменил 100% ключей узолов. Если новая статистика скачивается каждые 15 минут, то на подмену полностью всей статистики понадобится примерно 2 с половиной часа, при это деанонимизация произойдёт почти точно раньше :-D
P. S.: я предполагал для простоты, что протвник смог захватить ключи всех DA. Вносим это в предположение.
И скачает с любой из реальной ноды реальный, а не подставной статус и откатится назад, если не 100% ключей подменены. Поэтому и получим такую низкую вероятность. Скачивание может идти к тому же и с разных нод одновременно.
Как сегодняшний Tor-клиент в такой ситуации обрабатывать будет нестыковки и противоречия? По самой последней дате на статусе? Не знаю.
Или противник будет давать строить цепочки только через подставные узлы?
Каждый раз? Тогда почти каждое построение цепочки будет заблокировано, пока подконтрольных узлов мало. А если отпускать неподконтрольные цепочки в реальный Tor неперехваченными, то ещё раз – клиент просто на очередном шаге скачает статус не с DA, а с любой ноды, как с зеркала. И соединение будет подписано, а при определённых настройках и зашифровано ключём этой ноды.
Раз в 15 мин – это минимум. Реально, посмотрите свой кэш. Там обычно статус, устаревший от часа и больше. Раз в сутки он точно принудительно меняется. По какому принципу остальное время х.з.
Заметно всё будет, если контролировать число изменившихся ключей, которое не может изменяться слишком медленно или изменится скачком назад к реальному значению, если противник не достигнет 100% подмены.
Что-то закрузили вы меня, unknown...
В общем, тезис я понял. А как по-вашему могла бы выглядеть в принципе атака delayed cache poisoning – чтоб всё работало и получалось?
Это Вы меня загрузили! Я с самого начала утверждал, что при нынешнем дизайне она маловероятна, а Вы стали рассуждать, как будто она есть.
В принципе противник может действительно вводить по 10% узлов за раз, а остальные блочить, чтобы не дать скачать реальные статусы, но это слишком топорно и заметно.
Другие варианты пока в голову не приходят (это не значит что их в принципе нет).
И опять же: легко блокировать можно только первый узел, выбранный пользователем. Если он подконтролен, то тогда блокировать следующий за ним. Но если пользователь входит в сеть через неподконтрольный узел, далее он может достроить цепочку из неподконтрольных. Она будет может и лучше отслеживаема, но достаточна для скачивания реального статуса.
И что теперь, написать Роджеру что атака скорее теоретическая чем практическая, а потому не стоит маяться дурью и пытаться защититься?
Да вернуться к началу обсуждения. Противник может подменять 100% или по крайней мере > 50% ключей за раз (если он хочет рисковать), что элементарно засекается пошаговым сравнением.
Я предлагал, что если > 90% ключей сменилось за короткий период времени.
После останова (а он при таких условиях будет редким) перепугавшиеся пользователи могут сравниваться между собой.
Ещё контрмера – сравнить статусы принудительно скачанные со старых и новых нод-зеркал.
unknoun? Кто это?
Я решыл полгядеть насколько быстро заметят – ведь всего одна буква... :)
Ладно, щас удалю.
Ну в общем, да. Тогда концептуальных нареканий к предыдущему письму вроде как нет, получается. Проверяем орфографию и отправляем?
P. S.: параллельный вопрос: если ключ загружается на сайт непосредственно копипастом, а не с публичной кейсервера, то он пересылается автоматически ещё и на публичные сервера или нет?
Судя по задумке SATtv'ы да. С движком сайта Вы уже игрались (за что спасибо кстати), а вот распространять фальшивые ключи такого рода какой концептуальный смысл?
Нет, не пересылается. Только периодически загружается с серверов.
Какая провидческая предусмотрительность!
Решил проверить насколько чётко реакция работает.
Я не знаю что там на самом деле, но на subkeys ключ не появился.
Если вдруг что, то отозванная версия:
Кстати, имхо это более правильно идеологически как раз, чем силком загружать ключи на сервера. Возможно, кому-то понадобится ключ, который лучше бы лишний раз не светился на серверах...
А что делать с тремя вариантами: деление-умножение (связанные C и D), сумма дисперсий (несвязанные C и D) и пересечение множеств дескрипторов? Кратко перечислять всё?
Что делать со средней статистикой за большие интервалы, которая вроде как не нужна?
Именно. Такими причинами и руководствовался.
Там достаточно взять S = (1-C)2+(1-D)2
C/D не стоит, наверное, рассматривать... хотя тоже меожете включить.
Ну поюзать его, а что? Всё сводится лишь к тому, чтоб учесть существенные замечания и всё, всего навсего.
Ничего не писать.
Вот ещё контраргумент против замедленной атаки.
Пусть противнику на каком-то шаге удалось довести число ложных ключей и подменённых нод до половины:
Тогда пользователь может построить случайным образом 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 стабильно высокий, да ещё и глюки с работой сети наблюдаютсяя очень заметные, то это отсекает и практически любую замедленную атаку тоже.
// Multiple Directory Authorities' keys compromise: a partial
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
Ещё у меня лично есть вопрос о том, как часто клиент загружает статистику с тора. Слышал, что зависит от интенсивности трафика, пропускаемого через тор, или нет? Просто хотелось бы знать конкретные временные рамки: минимум – такой интервал, максимум – такой.
Ещё обсуждался беспредел с тем что в v2 протокола клиент не извещает пользователя о том что какой-то из DA не подписал статистику либо от него вообще не удалось получить ответа. Стоит ли об этом сказать Роджеру, или положиться на то что дизайн v3 совсем другой, а потому нечего городить?
Также, мы начинали обсуждение с того, что когда пользователь после перерыва запускает вновь свой тор-клиент, атакующий может запретить ему строить цепочки по существующему статусу, чтобы заставить его обратиться к DA напрямую (вот тогда и можно ему сделать хоть 100% подмен). Вы, unknown, оговаривались, что появилась недавно какая-то опция в тор-клиенте, имеющая отношение как раз к этому, но то вроде было не совсем то. В нашем случае требуется конкретно возможность/опция загружать статистику принудительно по уже имеющейся старой статистике а не напрямую, не допускать принудительно прямого обращения к DA.
В целом, по поводу стабильности/нестабильности могу сказать что очень часто возникает ситуация, когда нельзя через тор зайти на те или иные сайты, либо вообще ни на какие, и тогда приходится использовать
.
В этом смысле даже в текущем статусе сети делать её принудительныйрестарт приходится довольно часто.
Ещё было бы интересно узнать о том, сколько в среднем в каждый выбранный момент времени одновременно работает тор-нод, тор-экситов и тор-пользователей (с упором не на всё сообщество, включающееся время от времени, а на то, сколько одновременно). В оценочную упоминавшуюся цифру (100000 пользователей тора) я могу поверить от силы как в число всех, кто за много лет хотя бы раз запускал тор, но не более.
s / не допускать принудительно прямого обращения к DA / принудительно не допускать прямого обращения к DA
Он делает это только один раз, чтобы сразу погрузить пользователя в виртуальный 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.
И в первом письме и в этом указывается, что большое число любых битых соединений совместно с большими изменениями в картине сети – признак атаки. Что из этого следует, разработчики лучше нас поймут надеюсь.
выйдет такой, что спустя примерно год люди увидят сообщения в логах безо всяких реальных атак, а мы будем думать для чего здесь нужен этот код?
Ну если они ещё заумнее нас пишут, то нас они точно лучше понимают :-)
Да смысл-то я понял, конечно, только я не понял почему так писать на английском есть правильно. Мне такая грамматика не ведома.
P. S.: коментариев/нареканий/возражений к вышесказанным замечаниям не имею.
Ну, некоторых носителей языка даже попытки слишком правильного изображения грамматики инглиша веселят: "букиш, букиш!"
Так что нам думаю мелкие недочёты в грамматике простительны.
// Multiple Directory Authorities' keys compromise: a partial
solution for Tor clients protection. v 1.06
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 direction invarianted value in the range of [0..1], 0 – most unstable; 1 – fully stable. Finally, calculate R = (1-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" or "multistep attack" 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.
Our conjecture is "adaptive (or selective) blocking" connections is possible but don't gives a significant advantages to adversary.
Another problem for adversary is too many broken connections from mixing real and false nodes. In our another example user has a half of false nodes and another half of real ones. 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 passive 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.
Real scenario for attack is one step blocking all nodes (except false DA's), waiting of downloads false concensus from rogue DA and replace 100% of nodes keys for simulate virtual Tor network without giving any chance to user escapes from virtual Tor to real Tor.
It's possible from these 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 tools used by enthusiastic paranoids :)
Maybe this statistics and info about network status can be distributed for peer review by 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"
готово[link29]
Ясно, спасибо.
Только они както очень странно зеркалируют письма: ни на уровень выше выйти, ни проглядеть дерево всей рассылки... там вроде две ссылки всего или я что-то путаю?
На уровень выше – письма за месяц, ещё выше – список месяцев за год.
Дерево соответственно отображается только за месяц. Поскольку частота ответов за месяц невысока, то дерево не складывается. Если просматривать через почту, то рассылка выглядит стандартно со всеми деревьями.
Усредненённая статистика по cached-status за несколько дней[link30]
Исходники[link11]
Нативный линуксовый и байт-кодовый бинарники[link31]
Дальше надо собрать данные по количеству "новых" и "старых" нод.
В принципе согласуется с обычным изменением числа нод в сети.
Непохоже, чтобы кто-то подменил вам 100% узлов ;-)
Интересно было бы ещё увидеть распредление тор-узлов по их пропускной способности. Там из 2000 заявленных нод имхо большинство будет сидеть на хвосте распредления, а значит эффективное число используемых нод меньше (почти всегда только высокоскоростные узлы выбираются).
Картинка изменения числа "новых" и "старых" нод[link32]. Линии span total и span exits показывают число нод, которые были онлайн в течении последних 4 часов. Пересчитать для любого другого интервала легко – были бы файлы истории. Забавно что exit'ов практически точно половина и абсолютно повторяют динамику изменения числа всех нод. Исходные данные – сохранённые копии cached-status от одного DA взятые с интервалом 20 мин.
ЗЫ Кстати для меня было новостью что нода считается exit'ом тогда и только тогда когда её политика выхода включает два (или три) порта из трёх – 80 443 6667.
А причём тут 6667, за что он отвечает? Какой сервис?
6667 – стандартный порт IRC[link33]
Занятно. Я считал, что экзит — это узел с любой политикой, отличной от reject *:*.
Условие — тогда и только тогда, слишком сильное :) Для получения флага достаточно двух из трех, самое распространенное при такой схеме это 80 и 443 разрешенные. Однако даже запретив все эти три порта, но разрешив все остальные (например правило reject *:80, reject *:443, reject *:6667, accept *:*), узел всё равно будет Exit'ом. За подробностями — смотрите функцию exit_policy_is_general_exit(); Впрочем именно эта функция скажет что узел формально exit, даже если будет такой обман как reject *:1-65535, accept *:*
Сам по себе флаг влияет только на коэффициент при взвешивании скоростей (в пользу щадящего использования exit'ов). Клиент при выборе кандидатов на взвешивание смотрит только на полиси. К примеру если будет требоваться один 80 порт, то в число претендентов на последний узел в цепи попадет формально не Exit узел, имеющий в разрешенных единственные нужный порт.
Очень хорошая статистика. Видно появление с момента работы и стабилизация небольшой дельты между "span" и остальными нодами.
Кажется, что придумать метод постепенной селективной подмены без внесения существенных искажений в эту картину сложно, с учётом предположения о трудностях смешивания цепочек из подлинных и фальшивых узлов.
Хотелось бы, чтобы авторы это сами доказали более строго.
Другой вопрос, что метод с DA и другими централизованными доставщиками статусов сети в соответствующей литературе изначально считаетсяя недостаточно стойким (более того соответствующие исследования проводили сами разработчики TOR и они же предложили теоретически более стойкий метод получения клиентом информации о сети, скорее всего его пока невозможно реализовать практически.
К сожалению есть только упоминания об этих работах, сами их я не находил и не читал, за то что я правильно понял цитаты не ручаюсь).
Так что думаю наши изыскания их не особо удивляют. Ничего нового мы не открыли. Странно только, что среди моделей угроз сети Tor такой злоумышленник не рассматривается (умалчивается).
Русский язык пропарсить не смог :(
Да, reject'ы там вообще не учитываются. Очевидно, бага.
Ага, я именно про то что смотреть флаг exit в статистике не имеет смысла :)
Вообще говорить "сервер такой-то это exit" некорректно, правильно говорить "сервер такой-то это exit по отношению к ip:port".
Не считаю это багой. Если узел, правило для своей политики завершает accept'ом, значит он уже что-то разрешил. Он exit по отношению к неопределенной группе адресов и портов.
Данная функция рассчитана на более ограничительную политику, оканчивающуюся reject'ом. В таком случае важно проверить доступность по меньшей мере к определенной группе портов, и значительного диапазона адресов.
В случае когда узел обманно (пример в предыдущем постинге) получит флаг, он не будет выбран в действительности, ни конечным звеном (по причине полиси), ни промежуточными (его будут стараться избегать как драгоценного exit'а). Он обманет сам себя.
Как и рекомендовал unknown, задаю вопросы в этой ветке. В общих чертах алгоритм понятен, он сравнивает статистику сети, полученную от разных узлов, если статистики сильно отличаются, это считается проблемой. Так и не понял, алгоритм защитит от (захвата всех DA) + (медленного изменения статистики)?
Это скорее алгоритм голосования между DA, в результате которого получается готовый документ (консенсус, статус), отправляемый узлам сети в качестве статистики.
Если все DA коррумпированы, то они могут наголосовать что-угодно. Сами DA против собственного сговора этот алгоритм применить не могут.
Мы думали о другом алгоритме – попытке мониторить этот статус и число неудачных соединений с узлами на предмет аномалий со стороны клиента.
При медленном изменении статистики будет всплеск количества битых цепочек или постоянный откат к старой статистике по зеркалам.
Вообще алгоритм мониторинга (если бы он был создан) не защитил бы, а предупредил-бы, о чём-либо подозрительном. Точных оценок вероятности сформулировать никто не решился, так же как и доводить до ума саму идею. Разработчики тозже не проявили энтузиазма.
Да по-моему я правильно понял. Вы вычисляете величину S. Если для простоты взять N_k=N_k-1, то C=1 и S=D=I/I_max=I/N_k, где I — количество узлов, совпадающих между N_k и N_k-1.
Как вы объясняете, что атака с медленным изменением статистики не удастся. В начале все узлы являются честными, а в конце больше их половины подставные. Если злоумышленник меняет статистику постепенно, это как непрерывная функция, которая где-то должна пересечь 50% отметку на графике. Наступит момент, когда приблизительно половина узлов являются подставными. Но если половина подставные, то другая половина честные. Вы запрашиваете у честного и у подставного две статистики, и видите, что статистики отличаются на 50%, то есть S=0,5.
Но это доказательство работает, если вы получили хотя бы одну честную статистику. Тут я считаю, что никаких tor-watcher, о которых вы говорили, не существует, то есть только проверка статистики у клиента. Клиенты сверяют статистику, но любая статистика получена от DA, а список DA составляется дядей Роджером. Смысл сравнивать файлы, сгенерированные одним человеком? Никакой разницы, свидетельствующей о злых намерениях, вы там не найдёте. :-) То есть возвращаемся к тому варианту, что дядя Роджер и является глобальным наблюдателем.
Хотел бы уточнить. Если я создал middleman или exit-node, то я рано или поздно должен появиться в статистике. Вы имеете в виду, что в статистике будет указан мой IP-адрес, но не мой ключ?
В общем да. Или же меня могут вообще не включить в статистику, так ещё проще. ;-) Да, так легко проверить. Допустим, вы лично это проверили. Но есть лазейка: на каждый честный узел злоумышленник присоединяет к сети 9 подставных узлов. Так что честные узлы просто утонут. Ведь узлы — это не люди, а просто IP-адреса. Злоумышленник может купить диапазон IP-адресов, обслуживаемых одним компьютером. Что на это скажете?
Да, я оговорился. Не защитить, а предупредить.
Или по зеркалам, соединения с которыми аутентифицированы ключами со старой статистики.
постепенная подмена статистики затрудняет эмуляцию виртуальной сети tor, при смешивании реальных и подставных узлов эмулятор будет работать всё хуже из-за сбойных цепочек и есть большой шанс, что на каждом шаге пользователь соберёт и скачает реальную статистику от неподставных узлов или соединения с ними придётся разрывать?
вот насчёт этого[link34]
Допустим все DA коррумпированы вместе с Роджером впридачу. Но им надо ухитриться незаметно подсунуть конкретному пользователю левую статистику, и разместить между ним и реальной Tor-сетью эмулятор. Это возможно, но сложно и задача для прицельного, а не глобального наблюдателя. Чем большему числу людей будут раздавать левую статистику, тем больше шансов поймать Роджера за руку.
И IP и ключ, и политику прохождения трафика, и e-mail для спама если пожелаете и ещё массу служебных полей.
Ну пара человек за всё время себя не увидело, пожаловалось в рассылку. Нашли проблемы у них в настройках.
Вот вэб-парсер статистики:
xenobite[link1] – сертификат сайта самоподписанный.
Это возможно как и в любой сети вообще.
Хуже того, часть небольших узлов запущена на арендуемых виртуальных хостингах, где к ним и посторонний доступ есть, и с генераторами случайных чисел проблема...
Но пока сеть Tor не очень большая и пока плохо масштабируемая.
Здесь ошибка. Что есть "реальная статистика"? Нет никакой статистики, кроме той, которую выдают DA. В текущей архитектуре сети так, и в v2 и в v3. Я разумеется рассматривал вариант когда Роджер куплен и всё что из этого следует. В этом случае гораздо проще обманывать всех, чем одного клиента.
А если Роджер не куплен и среди DA есть хотя бы один честный, тогда я согласен, что ваш алгоритм будет обнаруживать ввод подставных узлов.
Кстати, как и голосование DA будет обнаруживать это. Может, поэтому разработчикам ваше нововведение не понравилось.
Тогда каждый владелец независимого сервера tor может заметить, что в статистике его ключ подменён. Он может ещё попросить посмотреть своих знакомых.
Кроме всего прочего каждый пользователь скачивает статистику с DA только при первом запуске, а затем собирает частями с произвольных зеркал, чтобы DA не перегружать.
Т.е. статистика не подменяется для всех, а для условно одного клиента (или выбранной группы) и не все узлы подставные, а при таком раскладе подразумевалось, что постепенная подмена будет приводить к скачиванию статистики по старым адресам зеркал, которая "не для одного", а правильная.
Или придётся заблокировать доступ резко ко всем узлам, дать скачать статистику только с DA и подменить все ключи разом, чтобы в реальную сеть пользователь не лез.
Но если долго не пользоваться программой, то никакие проверки на резкие изменения статистики конечно не помогут.
Нет, ключ не подменяется. Список узлов разбавляется подставными узлами.
Для всех подставные узлы можно и не вводить – можно действительно попытаться завести в сети много злонамеренных серверов.
А если для изолированной группы пользователей посылать статистику, сильно разбавленную фальшивыми узлами, то при контакте с реальными узлами они будут получать обратно правильную (общую для всех статистику). Будут наблюдаться изменения количества узлов в сети.
Похоже, эту особенность дизайна сети тор кардинально не исправить:
кто-то тоже спрашивает[link35].
Всех призывают верить в честность шести DA. Ответ дал пользователь arma – это ник Роджера что-ли?
Он самый. А анонимус — это не Вы, unknown? :-)
anonymous unknown или unknown anonymous! :-)
Этот Anonymous, которому отвечает arma, не до конца разобрался в вопросе. Какие собственно ключи (give your keys out) должен отдать главный разработчик? Теперь я понимаю, что unknown был прав, нет нужды подкупать DA, если можно завести много злонамеренных middleman. Этот недостаток следует из того, что вход в сеть свободный, стать middleman может каждый. А ограничить вход в сеть нельзя, потому что и так мало middleman.
I think that malicious Directory Servers should not do much harm. Proof. If you make your own tor-node, Directory Servers are *obliged* to publish your node's IP. You can check this. So at least some published tor-nodes are not malicious. This is at odds with your proposition "somebody can fake the server and publish *only* malicious tor-nodes".
A malicious Directory Server, in order to do its nasty things, should add much more (e.g. 100 times) malicious tor-nodes than there are fair tor-nodes. But a malicious man can add malicious tor-nodes without any help from a Directory Server. Because everyone can add a tor-node.
There is only one solution: to grow tor-network to such an extent that no single organization can overflow it with its malicious tor-nodes.
В начале этого топика предполагалось, что некий "человек посредине" вклинится между конкретным клиентом и завернёт весь его трафик (перехватывая на уровне маршрутизатора или ISP) в специально запущенный для него полный эмулятор сети из одних фальшивых узлов, после чего может его расшифровывать.
Народ, наверное, в курсе, но тем не менее перепощу:©[link36]. А ведь задача эмулировать Tor в принципе задача куда проще, чем эмуляция всей Сети.
Встретил Роджера на на канале #tor, irc.oftc.net.
Оказывается, такая машинка для эмитации тора уже была изобретена в 1995-2001, собственно на ней появился первый тор. Взял у Роджера интервью на плохом английском об истории тора, кому интересно, можете почитать:
Основная мысль интервью:
а в чем отличия?
"Разработанное на основе navy (используя только идею/интерфейсы, но не общий код)" versus "разработанное navy'ей".
"developed with the navy in mind" можно ещё понимать как "имея ввиду интересы navy" (нави?)
Так правильнее.
Майк Пэрри из Torproject предлагает подключиться[link37] к решению проблемы, практически в том виде, как мы её излагали (обмен статистикой между пользователями и её сверка постфактум с подписанными архивами торпроджекта — независимый аудит системы).
На данный момент созрели API для удобного снятия статистики тор-процесса и можно написать модуль контроллера на Python.
Предлагают студенту заняться на уровне GSoC :)