Простой способ атаки "в обход" 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


Комментарии
— unknown (01/08/2006 02:01)   
Небольшое исправление к пункту 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.

Все недостатки системы с корневым сертификатом здесь присутствуют. Вот только у кого он может депонироваться?
— SATtva (01/08/2006 05:42)   
Интересное исследование.

В качестве домашнего задания любителям теорий заговоров: можно ли использовать такую схему для индивидуализированной атаки на всех пользователей Tor и как долго нападающий сможет сохранять скрытность?
— unknown (01/08/2006 20:56)   
Из классификации Хирта следует, что все протоколы анонимной связи строятся на доверии к корневому сертификату.
Эта атака может быть направлена не только против Tor, но и cipherpunk, mixmaster и др. Неподвержены ей только непрактичные протоколы
типа "сети обедающих криптографов".

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

Атака злоупотребления главным секретным ключем анонимной системы идеально вписывается в теории заговоров (хотя мы высокомерно делаем вид что они нам не нравятся, но на самом деле мы падки до сенсаций :-). Создается анонимная сеть, изначально финансируемая военным ведомством (DARPA), учёные делают свою работу даже ни о чём не подозревая, располагая серверы в университетских лабораториях, откуда "люди неприметной внешности" крадут сертификаты.

Пользователи получают чистые исходники и формально стойкий протокол. Дальше "незаконные" владельцы сертификата могут снимать траффик отдельных пользователей.

Мэллори должен потрудиться, чтобы создать виртуальную машину, загружающую реальные ключи узлов tor'a и полностью имитирующую фальшивую сеть tor внутри себя, но состоящую из фальшивых ключей и статистики из которой он получит открытый текст и завернёт в настоящий tor. Пакеты и на выходе для Боба и возвращаемые обратно Алисе должны быть подправлены так, чтобы не было никаких изменений в их полях (TTL и др.), чтобы не было заметно, что пакеты обрабатывались (если Алиса вдруг попытается их анализировать). То же он может проделать с mixminion, в mixmaster пользователи вообще скачивают никем не заверенные ключи откуда попало.

Это несложно. Возможно кто-то в рамках небольшой сети даже сможет написать программную реализацию и провести эксперимент.

Алиса может заподозрить неладное, если она переключится на другой интернет-канал или ни с того ни сего войдёт в tor через неизвестный для Мэллори VPN. Тогда он отключит свою машинку и подозрение вызовет только то, что статистика поменялась. Но tor и так часто меняет статистику при смене IP адреса. Сравнивать же весь набор ключей на предмет того, как они меняются при переключении на разные соединения Алиса конечно может, но Мэллори тоже не дурак. Он на время отключит свою адскую машинку, подождёт пока Алиса успокоится и начнёт искать подходы ко всем её интернет-каналам, чтобы поставить аппаратуру и там.

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

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

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

Даже если случайно злоумышленник будет пойман, разработчики всегда могут развести руками и сказать, что они делали всё честно, а к краже ключа непричастны, сохранив свою репутацию. Протокол и код не содержат закладок, а начёт доверия к Root CA, ну скажут, что это же и так в соответствующих работах описано, эта такая глобальная проблема, которая в настоящее время не решена.
— SATtva (01/08/2006 22:19)   
Правда если пользователей будет очень много, то машина не потянет затраты на криптооперации по процессорному времени и памяти. Но можно сделать дешифрующий кластер. Можно от многих крупных провайдеров проложить прямые линии в единый центр прослушивания коммуникаций, это не совсем глобально, но близко к тому.

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

Что касается самой проблемы, она, на мой взгляд, чем-то напоминает известную статью, Trust Reflecting Trust (название могу путать, но вы наверняка понимаете, о чём), — такая же максима. Мы можем располагать открытым исходным кодом, и, не доверяя разработчикам, провести его аудит. Но откуда у нас уверенность в компиляторе? Даже если и компилятор собирался из исходников, то с применением другого компилятора, ничуть не более доверяемого.

Продолжать можно бесконечно, а поэтому на каком-то этапе важно остановиться, основываясь, возможно, на интуиции или каких-то других неэмпирических сдерживающих факторах. Это вопрос доверия уже скорее философского, а не криптографического. Впрочем, на этот вопрос каждый себе отвечает сам...
— unknown (02/08/2006 20:26)   

Не вижу причин, почему нельзя сделать такую схему распределённой по аналогии с нашим СОРМ.


Ну это уже получитя тот самый глобальный наблюдатель, защиты от которого нет, как честно говорили разработчики.
— spinore (03/08/2006 11:32)   
Да, очень интересно, unknown :)
Тем не менее, хоть многие и доверяют тор, но если я был бы уверен, что за мной следят, я бы не довольствовался одним тором точно. Легко можно водрузить проксю до или после тора. Тогда окромя ордера на прослушивание нужно будет ещё догавариваться с абстрактными странами о том, что они должны выдать логи и т.д. + для критических вещей надоне забывать об end-to-end gpg, с проверкой фингерпринтов по независимым каналам. Если коротко: я завожу себе впн в отфонарной стране и лезу в тор с того впн. Пока такие адские машинки не будут установлены на большинстве серверов мира об атаке можно будет забыть. К тому же в силу текучести информации, данную прослушивающую систему будет сложно претворять на практике и применять для многих пользователей так, чтоб никто не знал о самом существовании данной системы. К тому же, прийдётся писать специальную программу для каждой из анонимизирующих сетей. Идеальным выходом из ситуации является квантовый канал с асимметричным шифрованием. Тогда слушать просто будет нельзя :) (или по кр. мере существенно сложнее). + нужно не забывать об массовости. Чем болше пользователей и траффик, тем сложнее следить и т.д.
— SATtva (03/08/2006 12:04)   
Даже если случайно злоумышленник будет пойман, разработчики всегда могут развести руками и сказать, что они делали всё честно, а к краже ключа непричастны, сохранив свою репутацию. Протокол и код не содержат закладок, а начёт доверия к Root CA, ну скажут, что это же и так в соответствующих работах описано, эта такая глобальная проблема, которая в настоящее время не решена.

Они ведь честно предупреждали: "This is experimental software. Do not rely on it for strong anonymity."
— unknown (05/08/2006 01:26)   
Они всё отрицают

http://archives.seul.org/or/talk/Aug-2006/msg00042.html

Но мне кажется, что всё равно эта атака сработает, наверно не так просто и примитивно, как я описал
— SATtva (05/08/2006 09:09)   
Они всё отрицают

Заговор молчания? Мне кажется, комментарии других участников дискуссионной группы тоже были удалены на этапе модерации.
— unknown (05/08/2006 16:24)   


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



Ну не всё так просто.

Кое что прояснилось. В таком виде "атака на тор" невозможна.

На основе поверхностных знаний Onion Routing протокола я сделал неверный вывод и поспешил поделиться им с разработчиками.
Зато сэкономил время, которого признаюсь у меня было мало для более глубокого изучения вопроса.

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

Для меня ещё кажется туманным вопрос, что если серверов директорий немного, то как происходит официальная процедура включения их публичных ключей в программу? Или отзыв скомпрометированных ключей? Не могут ли они все быть (или стать) подконтрольными кому-либо? (Разработчики считают защиту от такой угрозы нереальной). Работает ли распределённая модель доверия в таком ограниченном объёме?

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

А со своей стороны вопрос считаю пока закрытым. Разоблачить заговор ЦРУ или АНБ не удалось ;-)
Гость (22/12/2007 23:33)   
Серверы директории тоже независимы, разработчики включают в программу только их публичные ключи, а программа признаёт статистику верной, только если получит подтверждений более чем от половины серверов.

Серверы директории – это что-то типа master-нод? Сколько их кстати? И как они соотносятся с корневыми нодами?
У меня сразу проскользнула мысль, что, возможно, имело бы смысл включать в программу публичные ключи всех серверов тора (ну или сертификаты, если угодно). Поскольку цепочки строятся клиентом независимо, Мэллори сможет устроить атаку только за счёт преобладающего числа подконтрольных ей мод, в противном случае ничего не получится, так как они не могут иметь публичные ключи все нод.

Серверы директории тоже независимы

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

P. S.: есть небольшой позитив: раз
  • До сих пор не известно достоверное ни об одном случае, когда кого-то вычислили из-под тора.
  • Планируют запретить анонимные системы в Германии, а потом и во всей европе (ссылка пробегала) => не могут иначе, видимо, справиться.
  • Когда всё-таки начинали расследования, изымали эксит-ноды а не тех кто что-то через них посылал.
Значит, возможно, не всё так плохо... Единственная надежда.
Гость (23/12/2007 02:47)   
И вобще, имхо не вредно было бы где-нить на сайте увидеть обзор всех возможных атак на tor.
— SATtva (23/12/2007 16:30)   
Серверы директории – это что-то типа master-нод? ... И как они соотносятся с корневыми нодами?

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

Сколько их кстати?

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

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

Неудачная мысль. Тогда для запуска каждого нового узла придётся выпускать новую версию программы. А ещё у оператор узла может рухнуть машина и лишить его ключа узла — опять придётся выпускать новую версию. Можно привести дюжину таких примеров.

И вобще, имхо не вредно было бы где-нить на сайте увидеть обзор всех возможных атак на tor.

http://www.freehaven.net/anonbib/
— unknown (23/12/2007 17:29)   
Когда запускали сеть, то сервер корневой директории действительно был кажется только один или несколько,
но все принадлежали разработчикам, поэтому у меня и осталось такое представление.

Сейчас, теоретически каждый желающий может запустить такой сервер.

Но, то ли желающих нашлось немного, то ли разработчики удостоили этой чести только себя и ещё кого-то,
но в файле статистики можно наблюдать только семь строчек:




Можете проверить здесь[link1], только большая страница может сделать браузер на время задумчивым.
про причину ругательства браузера на сертификат можете почитать на главной.

Из них два висят на одном IP адресе и, по крайней мере четыре из семи, связаны с разработчиками.
Так что тогда означает их фраза, что если половина директорий скомпрометирована, то игра окончена:



Instead we need to assume that Mallory compromises more than half of
the directory authority keys here. That's not something we try to
defend against, except by trying to make it harder to do: we assume
that if more than half of the authorites are compromised, we lose.



Ну и это я или не понял (я допускаю, что скорее всего так и есть) или это демагогия:



There are multiple directory authorities. Clients have
the public keys for all of them. No directory authority is trusted
completely: clients only believe a statement that is made by more than
half of the authorities.



Неполные 7 – это что, multiply, множество великое?

Вот что они пишут в спецификации, которую отослали почитать:



1. Directories were very large and use up a lot of bandwidth: clients
downloaded descriptors for all router several times an hour.
  • 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.
  • Our current "verified server" system is kind of nonsensical.

        1. Getting more directory authorities would add more points of failure
          and worsen possible partitioning attacks.

    There are two problems that remain unaddressed by this design.
      1. Requiring every client to know about every router won't scale.
      2. Requiring every directory cache to know every router won't scale.

    We attempt to fix 1-4 here, and to build a solution that will work when we
    figure out an answer for 5. We haven't thought at all about what to do
    about 6.



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

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


    Далее, по тексту:



    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.

    Routers periodically upload signed "descriptors" to the directory
    authorities describing their keys, capabilities, and other information.
    Routers may act as directory mirrors (also called "caches"), to reduce
    load on the directory authorities. They announce this in their
    descriptors.

    Each directory authority periodically generates and signs a compact
    "network status" document that lists that authority's view of the current
    descriptors and status for known routers, but which does not include the
    descriptors themselves.



    Со стороны клиента как работает тоже много написано, но естественно:



    When a client has no live network-status documents, it downloads
    network-status documents from a randomly chosen authority. In all other
    cases, the client downloads from mirrors randomly chosen from among those
    believed to be V2 directory servers. (This information comes from the
    network-status documents; see 6 below.



    Я не буду цитировать всё, там ещё много деталей и можете сами прочитать или на сайте
    или локально в консоли:




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




    * До сих пор не известно достоверное ни об одном случае, когда кого-то вычислили из-под тора.



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



      • Планируют запретить анонимные системы в Германии, а потом и во всей европе (ссылка пробегала) => не могут иначе, видимо, справиться.



    Ну, массово следить за пользователями они мешают, но вполне возможно что с особо вредными пользователями справиться могут.



      • Когда всё-таки начинали расследования, изымали эксит-ноды а не тех кто что-то через них посылал.



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



    Значит, возможно, не всё так плохо... Единственная надежда.



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

    Но тогда немцы бы узнали, что шифр Энигмы взломан.
    А несколько сотен тысяч жизней в военное время небольшая тактическая потеря
    в стратегических играх военных и политиков.

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

    И нравится ли это немецому правительству (или лоббистам от определённых ведомств),
    которое давно пытается освободиться от американского влияния, ещё со времён
    той самой Второй Мировой и которое использует криптографические проекты как разменную монету в своих попытках
    показать фигу Америке (то профинансируют GnuPG для борьбы с эшелоном, который используется для экономического
    шпионажа в пользу США, то на tor наедет, не раскрывая своих далеко идущих политических замыслов).

    На самом деле, лучше уделить внимание чисто технической стороне вопроса, а конспирология только уводит
    в пустоту и не даёт получить никакого реального знания. Никаких конретных фактов для позитивных выводов пока нет,
    так же как и для негативных.
    — unknown (23/12/2007 18:08)   

    1. Directories were very large and use up a lot of bandwidth:


    Цитата с перечислением пунктов неправильно отформатировалась из-за их автонумерации :-(
    — soot (23/12/2007 18:08)   

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


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

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

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

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

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

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

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

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

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


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

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



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

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

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

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

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

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

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

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


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


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


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

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

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


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


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


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

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

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

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

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

    StopClientIfTooMuchKeysChanged

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

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


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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

    Но это всё так... в далёком будущем и в перспективе :)
    Гость (24/12/2007 23:47)   
    Последние пункты следует читать так (опечатался):
    • числа изменившихся ключей со времени последней принятой статистики
    • числа новых нод, появившихся со времени последней принятой статистики
    • числа DA, которые подтвердили предложенную статистику
    • общего числа DA с помощью которых пытались получить статистику
    • числа DA, которые отвергли предложенную статистику
    • числа DA, ответ от которых по неясным причинам получить неудалось
    • времени, прошедшего со времени последней принятой статистики
    • степени паранойи пользователя
    Гость (24/12/2007 23:54)   
    SATtva
    Ключи DA намертво вшиты в клиентскую программу, дистрибутивы которой заверяются в помощью PGP.

    Это да, но здесь наполовину идёт речь о том чтобы изменить протокол :( Когда DA будет много, а степень доверия к ним будет разная, включать их все в программу не будут точно так же как сейчас не включают сертификаты всевозможных CA (очень точная аналогия), но... по желанию вы модете выбрать те DA (CA), которым доверяете, и впоследствии доверять только тем сертификатам которые подписаны не менее чем N различными DA (CA).
    Гость (24/12/2007 23:56)   
    s/как сейчас не включают сертификаты всевозможных CA/как сейчас не включают сертификаты всевозможных CA в браузер/
    Гость (25/12/2007 00:02)   
    soot
    Вероятно в текущем дизайне Tor, утрата большей части секретных ключей DA, считается необратимой катастрофой и все попытки опираться на информацию с оставшихся не подконтрольными DA не имеют смысла.

    Следует понять почему нельзя доработать протокол до того что я предложил, и понять, даст ли это в итоге интегральное преимущество, и если нет – то почему (хотя бы примерно). Аргумент, что пользователям так много удобнее и "можно ни о чём не думать" не будет веским аргументом... для таких можно предложить какие-то умолчальные настройки по аналогии с умолчальными CA, встроенными в стандартные браузеры + дефолтные настройки барузеров.
    Здесь tor-клиент = браузер достаточно точная аналогия.
    Гость (25/12/2007 00:09)   
    SATtva
    Ещё где-то видел софт для визуализации цепочек, которые строит клиент tor'а

    Vidalia.

    А если я не доверяю в полной мере Vidalia и предпочитаю что-то более близкое к ручному, нет ли альтернативы? Просто браузинг по инету в любом случае будет происходить без видалии... а потом ставить и разбираться с ней только ради этого не хочется.
    P. S.: писать самому срикпт для визуализации цепочек не предлагать :)
    — unknown (25/12/2007 00:21)   
    Это всё уже лучше, но...

    Вот SATtva уже нашёл существенную неточность формулировки:
    сообщение не о том, что ключи DA поменялись (это абсурд – программа отвергнет их подписи),
    а сообщение о событии, гласящее как минимум о том, что:

    a) Почему то возможно скачать статистику только с DA – со всех других узлов или всё заблокировано,
    или приходит что-то устаревшее или неверное.
    b) Резко поменялись все или большая часть данных, подписываемых DA.

    Всё это внятно формулируем по-русски, а уже затем пишем сообщение разработчикам на читабельном английском,
    если будет ещё пара таких ляпов или неясный текст, то они не будут это читать до конца и вникать в наши предложения.

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

    Короче не стоит торопиться и второй раз морочить им голову плохо читаемой белибердой в моём исполнении :-)

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

    Все замороки с настройкой эвристик и доверия к сертификатам по умолчанию будут наверняка выключены и идти только
    как advanced options, захотят ли разработчики таких сложностей, когда есть более прозаические задачи?

    На самом деле, не до конца ясны возможные сценарии атаки, например Мэллори может используя фальшивые ключи DA
    подписать левую статистику, в которой часть ключей серверов тора будет верной, но симулировать, перехватывая IP,
    что они всегда в оффлайне или отказывают в соединении, если они входящие. Или не давать строить через них цепочки,
    если они middle или exit. Т.е. банить те входящие узлы (а это просто, так как теперь есть guard'ы), у которых верные ключи
    и давать на основе левой статистики возможность выбора только ущербных для пользователя (подконтрольных) цепочек.

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

    Кстати, невидимый spinore, – вот Вамприходилось уже чистить кэш, потому что вас в торе "забанили", Вы проверяли что после этого
    Вам пришло в качестве новой статистики?
    Гость (25/12/2007 00:41)   
    А если я не доверяю в полной мере Vidalia и предпочитаю что-то более близкое к ручному...

    можно воспользоваться tork, точнее его исходником, или почитать спецификации протокола управления Tor'a и получать всё нужное по telnet.
    Гость (25/12/2007 01:36)   
    Всё это внятно формулируем по-русски, а уже затем пишем сообщение разработчикам на читабельном английском

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

    Это "простая" атака только для очень "непростого" злоумышленника

    Мне кажется, что здесь основная "непростота" кроется исключительно в том, что злоумышленник имеет право ставить оборудование на стороне провайдера. Однако, тор итак разрабатывается с учётом угрозы со стороны не "Васи с соседнего стола", а более серьёзной...

    Не забываем о том, что tor стараются сделать максимально прозрачным, простым для неподготовленных пользователей, автоматизированным

    Где-то пробегал принцип о том, что реальная безопасность не может быть "автоматизированной, простой и элементарной для неподготовленных пользователей". Я к тому, что всё отличие между простыми пользователями и теми, кто будет использовать advanced options, будет на уровне клиента... со стороны всё будет выглядеть примерно одинаково.

    Все замороки с настройкой эвристик и доверия к сертификатам по умолчанию будут наверняка выключены и идти только как advanced options, захотят ли разработчики таких сложностей, когда есть более прозаические задачи?

    Какие, например?

    На самом деле, не до конца ясны возможные сценарии атаки, например Мэллори может используя фальшивые ключи DA подписать левую статистику, в которой часть ключей серверов тора будет верной, но симулировать, перехватывая IP, что они всегда в оффлайне или отказывают в соединении, если они входящие. Или не давать строить через них цепочки,
    если они middle или exit. Т.е. банить те входящие узлы (а это просто, так как теперь есть guard'ы), у которых верные ключи и давать на основе левой статистики возможность выбора только ущербных для пользователя (подконтрольных) цепочек.

    Это тот случай, когда следует прибегнуть к формальной логике. Указанные здесь вами атаки применимы "на ура" и к текущему протоколу тора, а предлагаемая схема усложнит их проведение, и этот факт снимает поставленный вопрос. Разговор о конструировании ещё более идеального случая от защиты от подобных атак – это уже второй шаг...

    Кстати, невидимый spinore,? Вот Вам приходилось уже чистить кэш, потому что вас в торе "забанили", Вы проверяли что после этого Вам пришло в качестве новой статистики?

    Нет, не проверял :( Более того, могу сказать что меня удивляет некоторые моменты в поведении тора (возможно, я параноик, да).
    • В этом топике[link2] среди прочего в логе проскакивала строчка:

    которая была зело длинной с подобной абракодаброй. Мне кажется, что подобное происходило не раз, а указанный IP был тем же (гарантий нет, не помню).
    • При перестройке цепочек (может у нас так мало экситов?!) у меня чередовались IP из набора, как правило, 5ти штук. С течением времени они могли меняться. Мне бросилось в глаза что это постоянно были либо FR, либо DE, реже US, остальные страны – вообще редко.
    Порой хочется визуализировать всю полученную статистику и видеть какой выбор предоставлен и что из всего этого выбирает клиент. Я всё могу понять, но если иногда доходит до того что не меняет экзит, то значит их действительно "мало" (!) либо выбор "странный". Всё это меня и смущает...
    Разумеется, когда я кэш стёр, против меня можно было нахаляву провести описываемую атаку :)

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

    Ещё есть вот какая идея, по сути ваша же, но чуть доработанная :)
    Предположим, что никто ни у кого серт не одалживал (не крал). Провайдер может закрыть доступ ко всем ентренс-нодам (точкам входа), которые не подконтрольны противнику. Тор будет попытается построить цепочки через них и у него ничего не получится, а вот через подконтрольные – получится. Далее есть 2 варианта:
    • Если некоторые нода забанены только на стороне провайдера, противник, заставляя строить тор-клиента цепочки через более ограниченное число узлов, может тем самым упростить себе проведение дальнейшей атаки по корреляции траффика.
    • Если некоторые ноды забанены на всех файерволлах (например, со стороны их провайдеров), то получаем практически вышеопсанную атаку unknown'а когда тор-клиент вынужден использовать цепочки, состоящие исключительно из подконтрольных противнику узлов.
    — ntldr (25/12/2007 02:14, исправлен 25/12/2007 02:15)   

    Я тоже неоднократно замечал подобное. Такое ощущение что во всей сети есть всего лишь десяток ексит узлов.
    — SATtva (25/12/2007 09:56)   
    Всё это внятно формулируем по-русски, а уже затем пишем сообщение разработчикам на читабельном английском,

    Только писать не в or-talk, а на or-dev.
    — soot (25/12/2007 12:36)   
    Темы про "ограниченное" число выходящих узлов постоянно возвращаются. Указаные "ограниченные" страны экзитов и составляют костяк группировки узлов, что есть то и выбирается. Не стоит забывать что выходящие узлы для трансляции во вне Tor применяют политику выхода (известную клиенту). Кроме того, клиент хранит историю (в пределах часа) по запрошенным ранее портам, для предупреждающего строительства цепочек. Таким образом клиент который серфит веб и читает почту, будет иметь меньшее число выходящих узлов для выбора при строительстве (предупреждающем) новых цепочек, чем клиент просто серфящий веб.

    Алгоритм выбора такой что вероятностно будут выбираться чаще те узлы, чья скорость выше. Пример: Допустим за час работы, при заданной скорости смены цепочек раз в десять минуты (то есть всего 6 цепочек), вероятность заполучить один (из двух) достаточно скоростной узел в том же звене цепи (например 1МБ/c) дважды, трижды,... шесть раз, выше чем узел со скромными возможностями (например 100КБ/c). В действительности их больше чем два, и даже при двух, вероятность выбрать низкоскоростной узел остается. Такой алгоритм используется и для промежуточных и при отборе входящих охранных узлов (последние запоминаются и по возможности используются в дальнейшем). Плюс добавлен в алгоритм учёт длины цепочки. И в результате узел заявивший например 20КБ/c и будет выбираться пропорциональное его скорости число раз (в действительности очень редко) многотысячной армией клиентов и не будет причиной, теперь уже топиков про скорость. И если бы не качки терабайтов через Tor, искажающие картину, было бы всё совсем идеально.

    Если хочется попробывать как это — когда совсем не взвешиваются скорости, можете попробывать исправить код и собрать (сохраните оригинал, наверняка на него вернётесь):



    на код:



    Такие же строчки можно найти для выбора промежуточных узлов. Поиск файла и строки и эти исправления, доверяю вам.
    — unknown (25/12/2007 21:44, исправлен 26/12/2007 00:08)   

    Где-то пробегал принцип о том, что реальная безопасность не может быть "автоматизированной, простой и элементарной для неподготовленных пользователей".


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


    захотят ли разработчики таких сложностей, когда есть более прозаические задачи?
    Какие, например?


    Борьба за расширяемость (scalability). Борьба с Великим Китайским и прочими возможными файрволлами с помощью бриджей.
    Вероятно и над немецкой проблемой разработчики тоже думают, что предложить операторам кроме middleman'ов.
    Просто пока ждут что будет после вступления закона в силу, чтобы не торопить события.

    Ну и слишком усложнять протокол тоже не следует. Туда уже и так много всего сложного добавили.

    Думаю, идею с фактически новым протоколом, с опциональными DA пока стоит запомнить, но отложить на будущее.

    остановимся на самом простом: введением опции для блокирования атаки... эээ (объявляется конкурс на самое
    красивое название атаки, "unknown attack" – не катит :-). М.б. "Multiple Directory Authority keys compromising attack".


    Только писать не в or-talk, а на or-dev


    правильно, там будет самое место.

    Поскольку, кроме 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.
    (suspicious for fake DA IP interception, authentificated with stolen keys).

    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"
    — unknown (25/12/2007 23:57)   
    Кстати, похоже разработчики думают вперёд нас,
    возможно у них ещё много чего запланировано в новых фичах:



    Tor 0.2.0.13-alpha is out

    Tor 0.2.0.13-alpha adds a fourth v3 directory authority run by Geoff
    Goodell, fixes many more bugs, and adds a lot of infrastructure for
    upcoming features.

    – Three new config options (AlternateDirAuthority,
    AlternateBridgeAuthority, and AlternateHSAuthority) that let the
    user selectively replace the default directory authorities by type,
    rather than the all-or-nothing replacement that DirServer offers.



    Гость (26/12/2007 02:11)   
    А если я не доверяю в полной мере Vidalia и предпочитаю что-то более близкое к ручному, нет ли альтернативы?
    Tor прекрасно работает сам по себе, без всякой видалии и телнет-управления. :)
    Гость (26/12/2007 09:11)   
    Вероятно и над немецкой проблемой разработчики тоже думают, что предложить операторам кроме middleman'ов.

    Насколько я помню закон запрещает все анонимные сети. Почему промежуточные узлы тора сюда не относится?

    М.б. "Multiple Directory Authority keys compromising attack".

    tor-simulation attack? (атака симуляции тор-сети)
    Термин зависит от того что нужно подчеркнуть: что ключи DA "позаимствовали" или тор-сеть эмулируют?

    Поскольку, кроме SATtv'ы все подписываются псевдонимами или только ключами, письмо отправляем только как коллективную анонимку от нашего сайта.

    Мой ник (spinore), ключ и ФИО всем известны, но
    • не я один принимал участие в разработке идеи
    • перемешивать сущности в одном пиьме – тоже не в плюс
    так что ваш вариант, по-моему, самый оптимальный.

    we have really small set of semi-trusted authority

    authorities

    more than half of it

    its

    owners of this servers

    these

    and free from any third party evil influence

    and keep them free from any third party evil influence

    Key security and trust problem improved

    Key security and trust problem are improved

    If third party agent Mallory have

    If the third party agent Mallory has

    and have an ISP level acces

    and has an ISP level acces

    relative "fresh" stats

    relatively "fresh" stats вроде бы

    If stats downloading from all of mirrors blocked or have invalid signatures and may be download only from semi-trusted DA.

    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.
    (После исправления опечаток я бы переделал так).

    suspicious for fake DA IP interception, authentificated with stolen keys

    This case rises a suspicion about DA's IP interception authentificated with stolen keys
    (Я бы написал так, но запятую перед authentificated уберите немедленно, это не русский язык. В английском запятая в этом месте эффективно играет роль начала нового предложения).

    Keys for tor nodes signed with DA changed significant (> 90% of all keys for example) in a very short interval of time

    Tor-nodes keys signed by DA are changed significantly (for example, >90% of all keys) during very short time interval.

    suspicious for fake stats injection for user cache

    This case rises a suspicion about fake stats injection for user cache.

    How much keys it can be? How short interval?

    How MANY keys have to be affected by this attack to rise a suspicion?
    What's the minimal time per change?

    Any other criteria of suspicious activity? Formal model for other possible attacks detection for tor clients?

    What's about other criteria of suspicious activity or formal model of other possible attacks detection for tor clients?

    After detect this type of activity tor client can log message:

    We offer the next log messages for tor client as indication of attack involved:
    (Лучше так)

    Warning! Very significant part of tor nodes keys changed in a short interval of time!

    Warning: a lot of tor-nodes keys were changed during a short time interval!

    If more then half of Directory Authority keys compromised, stats may be poisoned with a fake data.

    If more than one half of Directory Authoritiy keys are compromised, stats can be poisoned with a fake data.

    Paranoidal settings for users in config file (client only section) may be:
    StopTorIfTooMuchKeysChanged 0|1

    As a paranoidal option listed in config file (client-only section) one can use
    StopTorIfTooMANYKeysChanged 0|1
    P. S.: Товарищ unknown, исчисляемые: many, а неисчисляемые: much. Если не влазить в тонкости, мой вам совет: забудьте про употребление слова may в научно-технической литературе...

    Other open questions: only stop tor if user enables this setting and log suspicious event or do any other way to interaction?

    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 measures user can makes after that message?

    What are the right things to do for the users who get that evil log event?
    (Ну типа английская фраза не есть русская с заменёнными словами, т.е. часто буквальный перевод невозможен либо звучит не по-английски). Кстати, make – это обычно "делать" в смысле конструировать, создавать.

    How to do with users with long period of inactive cache?

    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?

    We have a long discussion and more noncompleted ideas on our site.

    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"

    "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.
    Гость (26/12/2007 09:40)   
    s/and has an ISP level acces/and has an ISP level access/

    Tor прекрасно работает сам по себе, без всякой видалии и телнет-управления. :)

    Здесь не о том речь, чтобы работал, а о том чтобы функционировал надлежащим образом.

    Кстати, похоже разработчики думают вперёд нас, возможно у них ещё много чего запланировано в новых фичах:

    Да, интересно, но в любом случае надо написать: сообщение в talk, думаю, пойдёт только на пользу (и им и нам).

    Темы про "ограниченное" число выходящих узлов постоянно возвращаются. Указаные "ограниченные" страны экзитов и составляют костяк группировки узлов, что есть то и выбирается. Не стоит забывать что выходящие узлы для трансляции во вне Tor применяют политику выхода (известную клиенту).

    Я человек тупой и кондовый, а потому прежде всего смотрю на факты. Года 2 назад я чётко помню, как экзиты путём посылки сигнала -1 тор-клиенту менялись как перчатки, при этом тор функционировал достаточно шустро. Видимо, ключевое отличие, если атаки не происходит, лишь в увеличении отношения "число_нод/число_тор-юзеров."

    Плюс добавлен в алгоритм учёт длины цепочки.

    Раньше её нельзя было варьировать, сейчас что-то поменялось? И в каких пределах можно менять?

    Если хочется попробывать как это? Когда совсем не взвешиваются скорости, можете попробывать исправить код и собрать (сохраните оригинал, наверняка на него вернётесь)

    Кстати, это повысит анонимность?
    Гость (26/12/2007 09:44)   
    s/лишь в увеличении отношения/лишь в уменьшении отношения/
    — soot (26/12/2007 13:54)   

    Года 2 назад я чётко помню, как экзиты путём посылки сигнала -1 тор-клиенту менялись как перчатки, при этом тор функционировал достаточно шустро.


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

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


    Раньше её нельзя было варьировать, сейчас что-то поменялось? И в каких пределах можно менять?


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


    Кстати, это повысит анонимность?


    Вероятно нет, скорее понизит, изменения в алгоритме выбора выделяют такого клиента из общей массы. Вопрос только кто сможет это заметить (не считая глобального наблюдателя, но ему и так всё ясно).
    — SATtva (26/12/2007 14:05)   
    Уж извините, господа, но нельзя же так засирать дискуссию. Spinore, потрудитесь хотя бы скомпилировать свои правки в единый текст, а то в таком виде даже читать не хочется, ей богу!
    — unknown (26/12/2007 15:02)   

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



    PPS: Под конец понял что проще было переписать с начала до конца и запостить сюда.


    Не проще и не надо. Так всё сразу видно где ляпы и почему. И время экономится.

    SATtva, у меня претензий нет.
    Вроде так наоборот лучше понять, почему что-то требует исправления. Если бы было время, то открыл бы Вики-страницу с черновиком, но работа над ней отнимает гораздо больше времени. Нужно открывать и форматировать кучу страниц, ждать пока они загрузятся, после каждой правки проверять как они выглядят. Неудивительно, что вся разработка вообще консервативным способом обычно идёт в рассылках, а не форумах даже.

    Для подготовки короткого письма, чтобы исправить только ляпы и безграмотность, достаточно кидать все замечания прямо в тему.
    Пока все предложенные исправления подходят и будут включены в таком виде. Жду ещё поправок, раскиданных по теме как кому нравится, в пределах разумного. Если других замечаний нет, то ещё раз пишу окончательную версию письма и можно будет его отправлять.
    Гость (26/12/2007 15:25)   
    Уж извините, господа, но нельзя же так засирать дискуссию. Spinore, потрудитесь хотя бы скомпилировать свои правки в единый текст, а то в таком виде даже читать не хочется, ей богу!

    Так там правки к правкам :) Отослал – увидел опечатку, а как исправить? Только ещё один комментарий писать. Я итак стараюсь не плодить лишних сообщений – всё включить в одно... но порой они столь длинные, что я боюсь что браузер сглючит, потому лучше отправить что есть и не рисковать.

    Жду ещё поправок

    У меня таковых вроде бы больше нет.
    — unknown (26/12/2007 15:46)   
    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.
    (This case rises a suspicion about DA's IP interception authentificated with stolen keys).

    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"
    Гость (26/12/2007 15:58)   
    simulation attack?

    Атака виртуализацией? (Tor для этого[link3] необязателен.)
    — SATtva (26/12/2007 16:06, исправлен 26/12/2007 16:16)   

    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 of 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 ["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, тоже мой горячий привет.
    Гость (26/12/2007 16:15)   
    Tor прекрасно работает сам по себе, без всякой видалии и телнет-управления. :)


    Здесь не о том речь, чтобы работал, а о том чтобы функционировал надлежащим образом.

    А что ненадлежащего делает (или не делает надлежащего) Tor без Vidalia?
    Гость (26/12/2007 19:23)   
    Tor прекрасно работает сам по себе, без всякой видалии и телнет-управления. :)

    речь идет о получении пользователем по его запросу информации о цепочках (текущих) от демона (системного) тора и дальнейшей обработки этой инфы. Vidalia & Tork в данном случае делают сие "из каропки" автоматом. А как это проделать в ручную – надо читать спеки.
    — unknown (26/12/2007 20:20)   
    Кстати, s/mashine or claster/machine or cluster//g

    Но раз SATtva вообще предлагает эту фразу выкинуть, то можно и выкинуть. Лишний раз навязчиво убеждать, что это атака реальна не стоит.

    Для атаки виртуализацией tor нужен, чтобы после дешифровки траффик проходил через реальный tor и Алиса могла бы видеть ответы на exit-node IP через https.
    — soot (26/12/2007 23:33)   
    Допустим всё верно, сравнение будет полезным инструментом при кешированной Алисе, и упорном Мэллори (запрет всех кроме своих узлов для клиента и так далее, включая учет туннелированных запросов клиента к произвольным кеш-директориям с заворотом), всё таки будет внедрена фальшивая статистика. При этом Алиса конечно должна быть очень терпеливой (а скачивая статусы через готовые цепочки, в n раз терпеливой). И не факт что большая часть пользователей не предпочтет, после 10-и минутного ожидания вообще всё переставить, или почистит кешированные документы, с итоговой нулевой полезностью новой функции.

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

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

    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."


    Мы знаем что так было. Сейчас нет. В текущий момент одиночная DA не может обмануть клиента ни на секунду. Впрочем и "открыть" ему глаза на подделку данных с большинства других DA, тоже не сможет. Менее половины списочного состава DA могут вообще "Войну и мир" в документы со статусами записывать, и при правильных диалогах персонажей, клиент не обратит на это своего внимания :)
    — unknown (27/12/2007 00:28)   
    Угу и они каждую новую спецификацию начинают с цитаты этой старой проблемы, затем пишут как они это решили, но не до конца.

    Предлагаю тогда убрать для нашего письма цитату из спецификации вообще (они свою спецификацию наизусть и так помнят) и вместо неё придумать убедительный абзац:

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

    Ну и дальше, как у нас и написано, что типа в курсе мы про V.3 протокол, но проблема большинства там остаётся.

    TunnelDirConns не сработает, если всё заблокируют кроме DA или испортят все другие коннекты битыми аутентификациями, то туннелиться будет не через что.

    StrictEntryNodes – Пусть ответят, это параллельная и дополняющая мера. Ни одним из возможных способов полностью решить проблему всё-равно нельзя.
    — SATtva (27/12/2007 14:12)   
    "Основа проблемы в небольшом числе корневых нод и необходимости доверия к ним. Несмотря на сравнения подписанных данных, поступающих от разных DA, при наличии у злоумышленника закрытых ключей более чем от половины DA, он может производить различные атаки".

    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.
    Гость (27/12/2007 16:01)   
    owners of these servers really protects their server keys

    protect так как множественное число

    he still can makes a MITM-based virtual network simulation

    can make так как после can идёт инфинитив

    may implement an analysis for suspicious activity

    can implement, ибо tor-client... да ещё и may... не... слишком большая честь. Я вам уже написал выше: на данном уровне познания английского в научно-технических текстах, включая компьютерную тематику, забудьте про may. Если вам нужно подчеркнуть смысл "делать с позволения" то пишите allowed. Ну в конце концов... есть понятие стиля речи. (Пример: в официальном стиле речи пишут "здесь", а ещё лучше "в расссматриваемом случае" вместо "тут", так же и здесь...).

    How MANY keys have to be

    Я написал большими буквами чтоб вы запомнили а не для официального текста!
    s/MANY/many/

    P. S. Вашей шифровальщице, spinore, тоже мой горячий привет.

    an opponent controlling more than half of DAs' keys are able

    an opponent is able
    И вашей шифровальщице тоже низкий поклон! "1:1"

    Впрочем и "открыть" ему глаза на подделку данных с большинства других DA, тоже не сможет. Менее половины списочного состава DA могут вообще "Войну и мир" в документы со статусами записывать, и при правильных диалогах персонажей, клиент не обратит на это своего внимания :)

    Это нормально?! Имхо, это более чем вопиющая борзость! ... и подлежит немедленному исправлению.
    — SATtva (27/12/2007 16:09)   
    И вашей шифровальщице тоже низкий поклон! "1:1"

    Обменялись любезностями. :-)
    — soot (27/12/2007 17:03)   

    Это нормально?! Имхо, это более чем вопиющая борзость! ... и подлежит немедленному исправлению.


    Что не нормального, если по форме документа со статусами будет всё верно (про диалоги это преувеличение конечно). Допустим можно встроить функцию в клиента, сообщающую что DA создал (v2) документ содержащий какойто процент статусов совершенно неизвестных ранее узлов (вопрос как это отличить от факта более свежего документа с этого DA и ввода в строй кем-либо множества узлов разом, и какой должен быть порог), или исказил статусы большего чем нужно процента узлов (и опять вопрос в большей свежести документа и порога). Мэллори зная это, просто не будет отдавать документы данного DA, опять информировать клиента? А если DA реально не работает? Даже при редких действительных неисправностях и такой функции оповещения, рассылка и разработчики будут засыпаны почтой.

    В текущий момент v3 (в альфа версиях) вообще отбирает право у клиентов выбирать статусы для узлов опираясь на документы составленные DA. Вместо этого создается документ-консенсус под которым подписывается каждый DA и который единственный, выкачивает клиент. С одной стороны теперь клиенту проще бы проверить подписал или не подписал, но в спецификации и коде не заложено отказа DA подписывать консенсус (он полагается на правдивость большинства). Проще говоря все те статусы что рассчитывал каждый клиент локально, теперь рассчитывают только DA. Но даже если бы DA перестал подписывать консенсусы (у Мэллори бы не было его закрытого ключа) по соображениям не согласия, отсутствие подписи можно было бы представить его неисправностью.
    — SATtva (27/12/2007 17:31)   
    Допустим можно встроить функцию в клиента, сообщающую что DA создал (v2) документ содержащий какойто процент статусов совершенно неизвестных ранее узлов (вопрос как это отличить от факта более свежего документа с этого DA и ввода в строй кем-либо множества узлов разом, и какой должен быть порог), или исказил статусы большего чем нужно процента узлов (и опять вопрос в большей свежести документа и порога). Мэллори зная это, просто не будет отдавать документы данного DA, опять информировать клиента?

    Думаю, в таком случае Мэллори просто будет отравлять не все дескрипторы одним махом, а станет делать это постепенно, стараясь не превысить пороговое тревожное значение большинства пользователей (итоговую картину можно будет списать на регулярную замену ключей узлов). Т.е. атака растянется по времени, но будет иметь тот же самый эффект, оставаясь необнаруженной. Адекватна ли в таком случае предложенная схема защиты?
    — soot (27/12/2007 18:37)   

    Адекватна ли в таком случае предложенная схема защиты?


    Вот поэтому, по моему, единственного DA или меньшую половину списочного состава — проще игнорировать, чтобы они не документировали (даже если они единственные содержат настоящую информацию).

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

    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?


    Вот и надо выяснять, можно при особом желании и изменения за месяц (полгода, но кроме ключей надо учитывать процессы ухода старых и появление совершенно новых узлов) сравнивать. Поздно будет, но единственная цель сравнений это выявление катастрофы (если Мэллори разрешит Алисе это рассказать кому-то).
    — soot (27/12/2007 19:01)   

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


    Узлы периодично (раз в неделю) меняют только onion-key, но signing-key по которым их идентифицируют менять не принято (операторы меняют их только при подозрениях в утрате).
    — unknown (27/12/2007 21:39)   

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

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

    Короче про "замедленный вариант атаки" типа "delayed partial cache poisoning" разработчикам лучше пока вообще голову не морочить.
    Может он неработоспособен. Спросим, если хоть как-то на простой вариант отреагируют.

    В новой спецификации (v.3, а она в черновике и неполная) разработчики озаботились о том, что раз ключи DA имеют такую большую ценность,
    то, как я понял, они решили, что хранить их на сервере опасно из-за возможности взлома.

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

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

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

    Технологии типа peer-2-peer они конечно прикручивать не будут, хотя кто знает. И правильно p2p – это популизм,
    на самом деле это только кажется, что это лёгкий способ увеличить
    анонимность, а как выбрать правильный баланс между распределённостью и централизованностью неясно.

    Главное, убедить, что проблему решать нужно и поставить все вопросы и сомнения, а они чтобы озадачились и что-то вероятно более грамотное, чем мы, придумали.

    Слово "may" считаю уместным, поскольку это предложение к развитию и обсуждению идеи в весьма свободной форме, а не готовая инструкция
    к действию и не приказ.

    А у шифровальщиц мы похоже все чему-то не тому учились ;-)
    — unknown (27/12/2007 21:59)   
    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"
    Гость (27/12/2007 22:32)   
    т.е. атака растянется по времени, но будет иметь тот же самый эффект, оставаясь необнаруженной. Адекватна ли в таком случае предложенная схема защиты?

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

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

    Ну почему. Прочитайте топик: я предложил несколько другой протокол, если стремиться к идеалу. Различных DA должно быть много, они должны синхронизированно иметь одну и ту же статистику, а клиенты – доверять некоторым из этих DA либо скачивать статистику со всех из них и потом оценивать вероятность подмены. Аналогия:
    • tor-клиент<=>браузер
    • DA<=>CA

    Если не остановимся, то мы тут скоро весь протокол заново пересмотрим :-)

    Моё глубокое имхо состоит в том, что протоколу тор ещё очень и очень далеко до совершенства, так что пересмотр протокола – дело обыденное.

    V 0.03

    Я прочитал. Условимся считать, что возражений не имею (разрешаю отсылку). Видно, ваш текст прочитала какая-то шифровальщица, и внесла свои правки, судя по тексту (которые явно не сводятся к моим и SATtva'овским) :)
    — SATtva (27/12/2007 23:19)   
    А у шифровальщиц мы похоже все чему-то не тому учились ;-)

    Или просто пишем в спешке, оставляя глупые ошибки... К тексту замечаний не имею.
    Гость (28/12/2007 00:05)   
    "delayed partial cache poisoning"
    Напомнило "молекулярную агрессию в культурное ядро"[link4] Антонио Грамши.
    Гость (28/12/2007 13:33)   
    Another open questions:

    Other open questions, поскольку Another – еще один

    to rise a suspicion

    to raise a suspicion
    — unknown (28/12/2007 14:17)   
    Ладно, всем спасибо, думаю какие-то оставшиеся мелкие ошибки всё-равно неизбежны.

    Поскольку принципиальных возражений нет, последний вариант уже отправлен:

    http://archives.seul.org/or/dev/Dec-2007/msg00029.html

    К сожалению, строки не отформатились по длине :-(, надеюсь они все письма из рассылки всё равно читают через mail-client, а не через браузер.
    Гость (31/12/2007 20:52)   
    Чё-то ничего не пойму.
    Никого не заинтересовало что ли?
    Новых сообщений вроде БЫ нет в той[link5] ветке.
    — unknown (01/01/2008 17:26)   
    Вполне возможно, что не заинтересует.

    Или не поняли и решили, что это повторение старого и известного.

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

    Или может просто в новой спецификации протокола черкнут пару строчек на эту тему.

    А может, к концу года они решили отдохнуть. Вариантов масса.


    Новых сообщений вроде БЫ нет в [WWW] той ветке.


    Зато в пользовательской ветке, начиная с 30 декабря появились сообщения от пользователей
    с массой странных ошибок в логах тор-клиента вида:



    Утверждают, что этих ошибок раньше ни у кого не было (какое удивительное совпадение), а убедительного ответа
    тоже нет. Хотя скорее всего это связано с ошибкой при введении третьей версии протокола и неправильно
    обновлённым конфигом.
    — unknown (01/01/2008 18:58)   
    Раз уж я закрывал 2007 год в рассылке, то я же и открою 2008:

    Вот исправленное по формату строк сообщение в качестве новогоднего поздравления:
    http://archives.seul.org/or/dev/Jan-2008/msg00000.html

    Но думаю более навязчивым быть смысла уже нет никакого, а то забанят ещё и в рассылке нафиг! Если проигнорят и на второй раз, то будем считать вопрос нерешённым и окончательно оставленным без внимания.
    — soot (01/01/2008 22:02)   

    Хотя скорее всего это связано с ошибкой при введении третьей версии протокола и неправильно
    обновлённым конфигом.


    Это действительно ошибка владельца DA (он из США). И такие ошибки уже фиксировали ранее (для европейского DA). Кроме всяких технических ошибок с размещением сертификата и проблем на пути его доставки (вообще рано делать громкие выводы из поведения альфы), у клиента неудачно (это только мое мнение) выбран формат сообщения об этой ошибке, поскольку при отсутствии сертификата клиент не может знать signing_key (которым подписываются консенсусы), он знает только отпечаток долговременного identity ключа DA (которым подписывают сертификат). В результате и наблюдаются "пугающие" нули.
    Гость (01/01/2008 23:10)   
    Но думаю более навязчивым быть смысла уже нет никакого, а то забанят ещё и в рассылке нафиг

    В любом случае, мы своё дело сделали. Я думаю, что если никто не ответит из разработчиков, то хотя бы кто-то из читающих рассылку отпишется (есть же там наверняка соображающий народ). В противном случае всё будет очень странным... скорее близким к тому что либо
    • нас не поняли
    либо
    • мы не понимаем как работает тор.
    Первое означает неясное изложение проблемы в письме, когда все дружно решили что это сто раз обсуждавшаяся уже и замусоленная проблема, на которую есть тандартный ответ, а второе означает что ответ очевиден для тех кто знает протокол тора (то есть атака не пройдёт). Ладно, подожжом ещё, может что появится.
    Гость (02/01/2008 18:19)   
    По моему сеть i2p[link6] заслуживает не меньшего, чем Tor, внимания.
    — unknown (13/02/2008 09:35, исправлен 13/02/2008 09:43)   
    В новой нестабильной версии tor добавлена такая опция:

    FallbackNetworkstatusFile FILENAME
    If Tor doesn't have a cached networkstatus file, it starts out using this one instead. Even if this file is out of date, Tor can still use it to learn about directory mirrors, so it doesn't need to put load on the authorities. (Default: None).

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

    Если использовать при этом скачивание статистики с шифрованием через TunnelDirConns, то значение DA для прямой манипуляции падает.
    Гость (13/02/2008 11:33)   
    Да, но не панацея.
    Мне сам дух не нравится: нет никаких принципиальных запретов строить распределённую архитектуру для сети, однако не торопятся, а скорее считают нормальным положением дел ограничить себя предположением о непогрешимости DA.
    — unknown (13/02/2008 21:32)   
    Roger Dingledine извинился за задержку
    с ответом, но дал полностью
    развёрнутое мнение по вопросу.

    http://archives.seul.org/or/dev/Feb-2008/msg00003.html

    Пока моя первая реакция:

    * Нам удалось их слегка удивить
    своими изысканиями.

    * Со сценарием атаки они
    практически полностью согласны.
    В целом, если отбросить наиболее
    параноидальные моменты, они
    подвердили все наши идеи

    * Почему тянули с ответом полтора
    месяца
    при активных ответах на другие
    вопросы можно считать неясным
    и даже подозрительным, как кому
    угодно.
    Но вежливо извинились и не
    оставили без внимания, мы не зря
    старались.

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

    * Они открыты к конструктивному
    диалогу и интересуются нашим
    мнением

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

    Пока общая идея такая: да опция
    "не для всех", недефолтная, для
    особо продвинутых, но и активно
    привлекающих
    в сеть других пользователей. Её
    наличие будет иметь
    дополнительный, сертификационный,
    репутационный характер, для
    поддержания доверия к проекту со
    стороны "параноиков" и как пример
    того, что надо думать о
    максимально независимой
    реализации .протоколов.

    После этого будем совместными
    усилиями опять также переводить
    послание на English, ok?
    Гость (13/02/2008 22:49)   
    В качестве меры противодействия "глобальному заговору против Tor" ещё бы опциональные задержки пакетов в протокол добавить...
    — SATtva (14/02/2008 00:27)   
    Вполне понимаю Роджера в его оценке возможных последствий от реализации подобной схемы. Здесь порочный круг. Реализация опции и её включение по умолчанию способны в ряде случаев привести к существенному наплыву обеспокоенных пользователей, не знающих как реагировать на сообщения, возникающие в логе. (Эти опасения особенно обоснованы, учитывая экспериментальность всей сети Tor и её перманентный бета-статус.) Если же реализовать опцию, но не включать по умолчанию, это снижает саму ценность схемы — обнаружение атак через DA. Тогда какой смысл её вообще реализовывать? Думаю, у разработчиков достаточно пунктов, требующих внимания.

    Может быть стоит оценить предложение: написать скрипт, наблюдающий за состоянием кэша и сигнализирующий о его аномальных изменениях? Какие преимущества это даст:
    • быстрая реализация, существенно более быстрая, чем даже появление механизма в экспериментальной ветке Tor'а;
    • возможность "поиграть" с эвристиками, чтобы выбрать наиболее разумный баланс между false positives и false negatives;
    • установка скрипта добровольна, так что можно предположить, что пользователь понимает, что делает, и в случае странных результатов не побежит с криками в or-talk.

    При успешном результате эксперимента на скрипте нам будет куда проще убедить разработчиков Tor в действенности данной меры и в необходимости её включения в программу.
    Гость (14/02/2008 01:32)   
    Я поначалу как глянул... подумал: unknown захотел описать ситуацию стихами! А только потом вижу что рифмы нет – лишь форматирование полетело :)

    В качестве меры противодействия "глобальному заговору против Tor" ещё бы опциональные задержки пакетов в протокол добавить...

    Поскольку оппонент всегда сможет понизить скорость передачи данных, задержки, имхо, не помогут. Идея хороша, если у вас есть гипотетический канал строго выдерживающий скорость передачи, которая не падает ниже минимума, и тогда вы что-то мостите... Хотя может я вас не так понял. Это типа полумеры в стиле закоса на покрывающий трафик или что?

    После этого будем совместными усилиями опять также переводить послание на English, ok?

    Я предлагаю на будущее, чтоб текст переводил Зелёный :) Он иняз знает существенно лучше меня, судя по предыдущим правкам к тексту, а я потом скажу опечатки каких он не увидел. Больше у нас желающих кадров вроде нет.

    Если же реализовать опцию, но не включать по умолчанию, это снижает саму ценность схемы ? обнаружение атак через DA. Тогда какой смысл её вообще реализовывать?

    Можно для начала принять аргумент "пусть только для параноиков будет" – это увеличит при прочих равных систему защиты. Далее судя по опыту её использования, отладки, можно будет в будущих версиях придумать и грамотную эвристику и азщиту уже "для всех". Порочного круга, то есть, нет. Это не окончательное мнение, если что придумаем разумное-умолчальное, то можно будет предложить и сразу как дефолт.

    Может быть стоит оценить предложение: написать скрипт, наблюдающий за состоянием кэша и сигнализирующий о его аномальных изменениях?

    Аргумент очень разумный, но один момент меня оталкивает: кэш будет нас извещать постфактум, то есть после включения такого скрипта мы только начнём накапливать опыт по статистике завязанной на функцию, но не получим сразу же инструмент хоть какой-то мануальной защиты. Собственно, я выдвинул предложение больше с целью как можно быстрее обезопаситься от, и получить гарантии, а не только заниматься "научными исследованиями" статистики.
    — SATtva (14/02/2008 02:13)   
    Я предлагаю на будущее, чтоб текст переводил Зелёный :)

    Новая конспиративная кличка? :-)

    Собственно, я выдвинул предложение больше с целью как можно быстрее обезопаситься от, и получить гарантии, а не только заниматься "научными исследованиями" статистики.

    Проблема в том, что, в конечном счёте, решение о включении или не включении такого механизма защиты в Tor принимать разработчикам (самым параноикам они скорее всего предложат написать реализацию защиты самостоятельно). Чтобы они с большей охотой его всё-таки включили, нам таки придётся выполнить некоторую научную работу с целью хотя бы эвристики оценить. Наверняка это проще сделать на реальных данных, чем брать какие-то цифры из головы.
    Гость (14/02/2008 03:50)   
    Новая конспиративная кличка? :-)

    Да ладно, у нас ещё Красный есть! Ценный кадр :)

    Мой ответ пожалуй распадётся на следующие 2: предложения по будущему дизайну сети тор и предложения по усилению защиты клиентов тор. Начну с более простого (прочитал снова весь топик, попытался сжать покопактнее всю идею):

    Предложения по дизайну самой сети тор


    Для рассмотрения эффективной надёжности анонимных сетей определим понятие "секрета сети", которым условимся называть минимальное число публичных ключей, обладание которыми позволяет полностью скомпрометировать сеть. В случае тор-сети секретом является совокупность ключей DA-нод. Мы понимаем правильный дизайн надёжной анонимной сети как тот, который
    • обладает свойством как можно более равномерной распределённости "секрета" по хостам сети (принцип максимальной децентрализации), и который
    • при разрастании сети имеет своим пределом случай "интернета поверх интернета".
    В контексте тора мы имеем ситуацию с сотнями хостов, принадлежащих сети, но "секретом", распределённым лишь среди малой части его узлов – DA-нод. Возникает перманентное желание повысить надёжность сети, распределив её секрет по всем включённым в неё хостам. Аутентификация хоста происходит на основе асимметричной криптографии, для которой известны только два метода проверки валидности: "принцип доверия корневому сертификату" и участие в "сети доверия". Поскольку мы заинтересованы в максимальной децентрализации сети, возникает естественное желание организовать сеть доверия среди всех узлов сети. Здесь можно воспользоваться аналогией с сетью FreeNet, в которой все хосты равноправны между собой, и каждый доверяет только своим соседям. Предлагается организация схемы PGP-доверия в которой бы были обязаны участвовать владельцы нод сети тор, загружая свои подписанные ключи на DA-ноды. Условимся называть связку ключей PGP-сети доверия, в которых участвуют владельцы тор-нод, "статистикой ключей", чтобы отделять её от "статистики статуса", показывающей списки онлайн- и оффлайн-нод. Если опция проверки изменения статистики ключей и статуса, основанная на реальных эвристиках сети тор, будет встроена в тор-клиенты [примечание: смотрим секцию по предложениям для клиентов сети-тор, которая будет ниже], компрометация сети будет ограниченна только случаем атаки со стороны оппонента, так или иначе получившего контроль над большинством обычных тор-нод.
    Число DA-нод может быть сколь угодно велико при большом разрастании сети тор, при этом владелец каждой тор-ноды может иметь возможность сам выбирать свой список и число DA-нод, которым периодически сообщать свой онлайн-статус в сети, как и каждый тор-клиент может выбирать свой список и число DA-нод, с которых обновлять статистику статусов и ключей. В конечной перспективе такой тип сети будет напоминать "интернет поверх интернета", где каждый пользователь сам выбирает список CA-центров, подписи которых он доверяет, и список PGP-ключей, глубина доверия которых (в PGP-сети доверия) считается им удовлетворительной. Заметим, что сейчас доверие к ключам тор-нод основано лишь на единственной подписи, созданной DA, в то время как в предложенной схеме весь файл статистики будет представлять собой связку PGP-ключей сети доверия для тор, а сам DA будет играть роль и локального сервера PGP-ключей в общепринятом смысле.
    Гость (14/02/2008 06:03)   
    Поскольку оппонент всегда сможет понизить скорость передачи данных, задержки, имхо, не помогут. Идея хороша, если у вас есть гипотетический канал строго выдерживающий скорость передачи, которая не падает ниже минимума, и тогда вы что-то мостите... Хотя может я вас не так понял. Это типа полумеры в стиле закоса на покрывающий трафик или что?
    Простейшей мерой может быть возможность указать, сколько пакетов пропустить вперёд себя перед отправкой. Это не потребует дополнительных ресурсов, и увеличит скорость у тех, кто предпочитает скорость, за счет тех, кто предпочтёт большую безопасность – затруднение корреляции. На случай малой нагрузки на узел, когда долго нет пакетов, имеет смысл указывать максимальную допустимую задержку. Задержку можно указывать относительной к времени передачи между узлами – для предотвращения указанной вами атаки искусственного понижения пропускной способности сети. Может быть имеет смысл указывать и минимальную задержку, которую можно будет и не соблюдать при переполнении очереди.
    — unknown (14/02/2008 09:28)   
    Да, самое важное найти правильное решение. Но надо ещё думать о том, как его представить разработчикам, что верно подметил SATtva.

    1. Надо убедить (отчасти это удалось), что проблема реальна. Да, разработчики не сталкивались с такими атаками, да такой атакующий может быть слишком гипотетичен. Но если он появится, то это будет плохо. А поскольку часть пользователей об этом уже знает, то есть недостаток доверия. Пусть разработчики покажут пользователям, что они делают какие-то шаги в сторону прозрачности и децентрализации.
    2. Решение ограничено, это ясно с самого начала. Вопрос "это лучше чем ничего?" или "Защита хуже чем сама опасность?". Как бороться с эффектом ложных срабатываний сигнализации, когда злоумышленник нарочно изводит пользователя ложными срабатываниями, а затем ждёт, пока он отключит или станет игнорировать сигнализацию? (это как редкий, но иногда эффективный способ ограбления или угона авто).
    3. Опция для параноиков не имеет ценности? Параноики могут предупредить остальных. Правда их можно перед этим многократно дискредитировать по пункту 2. Как этого избежать? Если у них не было перед этим работы с контентом, подрывающим их анонимность, они могут сохранить подозрительный кэш для проверки и последующего предъявления и доказательства того, что кто-то ставит левые подписи. Кроме того, есть же отключенные в некоторых дистрибутивах по умолчанию или ограниченные опции в ядре Linux (boot selinux=0), чтобы не смущать большинство пользователей. А есть наоборот укреплённые версии для защиты от особо сильных атак. и они тоже дают много ложной тревоги в логах. Если есть "hardened kernel", почему не может быть "hardened tor"?
    4. Что делать пользователю? При малейшем сбое в сети выдёргивать шнур и думать о конспирологическом заговоре против сети TOR, как иронизирует Роджер? Или действовать по принципу "Вроде опять какая-то атака. Нажмём OK и продолжим работу". Это зависит от уровня параноидальности пользователя. Например в первых протоколах квантовых каналов связи считалось нормальным при обнаружении аномалий в канале, подозревать худшее – атакующего и прекращать согласование ключа. Затем были разработаны более сложные протоколы: можно без риска согласовывать ключ при потере или умышленном искажении параметров части фотонов, только снизив пропускную способность канала – "квантовое согласование ключа в присутствии злоумышленника". Почему бы не ввести пока первый вариант для желающих?
    5. Вынести это всё в виде сторонней утилиты? Получать данные по статистике через контрольный порт tor? Но у параноиков он выключен. тем более, после уязвимости с ним связанной. Выключен он и в конфиге по умолчанию (кроме установки в связке с Видалией на Windows).
    Анализировать кэш скриптами? Во первых, после того как изменили формат статистики и разбросали её по разным файлам это сложно, во вторых он большой и анализ всех файлов (их около 3 Mb) будет проиходить медленно, даже если написать утилиту парсер-анализатор. С чисто исследовательской точки зрения это конечно полезно. Но возможно ещё более непрактично. А вот сам клиент получает данные порциями, которые и может анализировать по частям, сопоставляя с тем, что уже получено.
    — unknown (14/02/2008 10:46)   
    Число DA-нод может быть сколь угодно велико при большом разрастании сети тор, при этом владелец каждой тор-ноды может иметь возможность сам выбирать свой список и число DA-нод, которым периодически сообщать свой онлайн-статус в сети, как и каждый тор-клиент может выбирать свой список и число DA-нод, с которых обновлять статистику статусов и ключей.

    Похожее решение есть в дистрибутиве Debian GNU/Linux:

    пакеты можно скачивать с сотен зеркал, проверяя их подписи. Зеркала иногда взламывают, иногда они падают и т.д., но security обновления можно скачать только с центрального кластера. Если с ним что-то случиться, больше шансов это заметить.

    В TOR аналогично: DA удостаиваются чести намертво вшить свои сертификаты в пакет. И можно пытаться отловить ситуацию если с ними что-то не так.
    От чего строить доверие, если каждый может быть DA? Злонамеренный exit-node может что-то делать с проходящим трафиком, это ещё можно как-то пережить, но DA может участвовать в атаках на раскрытие анонимности. Сколь угодно много этих DA бы ни было, но рано или поздно на такого DA пользователь наткнётся.

    Если проблему доверия DA вынести ещё на один виртуальный уровень, можно сконструировать новую атаку, наподобие изначальной, тоже на новом уровне. "Reflection on Trusting Trust" problem.
    — unknown (14/02/2008 11:13, исправлен 14/02/2008 11:25)   
    Судя по этому сообщению, spinore, Ваша идея о множестве DA поддержана не будет:
    http://archives.seul.org/or/talk/Feb-2008/msg00150.html

    We could use some more, it's true. But we need to make sure that the
    people who run them are well-known as being useful contributors to the
    Tor community and also as being honest people with good common sense.

    Их не{на}много увеличат, но они все будут держаться на репутации известных в коммунити владельцев, так чтобы их было немного и они все были на виду. Запустить свой и для себя никто конечно не мешает, но вы выделите себя в анонимности среди общей массы. Плюс где-то раньше у них говорилось об опасности атак разделения.

    Новые правила ужесточают требования к владельцам DA:

    authority-policy[link7]

    Обратите внимание, что лично Роджер является главным арбитром. Доверие во многом строиться вокруг него.

    Should be run by somebody that Tor (i.e. Roger) knows.

    — SATtva (14/02/2008 12:25)   
    [offtopic]
    Новая конспиративная кличка? :-)

    Да ладно, у нас ещё Красный есть! Ценный кадр :)

    "Бешеные псы" Квентина Тарантино: Mr. Green, Mr. Red, etc. :-)
    [/offtopic]
    — unknown (14/02/2008 12:42, исправлен 14/02/2008 12:42)   
    [offtopic]
    ;-) А spinore кажется когда-то кирпичём был, а сейчас находится в состоянии неопределённости и квантовой спутанности, как "кот Шрёдингера": не поймёшь то ли он есть, то ли его нет.
    [/offtopic]
    Гость (15/02/2008 03:14)   
    А вот сам клиент получает данные порциями, которые и может анализировать по частям, сопоставляя с тем, что уже получено.

    А если включить debug-уровень, разве в нём не будет содержаться вся нужная нам информация? Тогда работа выглядела бы как

    Где unknown-analyzer делал то что предлагалось делать скрипту и выводил сие на панель, ну напару писал бы и типичную информацию, что пишет

    От чего строить доверие, если каждый может быть DA? Злонамеренный exit-node может что-то делать с проходящим трафиком, это ещё можно как-то пережить, но DA может участвовать в атаках на раскрытие анонимности.

    Каждый может стать CA и начать выдавать сертификаты, только вам многие поверят? Но заметьте что раличных CA (рассмотреим только те что встроены в браузер), много больше чем 7. Здесь – ты же штука. Каждый DA может заработать себе репутацию, потенциально... а пользователь волен выбирать кому он доверяет больше (видимо, в зависимости от задачи и от того, от кого он анонимизируется).
    Гость (15/02/2008 03:40)   
    Если проблему доверия DA вынести ещё на один виртуальный уровень, можно сконструировать новую атаку, наподобие изначальной, тоже на новом уровне. "Reflection on Trusting Trust" problem.

    Естественно, вы меня предвосхищаете :) Я хотел написать но забыл. Да, получим фрактальнуюпирамидальную систему: от доверия к тор-нодам к доверию для DA, от доверия к DA к доверию super-DA и т.д. Но реальный интернет обошёлся пока что одним слоем – CA. Видимо, его почти достаточно.

    Опять же, я не хотел сказать что это предложение по поводу ближайшего будущего. Скорее, это моё видение того во что должен превратитсья тор по прошествии длительного времени, если ему дадут ходу. Да, они боятся атаки разделения, я их понимаю, но когда сеть станет очень большой такая атака рано или поздно произойдёт. В конечном счёте тор-team будет лишь группой, отвечающей за исходники. Мне так кажется. Что касается в целом атаки по дискредитации анонимности будучи злонамеренным DA-узлом, можно упомянуть про обязательное участие в сети доверия для тор-нод. DA, конечно, сможет сказать что ключи для части тор-нод сменились, но на них не будет покрывающих подписей других узлов тор-нод, а грамотный клиент настроенный с учётом разумных эвристик сразу скажет "баа!! 50 узлов новых враз появилось, никем их ключи незаверены... откуда бы они так?". Или ещё "О! Ключи все ОК, только почему то вдруг DA говорит что 97% хостов вдруг оказалось в дауне, чё правда что ли?". Схема многоуровневая просто... и в общем-то я её продумывал. Начинаем с разделения статистики ключей и статистики саттусов – это важный момент. Таким образом теперь есть только 2 атаки:
    • на подмену ключа, от которой защищает умная диагностика, проверяющая перекрёстные подписи тор-нод (глубину проверки в сети доверия), и
    • на подмену статистики от которой защитит опять же грамотная эвристика (например, в пределах месяца не может смениться статус у 97% тор-нод).

    Их не{на}много увеличат, но они все будут держаться на репутации известных в коммунити владельцев, так чтобы их было немного и они все были на виду. Запустить свой и для себя никто конечно не мешает, но вы выделите себя в анонимности среди общей массы. Плюс где-то раньше у них говорилось об опасности атак разделения.

    В идеале можно представить себе много анонимных групп в интернете, каждая из которых прячется от своей угрозы. Это и определяет список DA. Для малых сетей – да, лучше то что предлагает Роджер. Я всего лишь хочу чтобы он в рамках хотя бы своей тор-сети перевёл протокол на тот, который кастрирует права DA и уменьшает число атак основанных на злоупотреблении авторитетом DA. В конечном счёте, если я нигде не ошибся, если пользователь скачал правильные исходники тор, то единственная остающаяся атака – постепенное введение (!) [враз ввести не получистя при грамотной диагностике] в сеть тор подконтрольных оппоненту узлов пока их число не достигнет уровня, достаточно для проведения атаки. Ну и атака на корреляцию трафика – это уже классика :)

    P. S.: ещё можно пофантазировать насчёт протокола, в котором общеизвестны лишь exit-узлы тора, но не знаю реализуемо ли такое хотя бы теоретически [это в целях нейтрализации атаки на корреляцию трафика].
    — unknown (15/02/2008 10:05)   
    Но заметьте что раличных CA (рассмотреим только те что встроены в браузер), много больше чем 7. Здесь – ты же штука. Каждый DA может заработать себе репутацию, потенциально...

    Да и все их вшить в tor, как в браузер?
    Они не голосуют между собой за единый результат аутентификации. Сайт аутентифицирует любой из них. Это как в старых версиях тора, подписать статистику мог один любой DA.

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

    Пожалуйста, хоть сейчас – запустите свой DA и уговорите его прописать кого-нибудь в конфиг. Такая возможность есть. И выделяйте свою группу.

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

    Какая может быть сеть доверия между DA? Вы с ними в форуме задушевные беседы ведёте? Их можно только мониторить предлагаемым способом на предмет отклонений. Но Роджер справдливо отмечает, что ситуация когда куча ключей поменяется разом, может возникнуть запросто: поставили новую альфа-версию, там баг, откатились назад и др. ситуации. Вот в чём проблема то ещё. Сеть сама по себе нестабильна и её может лихорадить из-за всяких сбоев.
    Гость (15/02/2008 10:27)   
    Да и все их вшить в tor, как в браузер?

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

    Но Роджер справдливо отмечает, что ситуация когда куча ключей поменяется разом, может возникнуть запросто: поставили новую альфа-версию, там баг, откатились назад и др. ситуации.

    Ну откатились так откатились, а почему при этом ключи тор-нод-та должны смениться? Да и их статус, в массовом порядке... Не вижу связи.
    — unknown (15/02/2008 10:35, исправлен 15/02/2008 10:38)   
    а грамотный клиент настроенный с учётом разумных эвристик сразу скажет "баа!! 50 узлов новых враз появилось, никем их ключи незаверены... откуда бы они так?". Или ещё "О! Ключи все ОК, только почему то вдруг DA говорит что 97% хостов вдруг оказалось в дауне, чё правда что ли?".

    Вот эту идею пока только и можно продвинуть. Пусть в логах пишутся при максимальном уровне настроек сообщения о подозрительной сетевой нестабильности. И пусть будет возможность выключиться и сохранить кэш со статистикой. Для желающих. По аналогии "hardened kernel" – "hardened tor".

    Вот ещё идея, родилась прямо в этой строчке: пусть DA ведут публично доступные логи с хэшами всех когда-либо подписанных ими ключей. Ну или за год хотя бы. Пусть желающие эти логи зеркалят. Чтобы или можно было заметить, что DA подписал ключ, которого никогда в сети тор никто не видел. Или чтобы кто-то хотя бы по прошествии времени мог убедиться с помощью другого компа, или через PGP переписку с друзьями из другой страны, что ключ тор узла извлечённый из кэша клиента, который подписан верной DA подписью никогда ни у кого не встречался и ни разу не проходил в логах ни одного DA.

    Хотите уменьшить полномочия DA? Надо ставить задачу о введении системы аудита! Распределённого криптоаудита всем сообществом, если угодно. Думаю пару заинтересованных человек наберётся :-)
    — unknown (15/02/2008 10:40)   
    Ну откатились так откатились, а почему при этом ключи тор-нод-та должны смениться?

    Кстати не знаю, меняется он при переинстале или нет? Наверное всё-таки нет.
    — unknown (15/02/2008 10:58)   
    Роджер мог бы подписать ключи тех DA которым он доверяет.

    Обратите внимание на последний абзац[link7] и дату создания документа (она была 13 февраля).
    Роджер уже и так обеспокоился насчёт DA, рапределения юрисдикции и предпочитает всех владельцев знать лично (или видимо пристально смотреть им в глаза на коференциях).

    Зачем подписывать их ключи, когда они есть в исходниках, которые естественно подписаны всеми разработчиками?

    Самому тору достаточно иметь ключ Роджера, а пользователи могли бы сами доставлять ключи DA.

    Откуда?
    Типа свободного выбора вместо авторитарного метода назначения DA?
    Чтобы спастить от сговора DA против пользователя?

    Но как проверить, что ключи принадлежат доверенным и неподконтрольным владельцам?

    Как согласовывать результаты голосования групп, выбранных разным методом?

    Так мы можем обвинить в чём-то DA, а при свободном выборе может набежать куча самозванцев и саботирующих элементов, которые будут тыкать друг на друга пальцем: "это он виноват".

    Это допустимо для обычных узлов. Но для корневых DA нужен полный консенсус и слаженность. Поэтому их и не промасштабировать. А то мы придумываем какую-то "Кащееву смерть" в виде спрятанной иголки :-)
    — unknown (15/02/2008 11:09)   
    Что касается в целом атаки по дискредитации анонимности будучи злонамеренным DA-узлом, можно упомянуть про обязательное участие в сети доверия для тор-нод.

    Могут просто потребовать сдать ключики с 50% DA и участвовать с честным видом в сети доверия. А ключики и подставной узел будут применяться только против одного пользователя или нескольких несвязанных. В чём сеть доверия? Как пользователь докажет своё недоверие, как он может исключить DA из этой сети? Только предъявив левые ключи, подписанные DA (если успеет это сделать). Если 50% DA нельзя доверять, то можно ли доверять остальным?
    Ключи украдены или начался заговор против tor?

    Мне кажется разработчики тоже об этом думали и озадачились :-)

    Мне кажется нужно предложить идею аудита логов DA. (См. выше).
    Гость (15/02/2008 11:24)   
    Токмо ради истины:

    февраля


    Ноября. Но сам документ был написан в октябре (странно но найти правки за ноябрь не смог, непонятно почему дата изменилась с октябрьской), тогда же были описаны условия к DA боротья до последнего, и быть из "свободного" государства.
    — unknown (15/02/2008 11:39)   
    Токмо ради истины:


    февраля


    Ноября.

    Спасибо. Вы только что могли наблюдать первоначальные проявления параноидальных глюков :-)
    Гость (15/02/2008 12:42)   
    Вот эту идею пока только и можно продвинуть. Пусть в логах пишутся при максимальном уровне настроек сообщения о подозрительной сетевой нестабильности. И пусть будет возможность выключиться и сохранить кэш со статистикой. Для желающих. По аналогии "hardened kernel" ? "hardened tor".

    Я пока думаю над идеей, скоро озвучу что предлагаю написать им в ответ.

    Вот ещё идея, родилась прямо в этой строчке: пусть DA ведут публично доступные логи с хэшами всех когда-либо подписанных ими ключей.

    Понял. Поддерживаю. В письме про это напишем.

    Кстати не знаю, меняется он при переинстале или нет?

    В юникс не принято при сносе/переинсталляции изменять настройки, хранящиеся в домашней директории. Насолько я помню, тор также смотрит на наличие файлов настройки предыдущей версии, в "/usr/pkg/etc/.../" и то ли по датам смотрит, то ли по изменениям... и если видит что изменялись то не переписывает на новую версию. Вообще, это типичное поведения для unix-программ.

    Роджер уже и так обеспокоился насчёт DA, рапределения юрисдикции и предпочитает всех владельцев знать лично

    Я его понимаю и поддерживаю. На данный момент видимо это самое разумное решение. Но Роджер не будет жить вечно, и т.д. Все мои рассуждения строились на аналогиях DA с CA. Я не вижу столь концептуальных отличий. Заметим, что последнее время с CA пришли некие изменения к пониманию: доверять CA нельзя, так что можно свой серт не подписывать ничьим сертификатом, зато своим юзверям сообщить правильный сертификат своего сайта, чтобы они его прописали в браузере.

    Типа свободного выбора вместо авторитарного метода назначения DA?
    Чтобы спастить от сговора DA против пользователя?

    Ну типа да – это как использование CA cert которым подписан сертификат pgpru.

    Но как проверить, что ключи принадлежат доверенным и неподконтрольным владельцам?

    Полностью неподконтрольных не бывает ибо все мы люди, но есть эвристики, как и с сертами. Вот, авторитет Роджера – одна из таких эвристик :)

    Так мы можем обвинить в чём-то DA, а при свободном выборе может набежать куча самозванцев и саботирующих элементов, которые будут тыкать друг на друга пальцем: "это он виноват".

    В любом случае подразумевалось что DA будет не так много и т.д. Человеку с улицы, то есть, естественно, не поверят.

    быть из "свободного" государства.

    И давно это у нас Америка и Европа стали свободными государствами? Америка прослушку своих граждан активно ведёт, Европа собирается запретить все анонимные сети... ЬI?

    Могут просто потребовать сдать ключики с 50% DA и участвовать с честным видом в сети доверия. А ключики и подставной узел будут применяться только против одного пользователя или нескольких несвязанных. В чём сеть доверия? Как пользователь докажет своё недоверие, как он может исключить DA из этой сети? Только предъявив левые ключи, подписанные DA (если успеет это сделать). Если 50% DA нельзя доверять, то можно ли доверять остальным?
    Ключи украдены или начался заговор против tor?

    Моё рациональное внутри меня мне говорит что халява с тор не может длиться вечно. Во время когда вместо большей и большей свободы внедряются повсеместно всё более и более тотальные типы контроля анонимным сетям не место. Если бы кто-то слил инфу по поводу того что там в высших ешелонах думают по поводу тор, можно было бы жить спокойнее. Про мрос вот, и про рельную безопасность браузеров правда, например, более-менее уже известна.

    Во-первых, чтобы атаку которую вы описываете, можно было провести, нужно долго и постепенно вводить новые виртуальные подставные тор-ноды для тора. Если ввести сразу из в вашу ацкую машинку (тор-симулятор), то детектор подозрительной активности загноит сей косяк. Таким образом, надо чтобы машинка применялась к выделенному пользователю втечение долгого времени, постепенно добавляя всё новые и новые подставные хосты. Но тогда атакуемый может хотя бы раз в неделю скачивать статистику по третьему каналу и сравнивать её с тем что у него в логах – не появилось ли много лишних нод и не сильно ли сменились ключи нод. Сеть же доверия нужна для хоть какого-то дополнительного контроля за ключами тор-нод. Если я знаю хотя бы несколько людей которые тоже поддерживают тор-ноды, если я хотя бы общался с ними в сети, я могу подписать их ключи засвидетельствовав этим, что в некоторой мере доверяю им (что такие тор-нод хотя бы РЕАЛЬНО существуют, а не только в машинке симулятора).

    Основная суть в том, что скачав верные ключи для всех нод и статистку онлайн/офлайн, уже можно надолго забыть об атаке подмены ключей/статистики, ибо там идут малые колебания вокруг некоего "среднего". Надеюсь, понятно изъяснился.
    Гость (15/02/2008 12:48)   
    "ибо там идут только малые колебания вокруг некой "усреднённой" статистики" имелось в виду.
    — unknown (15/02/2008 13:23, исправлен 15/02/2008 13:36)   
    Я пока думаю над идеей, скоро озвучу что предлагаю написать им в ответ.

    Да, жду с интересом, надеюсь не только я.

    Вот, авторитет Роджера – одна из таких эвристик :)

    Аналогия – Л. Торвальдс или Theo de Raadt

    И давно это у нас Америка и Европа стали свободными государствами? Америка прослушку своих граждан активно ведёт, Европа собирается запретить все анонимные сети...

    Свобода относительна. Проще там хотя бы об этом узнать. Как власти делают это в других странах узнать сложнее.
    Плюс хотя бы иногда слабый может выиграть судебный процесс против сильного: например Hepting против AT&T или даже можно выиграть судебный процесс против государства, см. дело криптографа Bernstein vs USA[link8] или хотя бы здесь[link9].
    Хотя эффект от таких процессов не очень велик, прослушивание продолжается и т.д., но наиболее грубые злоупотребления это предотвращает.
    Что-то мне трудно представить даже показушных процессов "Слушается дело: Вася Пупкин против России".


    Во время когда вместо большей и большей свободы внедряются повсеместно всё более и более тотальные типы контроля анонимным сетям не место.


    Может это естественная уравновешивающая сила?


    Если бы кто-то слил инфу по поводу того что там в высших ешелонах думают по поводу тор, можно было бы жить спокойнее.


    Тупо фигеют. Или борются разными группировками по поводу разных вопросов. У них и более сурьёзные проблемы есть. Думаете какая-нибудь Ангела Меркель что-то знала про ремэйлеры, когда в Германии принимали закон ограничивающий анонимные сервисы?

    Если я знаю хотя бы несколько людей которые тоже поддерживают тор-ноды, если я хотя бы общался с ними в сети, я могу подписать их ключи засвидетельствовав этим, что в некоторой мере доверяю им (что такие тор-нод хотя бы РЕАЛЬНО существуют, а не только в машинке симулятора).

    Так это вручную будет делаться, напишите письмо, пообщайтесь, у них abuse-адрес есть. Как ключ поменяется, спросите в чём дело. Только ещё и это придётся делать анонимно. А то вдруг вычислят и их ключи подменять не будут, не будете же вы только через них ходить. Кстати, это в чём-то близко к входящим guard-нодам, только тут вы их выберете сами.
    С другой стороны для кого важна ваша подпись? Для тех кто знает вас? А кто не знает. Кто-то без репутации может наподписывать кучу ключей нод, а затем отозвать подписи. И что это будет значить? Вообще тор для скорости работает с относительно короткими ключами и не считает никаких сетей доверия. Сети доверия ещё подобны социальным сетям, а они потенциально подрывают анонимность.

    Можно ли переносить в TOR какую-либо модель, изначально рассчитанную для privacy, но не для anonymity?
    Гость (15/02/2008 13:33)   

    не будет жить вечно, и т.д.


    Какой Вы добрый, spinore. Но даже если формально; действительно думаете, что подобные по структуре анонимизирующие сети, переживут и Вас в том числе?

    Уверен что будем наблюдать еще 3-е и 4-е и n-е поколение, хоть бы и с прежним названием. Каждый узел будет посредником (bridge) и DA (функции изменятся конечно), и будет сеть бескрайней и не будет видно с одного края другой (clique mode) — ляпота.


    И давно это у нас Америка и Европа стали свободными государствами?


    Специально для вас и взято в кавычечки. На самом деле именно фразы про свободу в документе нет. Будем считать что вычитал между строк (там где спецслужбы будут гуманны и разрешат, что-либо владельцу DA разгласить).
    Гость (15/02/2008 13:50)   
    [offtoпег]
    Аналогия? Л. Торвальдс или Theo de Raadt

    Раадта знаю, а Торвальдс – это кто такой? :)
    [/offtопег]

    Сети доверия ещё подобны социальным сетям, а они потенциально подрывают анонимность.

    Я не вижу никакой особой деанонимизации в том что кто-то подписывает ключи кого-то. Многие, имхо, на это бы пошли. Есть такое понятие как фринет – там делается тоже самое в нынешнем протоколе – я выбираю себе соседей, даю им свой адрес и IP, а они мне – свои. В идеале соседи по фринет – это мои знакомые которым я доверяю (из разряда вопросов "откуда мнея взять надёжных "пиров"?"). Владельцы многих тор-нод могут быть выявлены – они не анонимны, анонимна лишь сама передаваемая информация по сети. Я согласен что это некий эффект деанонимизации, рассказывать каким тор-нодам я, как владелец тор-ноды, допуситим, доверяю. Вопрос даст ли это существенные преимущества в защите тор, и стоит ли эта деанонимизирующая поправка выделки. Вопрос открыт. Я не говорю что этому должны следовать все владельцы тор-нод, это должно быть опциональной фичей, но рекомендуемой. Например, если Роджер лично знает массу владельцев нод, почему бы ему не подписать их ключи явно? Подчёркиваю, что вопрос пока вполне открытый касаемо сети доверия и перекрёстных подписей – я просто хотел сделать "заверение статистики ключей" эффективным метанаблюдателем – всей сетью, то есть сетью доверия, вместо того чтобы поручить всю ответственность одному лишь DA. Клиент может проверять перекрёстные подписи не каждый 15 минут, а хотя бы иногда... хотя бы только при старте тора.

    Можно ли переносить в TOR какую-либо модель, изначально рассчитанную для privacy, но не для anonymity?

    Мне это напоминает аналогию между PGP и OTR. Когда генерируется otr-ключ для шифрования по DH, PGP используется для заверения отпечатков, вроде бы, но тем не менее доказать что я говорил именно то что говорил нельзя, несмотря на участие PGP как компонента схемы. Я тонкости не понимаю, но мне так объясняли.
    Гость (15/02/2008 14:01)   
    Но даже если формально; действительно думаете, что подобные по структуре анонимизирующие сети, переживут и Вас в том числе?

    Когда обсуждается дизайн сети, иногда нужно думать на много лет вперёд, чтобы не оказываться перед проблемами типа ipv6 вместо ipv4 и т.д. Там где-то в инете была целая подборка смешных "прогнозов" на будущее, которые утверждали чего в будущем заведомо хватит. Следует понимать, что ошибившись с дизайном потом можно долго растить костыли и платить куда большую цену чем за грамотное начальное проектирование. В этом смысле рассуждения о том что будет "когда ..." не столь глупы. Всё-таки не серьёзно привязываться к конкретному человеку в проекте. Проект должен быть устойчив и без его создателя. Например, как недавно сказал Линус Торвальдс, проект Linux сейчас практически не почувствует ничего если он уйдёт из проекта – он там один из многих и вполне заменяем, и это верно. Если мы хотим проект, который бы был надёжен, он должен быть поминимуму зациклен на человеческий фактор. Само начинание (тор-проект) мне нравится, и я не вижу причин почему оно должно умереть (если только ему очень "помогут").
    — unknown (15/02/2008 14:52, исправлен 15/02/2008 14:53)   
    PGP используется для заверения отпечатков, вроде бы, но тем не менее доказать что я говорил именно то что говорил нельзя, несмотря на участие PGP как компонента схемы.

    Все тонкости только в том, что: доказать нельзя, отследить можно. Вы можете только утверждать, что подписанное после завершения аутентифицированного сеанса могло быть подделано кем угодно, начиная от вашего собеседника, которому вы можете не доверять, что он вас не сдаст с подписанными вами запретными заявлениями. Как это перенести на тор или сети доверия не понял. Сети недоверия пока ещё не изобрели.
    — unknown (15/02/2008 15:12, исправлен 15/02/2008 15:13)   
    Клиент может проверять перекрёстные подписи не каждый 15 минут, а хотя бы иногда... хотя бы только при старте тора.

    Кстати, тут есть какой-то тонкий момент. Какого типа ещё специальные проверки разумно было бы осуществлять на старте? Или раз в сутки при полном устаревании кэша, если периодичность обновления его была невелика?

    Чтобы выбрать наиболее надёжные пути получения статистики?
    Гость (15/02/2008 15:35)   
    Как это перенести на тор или сети доверия не понял. Сети недоверия пока ещё не изобрели.

    А не надо переносить. Просто на уровне аналогий вспоминилось.
    — SATtva (15/02/2008 15:51)   
    Мне нравится предложение unknown'а о системе аудита DA. Да, в "академических" криптопротоколах принята концепция упреждения: если вы раз облажались — вам хана. Практическая криптография, однако (в основном в финансовой сфере), зачастую полагается именно на средства обнаружения.

    Я не поддерживаю переделывание протокола. Во-первых, сейчас это вообще бессмысленно, сеть слишком мала. Во-вторых, я сильно сомневаюсь, что разработчики Tor'а, изучающие анонимные сети на научном уровне, не задумываются над такими вопросами, как масштабирование доверия. Мне кажется, мы тут просто будем изобретать велосипед.

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

    Только в реализации этой системы на уровне DA, мне кажется, есть проблема. В специальной функции публикования заверенных ключей и зеркалирования этих списков нет особого смысла. В сущности, каждый клиент и так собирает все ключи, заверенные DA, в статус-документах. Так что это дело каждого клиента накапливать эти записи и сохранять до лучших времён, чтобы потом сверить их с аналогичными записями других клиентов.
    Гость (15/02/2008 17:06)   
    Да, жду с интересом, надеюсь не только я.

    Решение, в общем, уже продумано, осталось лишь всё внятно непротиворечиво изложить и отдать на суд читателей. Стоит отметить, что только что высказанное пожелание SATtva'ы оно учитывает. Единственное что мне не очень нравится, прийдётся ввести около 10ка новых дополнительных опций для конфига и это число особо не ужимается.
    — unknown (15/02/2008 17:13)   
    Я не поддерживаю переделывание протокола. Во-первых, сейчас это вообще бессмысленно, сеть слишком мала.

    Они указывали, что число DA не будет больше примерно десяти.

    Нужна лог в виде базы данных с поиском по хэшам ключей. Мы исходим из того, что клиентам могут подбросить ложные ключи. И это не те ключи, которые DA раздают массово всем. Клиенты могут проверить при подозрении их соответствия (теряя при этои часть своей анонимности на текущий сеанс). Но тот же Мэллори может заставить изменять записи в этой базе, а если клиенты будут сливать туда свои ключи, то там будет полный трэш из верных и неверных ключей. Подмену могут сделать и на зеркалах.
    Единственное на что можно опираться – на метки времени, которые должен отправлять на DA каждый tor узел, тогда записи в логах будут соединены этими метками и задним числом править отчётность будет нельзя. нужно поймать DA на том, что они не раздавали в какой-то момент времени ключи, которые в этот момент существовали у пользователей.
    — unknown (15/02/2008 23:01)   
    Вот что у меня вырисовывается, как краткий
    вариант письма, не перегруженный далеко
    идущими планами
    (метки времени оказались не нужны):

    пользователей тора делим на две группы:
    простых и продвинутых (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"?
    Гость (16/02/2008 00:31)   

    В обычном случае для отправки статистики
    сети DA подписывают весь список ключей tor-узлов
    целиком.
    Подписывать каждый ключ затратно. Но раз в
    сутки
    DA обязан подписать каждый ключ по отдельности
    и выложить в общий доступ в отформатированном
    виде.


    ммм... можно ссылку?

    DA всегда обязан отдать список с дескрипторами, подписанный своим ключом. Но, это v1 протокол директорий, и там никогда не подписывают каждый дескриптор каждого чужого узла в отдельности. Очень подозреваю что этот протокол будет выведен из обращения вскоре после удачного нового релиза. Надо опираться на v3 в котором DA подписывают консенсус-документ содержащий отпечатки идентификационных ключей узлов и дайджесты опубликованных ими дескрипторов (клиенты выкачивают дескрипторы адресовав запрос с этим дайджестом к зеркалирующим директориям). Сами дескрипторы проверяется на целостность и просто хранятся в кешах директорий.
    Гость (16/02/2008 12:14)   
    С unknown'ом по большей части не согласен. Громоздко всё. От pgp-сети доверия видимо надо будет отказаться, ибо преследуемые цели можно достичь без неё – есть более простое решение. В педелах часов 2 напишу, сейчас просто занят.
    Гость (16/02/2008 16:43)   
    Для начала обсудим схему безо всяких перекрёстных 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 в нужные значения. Правильные значения можно получить после изучения статистики, и анализа того как она меняется со временем. Когда средние значения отклонений для опций будут ясны (те, которые почти никогда не превышаются), их можно по умолчанию включить уже для всех.

    Как говорят на лоре, "всё, пинайте" :)
    — unknown (16/02/2008 16:44)   

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


    Так это предложение делать раз в сутки. Т.е. предлагается, что должен будет для отчётности. И список всех ключей за сутки. А выше написано, что отдаёт целый список как сейчас есть.

    Хотя в самом упрощённом варианте, пользователи действительно как говорит Sattva, могут просто обмениваться данными, извлечённых из своих кэшей и вести аудит без доп. требований к DA.

    Но если у spinore есть ещё более простое решение, то было бы ещё
    интереснее.
    Гость (16/02/2008 16:56)   
    P. S.: стоит добавить, что местами логика чуть слетела. Сначала я думал что скачиваемая статистика содержить ключи всех имеющихся тор-нод в сети, а также отдельное указание к каждой ноде её статуса. Потом я решил что она содержит только список онлайн-нод с их ключами. Это всё от незнания формата и спецификаций :) В иоге опции были написаны под случай логики, когда при каждой скачке статистики клиент банально получает онлайн-список нод и их ключи, и ничего более [ни о каких других нодах скачанная статистика не говорит, а частности о том кто ушёл в оффлайн – если только по сравнению с предыдущим файлов статистики это можно продетектить]. В общем, если итоговая логика сильно несоответствует спецификации, то предложенные опции надо немного пофиксить, возможно, на другие.
    Гость (16/02/2008 17:01)   
    Что касается PGP-сети доверия и прочих инструментов – это вопрос обсуждения. Пока мой вариант самый лёгкий – ничего не надо менять в протоколе, – только диагностиику самого клиента. Со временем можно будет видимо ввести и какие-то более драконовские меры, чем я предложил, только надо сначала будет понять: какова атака, от которой мной предложенное не защищает, новые меры защитят. Моё имхо, хорошо если протолкнуть хотя бы такой, облегчённый формат, для начала :) А то Роджер испугается и скажет что "атака малореальна", "не есть основная угроза" и прочее. В моём понимании, больше стоит бояться атаки на корреляцию трафика. Единственное, чем лучше атака с ацкой машинкой – она позволяет детерминистским образом деанонимизировать полностью (а не вероятностно как в кореляции трафика), и читать надёжно весь транслируемый в тор от конкретного лица трафик.
    Гость (16/02/2008 17:07)   
    Хотя в самом упрощённом варианте, пользователи действительно как говорит Sattva, могут просто обмениваться данными, извлечённых из своих кэшей и вести аудит без доп. требований к DA.

    Но если у spinore есть ещё более простое решение, то было бы ещё
    интереснее.

    ЫЫЫ, фактически я сделал то, что SATtva сказал изначально, просто облекши в техническую форму :))
    Гость (16/02/2008 17:11)   
    Да, забыл добавить важное: по прошествии какого-то времени (месяца, недели?) пользователь меняет свой файл "средней статистики" на новый. Он берёт самую свежую статистику, на которую ему указывает клиент, сравнивает её со статистиками своих знакомых/соседей/собутыльников, и возводит в ранг "средней", прописывая к ней путь в конфиге. Таким образом, вкратце схема защиты такова:
    Все стадртуют с доверяемого среднего, накладывая ограничения на эволюцию статистики. Время от времени средняя статистика между пользователями синхронизируется (вручную), и обновляется.
    Гость (16/02/2008 17:24)   
    Tor watchers проверяют, что список корректный (в нём не содержится ключей, которых бы не было в общей статистике

    А вот тут бага. Дело в том, что для того чтобы гарантировать что у тор-клиента есть все ключи тор-нод, которые подписал DA за сутки, ему надо сутки держать запущенным клиент, как минимум. Иначе DA сможет сказать, что те ноды, ключи которых он подписал, были в точности в то время онлайн, когда все тор-вочеры сидели незаконнекченными к тору. это если тор-вочеры – тор-клиенты (для тор-нод это не так критично, как аргумент). Идея в том что объединение некоторого числа тор-вочеров даст строго обоснованную претензию к DA лишь в случае если те постоянно online.

    Таким образом проблема решается не беспокоя разработчиков, а между пользователями и
    наблюдателями и возможно владельцами tor узлов и только при обнаружении серъёзных
    доказательств выносится на обсуждение.

    Как я уже высказался, лучше для начала воздержаться от беспокойства владельцев тор-нод – им итак достаётся проблем.

    P. S. Это как защита дома от молнии с помощью громоотвода? Если она есть, то молния скорее всего не попадёт и кажется что она не нужна. Она ведь и так редко попадает. Но последствия попадания могут быть разрушительными.

    Кстати, очень действенное сравнение. Поддерживаю написать об этом в письме в качестве красивой аллегории.
    — unknown (16/02/2008 17:35)   
    В целом набор опций выглядит хорошо.
    Только по моему у нас у всех не до конца ясное представление о работе сети.

    Всё что подписано 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, но не вся сеть и после
    подкладывания чужой статистики они могли работать.
    — unknown (16/02/2008 17:49)   

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


    Не совсем. Я исхожу из того, что группа скомпрометированных DA не будут настолько наглыми, что подпишут кучу левых ключей для всех.
    Левые ключи будут поставляться лишь отдельным изолированным клиентам. А не по всему миру, не во всех странах и не во всей сети.

    Кто-то, устроивший сговор с 50% DA не захочет это так публично выставлять, чтобы обнаружить было легче.

    Пусть DA в списке подписывает время действия полученных ключей.
    Гость (16/02/2008 18:14)   
    Каждый список? От своего DA, можно узнать каким DA подписан ключ.

    Важно, есть ли там сама подпись от DA, или её клиент проверяет и уничтожает?

    Но это пока в версии 2. В версии 3 не так? И подпись какого-то хэша в начале списка относится к последующей части файла? Или он не подписан и предъявить его в качестве доказательства нельзя?

    Были торокопатели класса лыжы_асфальт и soot. Они бы могли точно сказать что к чему.

    Дальше, по этим отпечаткам ключей скачиваются сами ключи по мере возможности и складируются в /var/lib/tor/cached-routers и /var/lib/tor/cached-routers.new.

    Видимо, cashed-routers и есть пример собственно файла статистики...

    Кстати можно даже вызвать ложное срабатывание, если запускать и отрубать после авторегистрации в DA много tor серверов умышленно.

    Что касается этой атаки и беспокойства самого Роджера:
    • Опция для параноиков. Кто хочет – включает лишь диагностику, никто никого не заставляет включать Actions.
    • Если будет предпринята массовая атака по подключению большого числа тор-нод на короткое время, то не вижу ничего неадекватного в том что тор-клиенты на это среагируют и известят пользователя. Далее уже тор-team будет думать что с этим делать, я пока ничего предложить не могу.
    На следует исходить из очень простого тезиса: от заметания мусора под ковёр сам мусор никуда не исчезает, так что опциональную (по желанию) диагностику включить надо – она делает лишь лучше. Далее: есть группа параноиков, она хочет хоть какую-то защиту – для них Actions. Атаку с массовым подсоединением новых нод к сети можно провести и сейчас, но это вряд ли кто обнаружит и никто толком ничего не сможет предпринять (банально нет инструментов) – так лучше что ли? Не стоит сразу хвататься за звёзды, давайте для начала протолкнём Diagnostics и Actions для параноиков и для диагностики возможных атак тор. Далее, может быть сам Роджер выскажет идеи что можно сделать против тех ддос атак.

    Кстати, что приходит в голову против такой атаки: можно установить квоту – число возможных подключений тор-нод к тор сети за единицу времени исходя из реальной статистики (чтобы очередь не накапливалась и атака не проканывала). – почему бы и нет? Сейчас все сайты устанавливают счётчики на скачку файла например – это чем-то напоминает то.
    Гость (16/02/2008 18:29)   
    Всё это, как я понимаю, можно делать сторонним скриптом, зачем беспокоить разработчиков? На чём нынче принято писать межплатформенные скрипты?
    Гость (16/02/2008 18:35)   
    Всё это, как я понимаю, можно делать сторонним скриптом, зачем беспокоить разработчиков?

    Секцию Diagnostics, возможно, и можно (пока ещё не ясно до конца).
    Секцию Actions нельзя написать (скрипт может реагировтаь лишь постфактум, а это может уже оказаться поздно).
    Там предлагается скрипт, но он кроме того должн быть ещё и интегрирован в функционал tor'а (tor его должен запускать). Кстати, если узлов – сотни, не факт что это будет делаться достаточно быстро.
    Кроме того, действия скрипта в стиле "перехватить статистику, успев создать её бэкап в другом каталоге" я считаю извращением.
    Это всё-таки базовые вещи, потмоу сам tor тоже надо допиливать.
    Другое дело, что можно самим попатчить тор-клиент, так как протокол совершенно не меняется. НО... я не программист.
    — unknown (16/02/2008 19:10)   

    Важно, есть ли там сама подпись от DA, или её клиент проверяет и уничтожает?


    Да, именно это для меня не ясно.


    Были торокопатели класса лыжы_асфальт и soot. Они бы могли точно сказать что к чему.


    Именно soot говорил в этом треде, что в v.3 клиент получает уже согласованный между нодами список,
    если я правильно понял. У меня клиента с поддержкой v.3 пока нет. Если это так, то это плохо
    для аудита. Они там по тихому между собой голосуют, что затрудняет обнаружение
    атаки :-)


    Видимо, cashed-routers и есть пример собственно файла статистики...


    Смотря что называть статистикой.
    Раньше всё было в одном файле, теперь это просто разделили, чтобы разгрузить 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, чтобы было можно обсуждать более предметно.


    Если будет предпринята массовая атака по подключению большого числа тор-нод на короткое время, то не вижу ничего неадекватного в том что тор-клиенты на это среагируют и известят пользователя. Далее уже тор-team будет думать что с этим делать, я пока ничего предложить не могу.


    Это они и так мониторят без помощи клиентов, собирая и анализируя статистику с DA.
    Им возможно бы интересно только знать что у отдельных клиентов картина tor-сети отличается от общей.


    Кстати, что приходит в голову против такой атаки: можно установить квоту – число возможных подключений тор-нод к тор сети за единицу времени исходя из реальной статистики


    Может это уже есть? DA регистрируют узлы почему то через неодинаковые промежутки времени, может есть и очереди и квоты.
    Надо спецификации читать, учитывая ещё что они местами и устаревшие и неполные.
    Гость (16/02/2008 22:03)   
    отпечатки ключей в cached-status, а сами ключи и подробности об узлах в большом файле cached-routers.

    Нужны подробности, в один-два абзаца о том как это всё происходит, протокол обновления статистики. Без этого говорить о конкретике невозможно.

    Если в v.3 действительно клиенту поставляется готовый cached-status с отпечатками, уже подписанный всеми DA

    А там вообще есть какие-нить подписи кого-нибудь из DA?

    Если будет время, предлагаю примерно в течении следующей недели выучить почти наизусть спецификации и v.1, и v.2 и v.3, чтобы было можно обсуждать более предметно.

    Блин, как всё не просто... А по какому протоколу сейчас работает большинство? Я не уверен что это спецификации, подробные и внятные, на каждый протокол есть (в терминах ИДЕИ а не в терминах программистских выпендрёжов). Мне например пох как называется та или иная функция, я бы хотел видеть, меня интересует сама научная идея организации доставки статистики, и мне кажется что прийдётся изучать всю рутину чтобы это понять, но на рутину у меня к сожалению уже нет времени (pgpru.com съедает много времени, да...).

    Можно перевести вопрос в плоскость "есть пример атаки" на то, то и то – сделайте что-нибудь. Мне не нравится сама идея, что они полагаются на то, что ключи DA никем не будут похищены и DA всегда можно доверять. Это сродни доверию что владелец сервиса-анонимайзера не сдаст ваши логи когда его прижмут. В общем, есть вариант объяснить вкратце идею решения в рассылке, а уже как её конкретно согласовать с протоколомроем протоколов – оставить Роджеру. Сразу честно скажу что спецификации читать не буду, я итак оборзел – нифига не делаю по учёбе. Если кто-то поймёт логику работы со статистикой и кратко, внятно её изложит – можно будет ещё пообсуждать, иначе, видимо, ограничимся "вбиванием кола" что "проблема существует".
    — unknown (17/02/2008 01:17)   

    Блин, как всё не просто... А по какому протоколу сейчас работает большинство?


    Стабильные на втором. Третий только в альфа-версиях и он в стадии разработки.


    Я не уверен что это спецификации, подробные и внятные, на каждый протокол есть (в терминах ИДЕИ а не в терминах программистских выпендрёжов). Мне например пох как называется та или иная функция, я бы хотел видеть, меня интересует сама научная идея организации доставки статистики


    Там изложено именно так как вы хотите. На уровне идеи.


    Сразу честно скажу что спецификации читать не буду, я итак оборзел – нифига не делаю по учёбе.


    Я Вас понимаю. Предлагаю сделать перерыв примерно на неделю, если ничего революционного в голову не прийдёт.


    Если кто-то поймёт логику работы со статистикой и кратко, внятно её изложит – можно будет ещё пообсуждать


    Надеюсь у меня будет свободное время за неделю подробно осмыслить все спецификации. Там совместными усилиями двинемся дальше.


    Можно перевести вопрос в плоскость "есть пример атаки" на то, то и то – сделайте что-нибудь.


    Они думаю лучше нас понимают чего можно придумать, если иметь ключи от DA. Того что было изложено в новогоднем письме было достаточно.


    иначе, видимо, ограничимся "вбиванием кола" что "проблема существует".


    ну мы и так уже много чего придумали.

    тезисно кратко пока:

    • проблема существует и может породить кризис доверия

    • первый уровень защиты (автономный): выявление аномалий в статистике; второй (сетевой) сравнение с другими источниками по защищённым каналам выявленных подозрительных ключей; совместное решение с tor watchers о нахождении фальшивых ключей и выявление скомпрометированных DA


    Так или иначе всё что нужно для защиты от атаки это определение того, что клиент видит искажённую картину tor-сети что выявляется или автономно или относительно к другим источникам.
    Может разработчики могут предложить совершенно иной способ решения.
    Гость (17/02/2008 02:43)   
    Ясно. Хорошо.
    — unknown (18/02/2008 11:51, исправлен 18/02/2008 12:06)   
    Собственно, чтение спецификаций не дало ничего интересного.

    Статистика состоит как и говорилось выше из двух частей: статуса сети /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. А так маловероятно.
    — SATtva (18/02/2008 14:56)   
    Такую утилиту не слишком сложно написать на Питоне, но себя в качестве добровольца предлагать боюсь — занят с openSpace.
    — unknown (18/02/2008 15:46)   
    Да, нам хотя бы очередное письмо осилить :-)
    — unknown (19/02/2008 09:52)   
    Кстати, вот что неправильно:

    Пусть было 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), чтобы никогда не равно было нулю.
    — unknown (20/02/2008 10:49)   
    Ну что, вот такой черновик пока, вроде кратко и основные идеи есть. Больше опасаюсь за грамматику :-)

    // 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"
    — SATtva (20/02/2008 14:47)   
    Проверяйте, особое внимание обратите на формулы, надеюсь ничего там не попутал (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"
    — unknown (20/02/2008 20:32)   
    Да, спасибо, что указали на формулы, так корректнее.

    Грамматику привели к приемлимому виду, уже не стыдно отправлять, но как-то интонационное восприятие незначительно поменялось. Зачем заменили словосочетание "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 скажет.
    Гость (21/02/2008 01:22)   
    с ЭБУ ОБРЙМУП, ФБЛ ЮФП ОЙЮЈ ЛПОЛТЕФОПЗП УЛБЪБФШ ОЕ НПЗХ. оП ЪЧХЮЙФ ПЮЕОШ ХНОП. пЮЕОШ ФТХДОП РПРБДБФШ РП ЛМБЧЙЫБН. ъБЧФТБ ЧУЈ РТПЮЙФБА Й РПДХНБА. уРБУЙВБ.
    Гость (21/02/2008 01:23)   
    Я щас напилсо, так что ничё конкретного сказать не могу. Но звучит очень умно. Очень трудно попадать по клавишам. Завтра всё прочитаю и подумаю. Спасиба.
    — unknown (21/02/2008 09:44)   
    Я щас напилсо, так что ничё конкретного сказать не могу

    с ЭБУ ОБРЙМУП, ФБЛ ЮФП ОЙЮЈ

    Очень трудно попадать по клавишам.

    Да, заметно :-)

    Завтра всё прочитаю и подумаю.

    Всвязи с этим можем добавить к фразе:

    We continue to discuss the problem on our website with our heads overheated. :-)

    Нечто вроде:

    And one of us in a hangover condition :-)
    — unknown (21/02/2008 09:53, исправлен 21/02/2008 09:53)   
    in the case of this attack 3+1 corrupted authorities

    а не nodes

    Моя ошибка.
    Гость (21/02/2008 11:15)   
    Написать утилиту которая реализует указанный алгоритм по оффлайновой статистикие – несложно. Предлагаю сначала получить рабочий прототип и проверить формулы на практике, а потом писать в or-dev, чтобы не зашумлять свой же сигнал. Тем более что отношение Роджера к этой идее довольно пассивоное, а дел у него и так выше крыши.
    — SATtva (21/02/2008 11:43)   
    Зачем заменили словосочетание "Lightning strike" на какой-то вялый "hit"?

    Окей, вернём обратно:

    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 of number of keys
    Имеется ввиду количества, может уместнее quantities или оставить номеров?
    numbers?

    Тогда лучше так:

    C=N_k/N_k-1 is the change in the number of keys

    Let I be the index of keys founded, найденных может быть так или получится ерунда, типа основанных фондом?

    Правильно всё-таки found для прошедшего времени. Типа "search process has found 7 docs".

    could print diagrams – я вообще-то графики предпочитаю, с точным временем, их накладывать и сравнивать легче

    Diagram тоже можно перевести как график, а с graph возникает двусмысленность: график или граф?
    — unknown (21/02/2008 13:38, исправлен 21/02/2008 13:48)   
    Написать утилиту которая реализует указанный алгоритм по оффлайновой статистикие – несложно. Предлагаю сначала получить рабочий прототип и проверить формулы на практике, а потом писать в or-dev, чтобы не зашумлять свой же сигнал. Тем более что отношение Роджера к этой идее довольно пассивоное, а дел у него и так выше крыши.

    Я не удивлюсь, если он ответит именно так, слово в слово :-)

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

    2 SATtva: со всеми правками пока согласен
    Гость (21/02/2008 13:52)   
    Я не удивлюсь, если он ответит именно так, слово в слово :-)
    И об этом надо написать тоже! И обяснить ему причину, по которой всё-таки он получил это письмо:
    Пусть это ответит лично он, тогда быстрее желающие найдутся
    — unknown (21/02/2008 15:53, исправлен 21/02/2008 16:02)   
    И об этом надо написать тоже! И обяснить ему причину, по которой всё-таки он получил это письмо:

    Это письмо в рассылку для всех разработчиков и возможно заинтересовавшихся проблемой. То что S легко посчитать из файла мы написали и это и так ясно.
    То что это возможно слишком наивно и недостаточно, мы упомянули.

    Пусть он или ещё кто-то из разрабов оценит пока хоть это. Или скажем всем: "флаг вам в руки, считайте". Думаю всех изложенных причин и объяснений достаточно пока.
    — ygrek (21/02/2008 22:45)   
    По-моему не читая развёрнутое русское описание понять английское – сложно.
    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 это какая-то большая константа -
    максимально расстояние.
    Очевидно первые два свойства выполняются.
    Третье сходу доказать не получилось..
    — unknown (22/02/2008 09:33, исправлен 22/02/2008 09:46)   
    Последнее условие какое-то странное, а точнее неинвариантно к течению времени :)

    теперь пусть время течёт назад: N2' = N1 и N1' = N2

    D очевидно константа в обоих случаях и коэф. S получается связан обратной зависимостью. Некрасиво. Искусственно.

    А время строго не определено. Да, за уши притянутая, чтобы было просто видно отклонение. Чтобы выделить ситуацию с уменьшением числа нод. Хотя главное значение имеет изменение только числа ключей.

    Можно конечно всё строго самим доказать, утилиты написать, работу в /LaTeX оформить с прилагающимися графиками. Но думаю энтузиазым делать это ради очередной коллективной анонимки иссякнет быстро.

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

    ygrek, если можете довести кратко до ума, так чтобы это можно было перевести и отправить в рассылку, тогда хорошо.
    — unknown (22/02/2008 09:44)   
    Теперь просто сравниваем размер общей части с каждым из множеств и выбираем худший показатель
    Z(M1, M2) = min( |M|/|M1| , |M|/|M2| )
    Z принадлежит [0..1], 1 это полное совпадение множеств (лучший вариант), 0 – абсолютно разные множества.

    Да так во многом лучше. Мне тоже хотелось, чтобы величина была нормализованной.

    Только как здесь различать когда число нод уменьшилось (и кол-во ключей уменьшилось допустим ровно на столько же) и увеличилось (пусть кол-во ключей увеличилось ровно на столько же – но это потенциально опасней).
    Гость (22/02/2008 11:12)   
    Причина всех бед – преждевременныя конкретизация. Оставьте формулы на потом, просто пишите словами основные идеи.
    — unknown (22/02/2008 12:17, исправлен 22/02/2008 12:19)   
    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].

    и пока на этом может пока остановимся? Просто хочется уже письмо отправить.
    — SATtva (22/02/2008 18:51)   
    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].

    На самом деле, смысл формализации далеко не очевиден из текста. Может и правда "своими словами"?
    — ygrek (23/02/2008 12:18)   
    По-моему нет смысла приводить формулы "от фонаря" – их надо проверить на практике или хотя бы обосновать подробно теоретически. Можно в этом письме не приводить конкретный алгоритм, а описать лищь общий план действий, а в это время проверять разные подходы.

    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.
    — SATtva (23/02/2008 12:24)   
    numerical => step-by-step?
    — ygrek (23/02/2008 13:30)   
    я имел ввиду численный. лучше numerical criteria
    — unknown (23/02/2008 18:01)   
    Я привёл свой вариант, как пример того, что посчитать можно для начала относительно просто. Инвариантность по времени и нормализация не требовалась, т.к. не планировалось сравнивать состояния из разных источников в один промежуток времени, а только разность состояний между двумя измерения с учётом не только изменения, а и уменьшения/увеличения.

    S<1 это один тип нестабильности (менее вероятный в качестве признака атаки и не такой опасный), S>1 – другой .

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

    Идеи мы привели, черновик тоже.


    We plan to develop a numerical recipe to determine the hazardous difference between two network-status documents.


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

    другое дело может быть этим всё-таки заинтересуются и займутся сами разработчики, плюс на 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"
    — SATtva (23/02/2008 18:44, исправлен 23/02/2008 18:50)   
    unknown:



    Других замечаний не имею. Если коллеги не против, можно отправлять.
    — ygrek (24/02/2008 00:14)   
    не против

    На досуге написал тулзу для парсинга network-status'а версии 2. Пока только считает коэфициент совпадения двух status'ов по "моей" формуле. Можно будет добавить другие формулы, статистику и использовать для анализа.

    Исходники[link11]. Для компиляции требуется ocaml[link12] и extlib[link13]. В Makefile исправить путь к extlib (недоработка, надо будет подключить ocamlfind). Должно работать и на Windows и на Linux. Запускать torstat -diff file1 file2
    Гость (24/02/2008 02:41)   

    Вы бы не могли подсказать как понимать такой ворнинг и следует ли о чём-нить беспокоиться? Весь остальной вывод в норме.
    Гость (24/02/2008 07:40)   
    Если имеется N_k ключей нод и N_k+1 за интервал обновления, можно сравнивать увеличение/уменьшение их количества

    Заметим(!), что я не зря ввёл понятие средней статистики, обновлять которую нужно лишь время от времени и мануально. Проверка ключей на шагах k и k+1 легко обходится противником – позволяет монотонно дестроить сеть. Скорость дестроя будет ограничена лишь максимальным допустимым отклонением для I и D за один шаг (интервал времени).

    Чем ближе C к единице, а I к своему максимуму (т.е. меньшему значению между N_k и N_k+1), тем стабильнее tor-сеть.

    Пусть D = I/I_max? Индекс изменения ключей. Тогда и D будет стремиться к единице при стабильной сети.

    Поскольку ключи сравниваются каждый раз только с предыдущим шагом, позвольте мне привести пример взлома: пусть у нас на шаге k и k+1 одно и то же число совпадающих ключей, например 10. Тогда D = I/I_max = 1 (вообще никаких подозрений). Пусть на шаге k и k+1 мы имеем одно и то же общее число ключей, пусть 100. Пусть у нас 10 ключей, как уже оговорено, остаются теми же, а 90 остальных меняются от шага k к шагу k+1. при этом индекс C = 1 (также никаких подозрений). Однако, при этом клиенту полменили 90% ключей всех нод. Или я что-то попутал?

    Тогда можно подсчитать стабильность сети в самом примитивном виде как некое S=C/D

    C меняется от 0 до inf (в идеале равно 1), D от нуля до 1 (в идеале равно 1). Так?

    Чем больше единицы значение S, тем опаснее.

    Пусть C мало (куча нjд одновременно ушла в оффлайн по ср. с предыдущим шагом), и D мало (совпадающих ключей мало) – тогда S орядка 1, а атака сканала. Или я не прав?

    P. S.: unknown, я же протрезвею – я выведу вас на чистую воду! Или вы думали что вот так вот просто всё с рук сойдёт?
    Гость (24/02/2008 07:58)   
    Поскольку ключи сравниваются каждый раз только с предыдущим шагом, позвольте мне привести пример взлома: пусть у нас на шаге k и k+1 одно и то же число совпадающих ключей, например 10. Тогда D = I/I_max = 1 (вообще никаких подозрений). Пусть на шаге k и k+1 мы имеем одно и то же общее число ключей, пусть 100. Пусть у нас 10 ключей, как уже оговорено, остаются теми же, а 90 остальных меняются от шага k к шагу k+1. при этом индекс C = 1 (также никаких подозрений). Однако, при этом клиенту полменили 90% ключей всех нод. Или я что-то попутал?

    Да, проглючило меня с определениями. Атака не сработает.
    Гость (24/02/2008 08:14)   
    Кстати, вот что неправильно:
    Пусть было 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), чтобы никогда не равно было нулю.

    Ужас! Так, срочно учим математику. У нас есть 2 случайных величины. Для простоты забъём на то, зависимы они или нет. Нам нужен случай, когда обе из них отклоняются не сильно от некоего среднего. Вводим стандартное отклонение и используем МНК.
    Поскольку

    C меняется от 0 до inf (в идеале равно 1), D от нуля до 1 (в идеале равно 1).

    Поучаем: S(pinore) = (C – 1)^^2 + (D – 1)^^2.
    В идеале таким образом определённое S будет стремиться к нулю в случае стабильной сети. И чем оно больше, тем нестабильнее сеть.
    Гость (24/02/2008 08:50)   
    Вики меня не правильно поняло, имелось в виду ^ а не ^^ (я думал оно так их напишет сверху, как и подобает степеням тому быть).

    Thanks Roger. We continue a discussion on our site and our minds is overheat :-)

    Вроде только я пил, у вас-то почему мнения перегреты?

    Проверяйте, особое внимание обратите на формулы, надеюсь ничего там не попутал (Nk+1 я заменил на Nk-1: всё-таки будущего статуса у пользователя никак не может быть, а предыдущий может храниться).

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

    Написать утилиту которая реализует указанный алгоритм по оффлайновой статистикие? Несложно.

    И чё, привязываться к изменениям файлов статистики? Как мониторить-та? Или как дибилы-программеры мониторить "не появилось ли что нового" обращаясь к файлу каждые n секунд?
    Сразу скажу что я дилетант в прогерстве, но мои представления таковы что без интеграции с самим клиентом по уму это не реализовать.
    Гость (24/02/2008 09:41)   
    Вообще для каждого значения надо описать его смысловую нагрузку словами, чтобы было понятно откуда что берётся.

    С посылом согласен.

    Вообще, 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.
    • Вводим измерение относительно нулевого момента времени (средней (доверяемой) статистики).
    Я ушёл спать, смогу ответить ещё что-нибудь уже только вечером.
    — SATtva (24/02/2008 10:45)   
    Вики меня не правильно поняло, имелось в виду ^ а не ^^ (я думал оно так их напишет сверху, как и подобает степеням тому быть).

    Тогда надо так: x^^2^^.

    Thanks Roger. We continue a discussion on our site and our minds is overheat :-)

    Вроде только я пил, у вас-то почему мнения перегреты?

    s/minds/heads/ (или brains), но, на мой взгляд, это не принципиально. И если есть замечания к переводу, критикуйте, пожалуйста, последнюю версию перевода, а не первую.

    И чё, привязываться к изменениям файлов статистики? Как мониторить-та? Или как дибилы-программеры мониторить "не появилось ли что нового" обращаясь к файлу каждые n секунд?

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

    нужно сравнивать каждый шаг(t=t1) с одной и той же средней статистикой при t=0 (с шагом(t=0))

    Тогда, наверное, t=tn.
    — unknown (24/02/2008 16:47)   

    Ужас! Так, срочно учим математику. У нас есть 2 случайных величины. Для простоты забъём на то, зависимы они или нет. Нам нужен случай, когда обе из них отклоняются не сильно от некоего среднего. Вводим стандартное отклонение и используем МНК.


    Да я понимаю к чему Вы spinore и ygrek клоните, вы хотите получить красивый нормированный и симметричный критерий, который бы укладывался в "правило трёх сигм" (нам бы одной хватило для 90% вероятности) и т.д. Как будто сеть стабильна хотя бы в некотором временном интервале и есть некоторый критерий, по которому пользователи не должны сильно отклоняться.

    Во-первых, я не уверен вообще может ли он существовать и будет ли он иметь смысл.
    Можно ли будет доказать, что он показывает оптимальным образом все атаки?

    Во-вторых, я хотел применить другой подход: пользователи сравнивают показатель для одного и того же времени. Если у них (у всех) был скачок в одно и то же время, то скорее всего никакой атаки нет (или у них всё равно нет шансов её обнаружить путём нахождения различий). Далее могут статусы сравнивать. Кстати, статусы выдаются голосованием в V3 не чаще раз в 15 минут (про исключения не знаю).

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

    C и D зависимы, если вы хотите их просто так считать по отдельности, то не проблема. C можно считать не только как изменение количества ключей, но и IP-адресов, имён.
    Просто реально, есть разные случаи:

    1. Число ключей осталось тем же. Но они поменялись почти все. Самый подозрительный случай.
    2. Число ключей возросло. Если при этом число поменявшихся ключей примерно соответствует, то не так страшно. Похоже на ввод в сеть множества узлов. Но если оно при этом возросло раз в десять, есть вероятность соединиться с подставным узлом.
    3. Число ключей резко упало. Это может быть массовый останов узлов (какие-нибудь проблемы с новой версией сервера, о чём предупреждал Роджер). Это не так серьёзно, но если нам дают слишком мало узлов для выбора, то это опять подозрительно.

    Вероятность с частичным отравлением кэша статуса невелика – это слишком рискованно для противника. Пользователь может соединиться с реальным узлом и снова скачать нормальную статистику, если при этом он будет мониторить ситуацию, то он зафиксирует ещё более подозрительные колебания параметров. Для этого противник оставлять в статусе часть реальных узлов, но блокировать соединения с ними, что из файла статистики вообще не отследить. Это хорошо бы выводить из самой программы и тоже учитывать как некий коэффициент.
    — unknown (24/02/2008 16:57)   

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


    Неправильно выразился. Планировалось получить скачок между шагами, который был бы одинаков у пользователей в тот же промежуток времени.
    — ygrek (24/02/2008 17:58)   
    По-моему письмо можно отправить и сейчас как есть – с описанием идеи. С чистого листа придумать "хороший" критерий мы всё равно не сможем (даже ориентируясь на математическую красоту) – нужна практическая проверка – это потребует много времени.
    unknown, наверное вы правы, красивый идеальный критерий скорее всего работать не будет, т.к. мы имеем дело с неидеальным грубым реальным миром :) – но ведь интересно..
    Хочется в общем посмотреть статистику сети, не обязательно с точки зрения этой атаки.
    — unknown (24/02/2008 19:29)   

    unknown, наверное вы правы, красивый идеальный критерий скорее всего работать не будет, т.к. мы имеем дело с неидеальным грубым реальным миром :) – но ведь интересно..
    Хочется в общем посмотреть статистику сети, не обязательно с точки зрения этой атаки.


    Мне тоже интересно, а статистику можно изучать, никто не мешает.

    Можно наизобретать массу разных моделей и все визуализировать. Вполне возможно, что совершенно разные способы построения критериев будут работать (или не будут вообще). Вот у нас уже почти три есть. Можно было бы все три чисто навскидку сравнить.

    Возможно моя идея с одним критерием действительно неосуществима и порочна изначально.

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

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

    Если что-то получится ещё, будет повод о себе напомнить и следующее письмо отправить.
    Гость (24/02/2008 21:20)   
    Да я понимаю к чему Вы spinore и ygrek клоните, вы хотите получить красивый нормированный и симметричный критерий, который бы укладывался в "правило трёх сигм" (нам бы одной хватило для 90% вероятности) и т.д. Как будто сеть стабильна хотя бы в некотором временном интервале и есть некоторый критерий, по которому пользователи не должны сильно отклоняться.

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

    Во-первых, я не уверен вообще может ли он существовать и будет ли он иметь смысл.
    Можно ли будет доказать, что он показывает оптимальным образом все атаки?

    Для начала, нужно получить список всех атак. Потом уже ставить подобный вопрос. Пока что я увидел только одно существенное нарекание в треде: куча нод систематически включается только на определённое время суток и т.д. Касаемое конеретно этого обстоятельства нужно просто оценить: куча – это сколько процентов? 50? 5? Если на фоне общего числа нод это не великое колебание, то проблем нет, всё решается лишь выставлением ограничителя на S, который бы допускал такие суточные изменения, но не пропускал бы атаки.

    Во-вторых, я хотел применить другой подход: пользователи сравнивают показатель для одного и того же времени. Если у них (у всех) был скачок в одно и то же время, то скорее всего никакой атаки нет (или у них всё равно нет шансов её обнаружить путём нахождения различий). Далее могут статусы сравнивать. Кстати, статусы выдаются голосованием в V3 не чаще раз в 15 минут (про исключения не знаю).

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


    Неправильно выразился. Планировалось получить скачок между шагами, который был бы одинаков у пользователей в тот же промежуток времени.


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

    Вот... Только теперь-то я вас понял, могу уже конструктивно повозражать по поводу подходов :) Вы, unknown, смотрите на мониторинг этой атаки как на обычное исследование скорее, а не как на нечто, что тут же должно давать конкретный технический продукт защиты. Я же смотрю на неё скорее как практик которому нужна защита от неё и как можно скорее. В нейтральном анализе смысле различия между подходами вот каковы:
    Вы включаете "дебаг-уровень отладки" статистики и пишете пошаговые сравнения. Вы надеетесь, что задним числом сравнив свою статистику (куча фйлов, так как они обновляются относительно часто) в соответствующие времена со статистикой соседа выясните правду. Во-первых, минусы:
    • Реакция исключительно постфактум, но никогда не до.
    • Слишком много файлов и объёмов данных, которые прийдётся сравнивать.
    • Будет сложно найти кучу народа, кто согласился бы писать все скачки статистики втечение длительного промежутка времени, всего лишь ради одной-единственной атаки (а атак на тор кучу можно придумать).
    • Поптыка синхронизовывать статистику с сстатистикой соседа влекёт за собой трудности (чё, будем каждые 15 минут друг с другом файлами статистики перекидываться?).
    Вы уж меня извините, это может быть всполедствии включено как дополнительная мера "дебаг-уровня", но с практической точки зрения она пока мало чего не даёт. Мы должны думать во-первых о других и технической стороне дела, в идеале должна быть одна конопка которая будет загараться на атаку и справшивать у пользователя "что едлать? Идти или не идти дальше?" либо будет действовать в рамках заданных для неё ограничений. "Любите юзера", что называется :) Он должен выставить 2-3 разумных числа-переметра в конфиге и забыть про эту атаку – ему нужно пользоваться тор-сетью а не изучать статистики(!).

    Теперь смотрим то что я предлагаю:
    • Сравниаем друг с другом только среднюю статистику. Её можно сравнивать иногда, например раз в месяц (не думаю что за месяц сильно меняется число узлов в сети тор). При попытке мониторить атаку заранее нам уже не нужно каждые 15 минут обмениваться файлами статистики – достаточно раз в месяц этого сделать. А это уже куда легче технически.
    • Когда происходит атака, я её могу засчеь в реальном времени и остановить программу, я её обнаруживаю до, а не после.
    • Предложенная схема не сложнее вашей, но она уже технически дорабатываема до уровня конкретной реализации и будет реально давтаь разумную защиту при небольшом геморрое.
    Поэтому я предлагаю начать с простого: сделаем сравнение с "трастед-средним", а уже потом будем смотреть на динамику (это что вы предлагаете).

    Самый концептуальный момент – в том, что равняясь на среднее всегда самому уединённо видно, есть лиатака и что происходит с сетью, а равняясь на предыдущий шаг, видно лишь малое отклонение, из которого ничего толком заключить нельзя (ибо надо смотреть уже на совокупную динамику за массу предыдущих шагов по уму, я по сути предложил лишь упрощённый вариант – сравниваемся с начальным моментм времени). Вы поймите, что атака не обязательно есть марковский процесс (на шаге k всё ништяк а на шаге k+1 противник ввёл все свои фиктивные нод или что-то подобное), проивник может сделать её немарковской, и предполагая что вы включили защиту от неё заранее, постепенно впрыскивать ноды пока не доведёт вашу итоговую статистику до до уровня нужной для атаки (а поскольку в реальном времени вам не удобвно сравниться с сосдеями каждые 15 минут, вы вообще ничего не заметите. Я уж не говорю о том, насколько легко/трудно противнику будет понять, с кем вы сравниваете статистику а с кем нет, а то он может прдделывать её для группы связянных друг с другом пользователей).

    Просто реально, есть разные случаи:
    Число ключей осталось тем же. Но они поменялись почти все. Самый подозрительный случай.
    Число ключей возросло. Если при этом число поменявшихся ключей примерно соответствует, то не так страшно. Похоже на ввод в сеть множества узлов. Но если оно при этом возросло раз в десять, есть вероятность соединиться с подставным узлом.
    Число ключей резко упало. Это может быть массовый останов узлов (какие-нибудь проблемы с новой версией сервера, о чём предупреждал Роджер). Это не так серьёзно, но если нам дают слишком мало узлов для выбора, то это опять подозрительно.

    Давайте ближе к Земле и практике:
    Какая из этих атак не отлавливается посредством измерения S = (C – 1)2 + (D-1)2?

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

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

    По-моему письмо можно отправить и сейчас как есть? С описанием идеи. С чистого листа придумать "хороший" критерий мы всё равно не сможем (даже ориентируясь на математическую красоту)? Нужна практическая проверка? Это потребует много времени.

    Чего бояться, дорабатываем до нормально состояния письмо с учётом поправок и отправляем. Предложив хотя бы что-то мы упрощаем задачу разработчикам тор. В добавке укажем: "Это наше предложение, может быть вы увидите ошибки в его конструкции и придумаете что-то своё, лучшее".
    Гость (24/02/2008 21:24)   
    Возможно моя идея с одним критерием действительно неосуществима и порочна изначально.

    Можно строго показать что почти для любой куйни достаточно одного числа для оценки и оно называется МНК. Самих величин может быть хоть миллиён (просто надо будет в общем случае понять как сконструировать правильные случайные величирны из того что наблюдаем а потом применить уже к ним МНК).
    — Vadim_Z (24/02/2008 22:09)   
    Spinore дело говорит. Средние всегда надёжнее чем значения случайных величин, в том числе и в динамике.

    Тот метод, который предлагается, называется средним по скользящему окну (sliding window average).
    Идея в том, что усредняются характеристики за время от T-dT до T, где dT-ширина окна. Такие методы применяются
    также в техническом анализе (статистика рынков валют и акций). Метод работает потому, что в большом количестве случаев
    системы эргодичны (т.е. среднее "по ансамблю" совпадает со "средним по времени").

    Кроме того, spinore предлагает брать средние на нескольких временных масштабах (разных dT). Это связано с тем,
    что система узлов сети Tor имеет несколько характерных времен (суточные колебания, и т.п.). Поэтому это тоже здравая идея.

    Естественно константы (ширины окон, пороговые значения отклонений средних) надо выбирать аккуратно. Здесь место и для
    теоретических исследований, и для экспериментов. Есть где unknown-у развернуться :)

    Да, я думаю, что можно считать не только средние, но и дисперсии. Аномальные значения тоже могут свидетельствовать об
    атаке.
    — unknown (24/02/2008 23:21)   

    Мы должны думать во-первых о других и технической стороне дела, в идеале должна быть одна конопка которая будет загараться на атаку и справшивать у пользователя "что едлать? Идти или не идти дальше?" либо будет действовать в рамках заданных для неё ограничений. "Любите юзера", что называется :) Он должен выставить 2-3 разумных числа-переметра в конфиге и забыть про эту атаку – ему нужно пользоваться тор-сетью а не изучать статистики(!).


    spinore, Вы уже пытаетесь мне втолковать тоже, что и Роджер, я это понимаю прекрасно. Я согласен, это идеально было бы.

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

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

    Тут важно то, что можно выявить "левые" ключи и после сравнения статусов от всех добровольцев за один период времени выявить у кого есть "левые" статусы и предъявить этот "обвинительный" документ как доказательство нечестности DA. Что-то вроде наблюдателя на выборах.

    Ещё одно рабочее упрощение: атака проводится только за один шаг (максимум несколько). В расчёте, что "delayed partial cache poisoning" почти невозможен, если пользователь может на следующем шаге снова скачать правильный статус с правильного зеркала.

    Ну допустим, две тысячи узлов. Противник вбросил или заменил 200 виртуальных фальшивых и "разместил" на них "более свежие статусы", в расчёте, что пользователь их скачает и в каждом новом статусе он будет заменять по только по двести узлов, а не все сразу.

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



    Теперь смотрим то что я предлагаю:

      • Сравниаем друг с другом только среднюю статистику. Её можно сравнивать иногда, например раз в месяц (не думаю что за месяц сильно меняется число узлов в сети тор). При попытке мониторить атаку заранее нам уже не нужно каждые 15 минут обмениваться файлами статистики – достаточно раз в месяц этого сделать. А это уже куда легче технически.
      • Когда происходит атака, я её могу засчеь в реальном времени и остановить программу, я её обнаруживаю до, а не после.
      • Предложенная схема не сложнее вашей, но она уже технически дорабатываема до уровня конкретной реализации и будет реально давтаь разумную защиту при небольшом геморрое.

    Поэтому я предлагаю начать с простого: сделаем сравнение с "трастед-средним", а уже потом будем смотреть на динамику (это что вы предлагаете).



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

    2 Vadim_Z, я об этом тоже подумал. Только в этом реально можно увязнуть.

    Сеть tor статистически ближе к поведению толпы людей, а то что мы можем померить – это как биржевой курс. Мы посчитаем среднее, а он возьмёт и скакать начнёт, или обвалится, или офигенно стабилизируется в зависимости от чьих-то настроений или обстановки в мире. Завтра в Германии или где-то примут новый закон, все операторы перепугаются и куча нод отрубится. После завтра закон понаставят кучу новых нод с новой альфа-версий. После-после завтра в этой версии найдут баг, узлы отключаться, наши средние критерии опять уедут.


    Давайте ближе к Земле и практике:
    Какая из этих атак не отлавливается посредством измерения S = (C – 1)2 + (D-1)2?


    Да мне Ваш S чисто внешне больше нравится, я понимаю, что он формально более правильный, универсальный и в него при необходимости можно понапихать сколь угодно много параметров.

    Не учесть таким универсальным способом, что когда C и D сильно скачут это плохо, но ещё хуже когда есть определённые корреляции между ними в этих скачках. Причём некоторые корреляции – "хорошие" или "смягчающие" друг друга (немного увеличилось число узлов, но и количество изменившихся ключей возросло на столько же, а если C и D одновременно в сторону уменьшения, то это ещё лучше, а снижение ниже некоторого предела – опять плохо, это вообще отдельный параметр должен быть), а некоторые корреляции "плохие" (если C и D ползут в разные стороны, то это хуже; уменьшение D – это в принципе хуже, чем увеличение C и т.д.).

    Т.е. при разных соотношениях C и D мы имеем разные состояния системы. Причём смену IP адресов тоже надо учитывать (не знаю как).

    Если вам ближе физические аналогии (тут меня можете смело поправить если слишком наивно): Вы пытаетесь просто рассмотреть все параметры, как независимые, не имеющие взаимосвязи или конкретного смысла.

    Я же попытался представить некую модель системы, на которую действуют разные факторы, ну как например температура и давление. Как если бы мы ожидали, что при опредлённом давлении будет опредлённая температура внутри какой-то установки или реактора, которые мы полностью не контролируем (не зная точного закона изменения, а только на основании предшествующих на один-два шага данных), а если получается слишком большое и резкое расхождение c ожидаемым, значит система стала нестабильной.

    Только, это также неблагодарно как считать прогноз экономический, политический, поведенческий когда все факторы работают только приблизительно.
    — ГОСТЬ (25/02/2008 01:46)   
    СПАСИБО ВАН ЛЮДИ)) НО? Не могли бы вы сделать типа статистики? За-тор безопасен! Против-нетЯ и многие юзающие ТОР не так просветлены как многие тут! И очень много НАРОДУ желает всеж выслушать ВАШЕ мнение! Если есть подозрения то? КОМПЛЕКС МЕР по защите от знающих людей ТУТ бы не помешал бы я думаю)
    Гость (25/02/2008 02:08)   
    Но он высказал и свои сомнения по поводу этого: слишком чувствительные настройки? Много ложных срабатываний, слишком грубые? Можно пропустить атаку.

    Уже обсуждали много раз. Опция для параноиков, и после исследований средних и дисперсий возможно включим уже для всех. Для начала она в любом случае будет как для параноиков, какая бы она не была.

    Я предлагаю паралелльную идею? Временно отказаться от построения реальной защиты и заменить её на коллективный аудит, основанный на сообществах заинтересованныхх пользователей

    А нафига?? Если то что я предлагаю не сложнее, но зато сразу заземляется? А куда ваш аудит пришить? Кто этим будет заниматься? Ну и по сути, "случайная величина"... её ни к чему не пришить, и она легко обходится.

    Тут важно то, что можно выявить "левые" ключи и после сравнения статусов от всех добровольцев за один период времени выявить у кого есть "левые" статусы и предъявить этот "обвинительный" документ как доказательство нечестности DA. Что-то вроде наблюдателя на выборах.

    Так не вопрос – добавляем ещё одну дебаг-опцию в конфиг и пишем: сохранять все скачанный статусы, с пометкой их времени. Потом заним числом можно понять, какие ключи что и у кого.

    Ещё одно рабочее упрощение: атака проводится только за один шаг (максимум несколько). В расчёте, что "delayed partial cache poisoning" почти невозможен, если пользователь может на следующем шаге снова скачать правильный статус с правильного зеркала.

    А что, delayed partial cache poisoning это что-то слишком экстраординароное? И покажите мне почему мой подход её не отловит, а то я это в упор не вижу. Повторяю – среднее апгрейдится время от времени мануально. Ща по пгп обращусь к тому кого знаю лично, попрошу запустить тор и скачать, или ещё чё-нить подобное сделаю. И буду изучать, действительно ли статистика за это время поменялась так как как мне предъявляет сервер.

    Если кого ввёл в заблуждение, "средняя статистика" – это не усреднение в обычном смысле по статистикам. Это просто одна какая-то статистика, которую мы проверили по разным каналам и стали ей доверять. Правильнее было бы её называть доверяемой статистикой. Но посольку если бы мы знали истиное среднее в отсутствие ататки, можно было бы сравнивать с ним (но мы его не знаем и знать не будем), вот потому по аналогии я и гвоорю что "среднее". В письме лучше напистаь trasted конечно, чтобы не вводить никого в заблуждение.

    Меня ещё поправили что S в моём опредлении не есть дисперися, а всего-навсего "отклонение" от trusted-статистики, которая по опр. полагается верной для t=0.

    Ну допустим, две тысячи узлов. Противник вбросил или заменил 200 виртуальных фальшивых и "разместил" на них "более свежие статусы", в расчёте, что пользователь их скачает и в каждом новом статусе он будет заменять по только по двести узлов, а не все сразу.

    Ну и почему мой метод не сработает? Изучим статистику и поймём праивльные коэффициенты которые в норме никогда не превышаются.

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

    Нет, не обойдёт :) Пример в студию. Коэффициенты подбираются так, чтобы суточные колебания пропустить а атаку – нет.

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

    См. определение выше. Я очень аккуратно описал что я понимаю под этим термином в том посте где писал конфиг для, опираясь на моё понимание того ка как работает тор. Жалко, что никто внимательно тот пост вы не прочитали. Она не имеет прямого отношения с реальным средним по релаьной сети(!), потому что мы не можем гарантировать что "ататки не было".

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

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

    Не учесть таким универсальным способом, что когда C и D сильно скачут это плохо, но ещё хуже когда есть определённые корреляции между ними в этих скачках. Причём некоторые корреляции ? "хорошие" или "смягчающие" друг друга (немного увеличилось число узлов, но и количество изменившихся ключей возросло на столько же, а если C и D одновременно в сторону уменьшения, то это ещё лучше, а снижение ниже некоторого предела? Опять плохо, это вообще отдельный параметр должен быть), а некоторые корреляции "плохие" (если C и D ползут в разные стороны, то это хуже; уменьшение D? Это в принципе хуже, чем увеличение C и т.д.).

    Мы измеряем не корреляции, в вероятность атаки. Уклонение от trusted всё это прекрасно ловит.

    Т.е. при разных соотношениях C и D мы имеем разные состояния системы. Причём смену IP адресов тоже надо учитывать (не знаю как).

    Они физически разные, но с точки зрения вероятности атаки несут угрозу с одинаковой вероятностью.

    Если вам ближе физические аналогии (тут меня можете смело поправить если слишком наивно): Вы пытаетесь просто рассмотреть все параметры, как независимые, не имеющие взаимосвязи или конкретного смысла.

    ЦПТ и ЗБЧ ещё никто не отменял ©
    Гость (25/02/2008 02:42)   
    Пока он ещё в процессе обсуждения :)

    2 SATtva: мы должны прийти к единому выводу, тогда и приверим ещё раз ваше письмо на предмет как соответствия "физике", так и "языку". Пока я хочу успокоить unknown'а :) То ли я запутал всех своими терминами (сорри если что), то ли кто-то упорно тупит, не могу понять.

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

    • На данный момент мы не знаем реальных коэффициентов и реальной статистики, но предположим что наш метод работает. Сразу оговариваюсь что будет оставлено за кадром на будущие доработки впоследствии, и что обсуждаться не будет:
      • Искусственное введение нод в оффлан.
      • Суточные колебания (предполагаем что сеть однородна по времени)
    • Вначале мы скачиваем свою самую первую статистику с тора, и изучаем её на предмет отличия от статистики, которую скачали запустив свой тор-клиент наши соседи. Пытаемся добыть статистику разными путями и сраниваем её. Если анонмальных отклонений между статистиками не обнаружено, запускаем тор. Называем таким образом назначенную статистику трастед-статистикой, и полагаем её верной для t=0.
    • Определяем коэффциеинт S равный числ заведомо большему, чем нужно, чтобы защита на него не срабатывала. Испольузем тор и пишем статистику. Наш клиеент каждые 15 минут выкачивает статистику, сранивает её посредсвом отклонения S с тратсед-статистикой и извещает нас о коэффициенте отличия. Все отличя мы пишем (хотя имея все файлы статистики их можно выудить и оттуда). Таким образом, мы работаем со случайной величиной, которая принимает значения S равные отклонению текущего скачанного от трастед.
    • Отклонение S определяется как S = (C-1)2 + (D-1)2, где C и D определяются как сказал unknown, но(!), не между сосденими по времени скачанными статистиками, а между только что скачанной и трастед-статистикой.
    • Изучив за месяц коэффициенты, обдумываем то что получили. Берём свою последнюю скачанную за месяц статистику и сраниваем её со статистикой соседей. Если аномальных отклонений нет, переопределяем: трастед = последняя статистика, и у нас начинается следующий месяц.
    • По желанию включаем уровень дебаг, который позволит нам сохранять всю статистику что мы выкаичваем с сети тор. Если будут обнаружены аномалии, мы задним числом выясним кто пожписал статистику и что там за ключи.
    • Программа настраивается так же как и я описал ранее: работая с коэффициентами, включёнными в конфиге тор-клеинт останавливает работу, если S на какой-то скачке превысило допустимое указанное в конфиге значение.
    • Включение красной кнопки "для всех", будет сводиться лишь к раскомменичванию ряда опций из тех что я уже предложил, и выставлению правильных коэффициентов, полученных энтузиастами после "изучения на сырую" статистики тор.
    • Целью всего этого является попытка снять катастрофичную привязку к авторитету DA. Если все будут работать с трастед-статистиками и сраниваться друг с другом, DA не сможет сделать вообще ничего, ибо каждый её шаг вперёд будет зависеть от всех предыдущих. Так что, единственный раз, еслди в условный начальный момент времени все юзеры запаслись правильной статистикой и DA им ненаврал, то далее DA вообще не сможет дезынформировать пользователй. – Да, именно поэтмоу я отказался от форсирования включения тор-нод в PGP-сеть доверия, сказав что наша модель достаточна для отражения атаки.
    • Впоследствии схему можно доработать с учётом реальностей сети тор, всё вышепредложенное – как самый первый шаг, что предлаагем Роджеру.
    • Конфиг который я писал ранее почти полностью годится для, и легко дорабатывается с учётом позже сказанной критики. Его можно было бы включить в мэйл.

    Я уже очень устал переливать из пустого в порожнее, так что критику просьба пистаь конструктиную: конкретная атака, которую предложенная выше схема не ловит, и она не оговорина в спике того, что пока я осталяю за кадром.
    Гость (25/02/2008 02:44)   
    Пока он ещё в процессе обсуждения :)

    Это ответ Гостю на

    КОМПЛЕКС МЕР по защите от знающих людей ТУТ бы не помешал бы я думаю)
    — Vadim_Z (25/02/2008 03:18)   
    Я же попытался представить некую модель системы, на которую действуют разные факторы, ну как например температура и давление. Как если бы мы ожидали, что при опредлённом давлении будет опредлённая температура внутри какой-то установки или реактора, которые мы полностью не контролируем (не зная точного закона изменения, а только на основании предшествующих на один-два шага данных), а если получается слишком большое и резкое расхождение c ожидаемым, значит система стала нестабильной.

    Насколько я понимаю, реальные системы управлением реактора строятся на сравнении измеряемых параметров с проектными. Строить реактор с заранее неизвестными характеристиками — самоубийственно.

    Ув. Spinore невольно ввёл меня в заблуждение своим определением "средних". В действительности он не предлагает "скользящее среднее", а просто "скользящую точку отсчёта".
    Трудность усреднения понятна. Для того, чтобы использовать статистику и моменты от неё, нужно иметь период, за который можно ручаться, что статистика верна. Поэтому на первом шаге вместо усреднения можно использовать сверенную независимым способом статистику в начальный момент времени, по методу spinore. Когда пройдёт определенный период времени, т.е. размер окна усреднения, можно уже переходить на "скользящее среднее" (и высшие моменты). Далее положение окна будет плавно сдвигаться, по мере обновления данных о серверах tor-сети. Периодически статистика должна кросс-верифицироваться между пользователями.
    Преимуществом усреднений будет меньшее количество ложно-положительных срабатываний системы. Недостаток является продолжением достоинства — будет меньшая чувствительность к немонотонным вбросам, впрочем, на монотонные вбросы оно не повлияет. Нельзя забывать и о большей технической сложности критерия с усреднением по сравнению с предложением spinore. Можно поэтому рассмотреть схему с усреднением как следующий этап.
    Гость (25/02/2008 03:28)   
    P. S.: Да, кстати vadim_z по роду основной деятельности занимается реакторным материаловедением (хоть и не теплогидравликой, на которую указал unkown), так что комментарий уместен :)
    — unknown (25/02/2008 03:31)   
    spinore, думаю Ваш вариант можно принять пока за основной, про пошаговое измерение динамики и многопользовательский аудит постфактум упомянуть более коротко, как альтернативу. Всё-таки интересно: подход с двух сторон.

    Разработчики неоднократно говорили, что собирают статистику сети, они могут наверное сразу сказать насколько реально то или другое.
    Гость (25/02/2008 03:37)   
    spinore, думаю Ваш вариант можно принять пока за основной

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

    Ну чё, мне тогда попытаться доработать итоговое письмо с учётом всех правок?
    — unknown (25/02/2008 04:00)   

    если есть существенные недоработки в схеме, которые стоило бы учесть в первом шаге на пути к истине, то пишите.


    Как бы связность C и D между собой внести?



    Ну чё, мне тогда попытаться доработать итоговое письмо с учётом всех правок?


    Можете всё письмо или хотя бы внести абзацы с описанием Вашего метода.
    Гость (25/02/2008 04:19)   
    Как бы связность C и D между собой внести?

    Нам в первом приближении вообще всё равно – скоррелированы C и D или нет. Общие формулы это не отменяет.

    Можете всё письмо или хотя бы внести абзацы с описанием Вашего метода.

    Завтра будет. Сегодня уже – баиньки :)
    Гость (25/02/2008 04:51)   
    Ох большая тема. В кратком изложении Spinore я согласен с его моделью – без перекресной проверки ключей и статусов остальное будет полумерами удаляющими от грамотного решения.

    Сразу оговариваюсь что будет оставлено за кадром на будущие доработки впоследствии, и что обсуждаться не будет:
    Искусственное введение нод в оффлан.

    А что под этим будет пониматься:
    оппонент оставляет доступ для подключения к ентри-ноде только к подконтрольным нодам, остальное блокирует на стороне провайдера
    или
    оппонет банально досит (или закрывает ноды использую административный ресурс) неподконтрольные ноды так что цепочки строятся через вражеские ноды.

    В первом случае это сразу обнарудится по статусам (для всех ноды работают для вас нет).
    Во втором не знаю как грамотно сделать. Допустим ориентироваться на график работы каждой ноды на прошлый период, например если пойдет массовое отключение нод раньше никогда не отключавшихся, но нереагировать на появление/пропадания ноды если это укладывается в ее средний график работы (днем работает ночью выключена или наоборот) + стараться "разумно" использовать в цепочках спонтанно появляющиеся ноды (в масштабе всей сети нода должна наработать себе статистику, неделю-месяц, после чего ей условно можно доверять и использовать в цепочках) – во всякомслучае это избавит от вброса большого колич вражеских нод (например зарядили ботнет).
    Гость (25/02/2008 05:23)   
    Сразу оговариваюсь что будет оставлено за кадром на будущие доработки впоследствии, и что обсуждаться не будет:
    Искусственное введение нод в оффлайн.

    А что под этим будет пониматься

    Вообще, строго говоря это терминология unknown'а – он лучше ответит что подразумевал, но мне казалось что вот это:

    или закрывает ноды использую административный ресурс

    хотя, мб вы привели более общий случай.

    P. S.: задача пока бьётся на модули и мы разбирамеся с самым первым из них. Далее судя по ответу Роджера будем думать как доработать схему. Не надо сразу за звёзды, надо постепенно, а то замахнувшись на всё, не получим и малого.

    Допустим ориентироваться на график работы каждой ноды на прошлый период, например если пойдет массовое отключение нод раньше никогда не отключавшихся, но нереагировать на появление/пропадания ноды если это укладывается в ее средний график работы (днем работает ночью выключена или наоборот)

    Теоретически звучит хорошо, но как это будет выглядеть технически мне совершенно не понятно. Лично изучить несколько сотен нод и их график? А насколько он устойчив/меняется?

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

    А вот эта идея очень интересная.. мне нравится :) Выглядит как тривиальная защита от атаки которую мы рассматриваем (только для начала всё равно прийдётся с нескольких различных площадок набрать статистику тора, чтобы потом было на что ориентироваться). Если бы нод было очень много, то ваш критерий работал бы и был разумен для всех (выкидывание малоизвестных нестабильных нод не повлияло бы на анонимность). Что же касается текущего статуса сети – это может привести к катастрофическому снижению числа нод и, соответственно, падению анонимности (но точно я здесь не скажу, может быть кто из наших торокопателей ответит). Кстати, если стабильных узлов – подавляющее большинство, то как первая контрмера можно внести их список в конфиг (в список узлов, разрешённых для цепочек и запретить все остальные).
    Гость (25/02/2008 05:26)   
    В первом случае это сразу обнарудится по статусам (для всех ноды работают для вас нет).

    Тогда уж вы придумайте как детектировать такую атаку apriori, а не aposteriori.
    — SATtva (25/02/2008 11:03)   
    А нафига?? Если то что я предлагаю не сложнее, но зато сразу заземляется? А куда ваш аудит пришить? Кто этим будет заниматься? Ну и по сути, "случайная величина"... её ни к чему не пришить, и она легко обходится.

    spinore, разница, как я уже отмечал, в степени привязки к Tor-клиенту. Ваше решение обязано быть реализовано только в коде клиента. Я сомневаюсь, что разработчики за это возьмутся: в лучшем случае скажут "send a patch", в худшем проигнорируют. Другое дело, если сейчас отправить это предложение, самим реализовать утилиту для аудита, как сделал ygrek, собрать статистику при разных вводных величинах (изменения в статистике ведь можно и вручную в офлайне моделировать, вставляя и удаляя собственные записи в status-файле дополнительным скриптом) и затем уже представить её разрабам: хотели доказательства эффективности? вот они. Если подобный аналитический подход (независимо от конкретной модели — Вашей, uknown'а или ygrek'а) реально сможет детектировать аномальные изменения в статусах узлов, разработчики сами закодят его в Tor. А так нам остаётся только бить себя в грудь, мол, прислушайтесь к нам, мы дело говорим.

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

    Всё, что Вы далее описываете, можно (и нужно) реализовать в виде сторонней утилиты. Это называется dry-run, когда программа только имитирует своё реальное поведение: собирает статистику, выводит в собственный лог сигналы об обнаружении аномальных с её точки зрения случаях и т.д. Это именно то, что следует передать разработчикам для анализа. Пока всё, что мы здесь рассматриваем — чистая теория. Будь я на месте Роджера (в разработке я немного понимаю), я бы не включил это даже в нестабильную ветку (тем более, что писать реализацию, будь я на месте Роджера, пришлось бы мне ;-).

    Замечу, я не критикую ни одну из предложенных моделей, они на мой взгляд просто разные и предназначены для разных целей; могли бы и дополнять друг друга; возможно, на их основе можно было бы вычислять и некоторую "мета-оценку"... Моя критика направлена только на избранный spinore'ом подход: первостепенную реализацию в Tor-клиенте. Я не вижу это реалистичным.
    — unknown (25/02/2008 14:22)   

    Я не подразумевал брутального соглашательства...


    Остаётся: небрутальное соглашательство, брутальное несоглашательство, небрутальное несоглашательство ;-)
    причём последний вариант самый бредовый.


    Нам в первом приближении вообще всё равно – скоррелированы C и D или нет. Общие формулы это не отменяет.


    Вот тоже четыре варианта. Представим, что C и D – это нечто вроде спроса и предложения на рынке, которые в идеале должны
    быть стабильны и сбалансированы и немного плавно расти.

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

    Имеет ли смысл изучать такие величины отдельно друг от друга?


    Моя критика направлена только на избранный spinore'ом подход: первостепенную реализацию в Tor-клиенте. Я не вижу это реалистичным.


    Мне чего-то тоже кажется, что они там между собой тоже подумали (более вяло чем мы) и решили, что мороки много, толку мало.
    Всё равно это полумера или костыль, не устраняющий недостаток самого протокола.

    А так, оба варианта в урезанном виде можно смоделировать и вне tor-клиента. Просто не будет готового к применению решения, а только исследование.
    — ent1 (25/02/2008 16:21)   
    Теоретически звучит хорошо, но как это будет выглядеть технически мне совершенно не понятно. Лично изучить несколько сотен нод и их график? А насколько он устойчив/меняется?

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

    (только для начала всё равно прийдётся с нескольких различных площадок набрать статистику тора, чтобы потом было на что ориентироваться).

    Проблему начальной статистики присутствует во всех предложенных схемах. Здесь имхо прийдется придумывать мехинизм отденый от тора.

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

    Почему?
    Нестабильность я рассматриваю как появление ноды с новым ключем на небольшой промежуток времени – появилась нода, поработала пару дней и пропала. Потом на том же ip может появиться нода с другим ключем.
    Если же нода в течении месяца работает по 2-3 часа в вечернее время, то условно такую ноду можно считать стабильной, со своим определенным коэффициентом стабильности во времени.
    Если нода в течении месяца работает в хаотическом режиме, то она тоже считается стабильной, со своим коэф стабильности.

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

    Связываться с анализом работоспособности ноды во времении я вижу смысл только если есть задача определить целенаправленно выведение из рабочего состояния нод в масштабах всей сети. Иначе перекресной проверки вполне достаточно.

    В идеале допустим у нас есть график доступности ноды за весь предыдущий период ее существования. Из этого графика вытягиваем статистику:
    1. как часто включатеся/выключается нода
    2. среднее и максимальное время недоступности
    3. корреляцию времени работы (нода может постоянно работать, нода может работать в строго определенное время, нода может работать хаотически)

    Можно обрабатывать изменение режима работы ноды – если нода раньше работала только в опр часы а начала работать постоянно это нужно как-то учесть.
    Можно предложить людим поднимающим ноды указавать референсный режим работы и обрабатывать отклонение от этого режима.

    Я понимаю, все эти действия могут привести к непредсказуемым результатам, но они не будут сказываться на работе самой сети тор! Это будут действовать только на клиента решившего самостоятельно настроить для себя модель анализа поведения нод.

    Тогда уж вы придумайте как детектировать такую атаку apriori, а не aposteriori.

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



    Всё, что Вы далее описываете, можно (и нужно) реализовать в виде сторонней утилиты. Это называется dry-run, когда программа только имитирует своё реальное поведение: собирает статистику, выводит в собственный лог сигналы об обнаружении аномальных с её точки зрения случаях и т.д. Это именно то, что следует передать разработчикам для анализа.

    А можно так посмотреть на это в клиенте тора уже есть возможность работать как DA, все что нужно для обмена статистикой и статусами есть. Положим врикручивать "эвристический" анализ работы нод во времени это бесперспективно для самих разработчиков пока не будет хотябы работающей можели. НО перекресную проверку нужно сделать ОБЯЗАТЕЛЬНО!

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

    Пока всё, что мы здесь рассматриваем — чистая теория. Будь я на месте Роджера (в разработке я немного понимаю), я бы не включил это даже в нестабильную ветку (тем более, что писать реализацию, будь я на месте Роджера, пришлось бы мне ;-).

    Можно долго и нудно что-то доказывать человеку, приводить статистику, аналитические выкладки и тд, и все равно не убедить если ему не понравится идея, соотв реализации не будет.
    С другой стороны если он проникнится идеей и она покажется ему интересной и нужной, то убеждать не прийдется.
    Я не программист, к сожалению, и написать рабочий код не смогу – хотя могу прочесть чужой код и даже написать что-то для обсчета своих данных на уровне институтских знаний :( но показывать другим такое нельзя ;)

    PS Прошу прощения за несвящанность мыслей, месагу набирал урывками в течении трех часов :)
    — SATtva (25/02/2008 16:54)   
    Еще у нас не получится показать работу модели при реальной атаке, тк мы рассматриваем теоретическую атаку какие еще не было, и максимум сможем показать на реальных данных что наши формулы не дают ложных тревог при обычной работе сети. Готовый код для клиента тор думаю никто из нас не напишет.

    Я писал выше, как смоделировать атаку. В конце концов, как Tor-клиент, так и гипотетическая утилита берут входные данные из статус-файла. Целенаправленная модификация этого файла (вручную или автоматически) с петтарнами, примерно соответствующими модели атаки, должна показать эффективность защиты (ну, или неэффективность). А без тест-кейсов даже готовый патч для Tor-клиента не сможет показать свою эффективность.
    Гость (26/02/2008 01:44)   
    Как бы связность C и D между собой внести?

    ...+k*(C-D)2 ?
    Гость (26/02/2008 04:14)   
    Я щас напилсо, так что ничё конкретного сказать не могу

    с ЭБУ ОБРЙМУП, ФБЛ ЮФП ОЙЮ?

    Очень трудно попадать по клавишам.


    Да, заметно :-)

    Да, отмечал окончание работы над которой работал последний год [можете поздравить :)] – только что появилась в свободном доступе[link14]. Кстати, vadim_z[link15] в соавторах :)
    Гость (26/02/2008 06:55)   
    spinore, разница, как я уже отмечал, в степени привязки к Tor-клиенту. Ваше решение обязано быть реализовано только в коде клиента.

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

    Я сомневаюсь, что разработчики за это возьмутся: в лучшем случае скажут "send a patch", в худшем проигнорируют.

    ent1 уже ответил. Давайте напишем так, как будто это атака важна и попытаемся внятно что-то предложить. Далее можно поглядеть на реакцию разработчиков.

    Другое дело, если сейчас отправить это предложение, самим реализовать утилиту для аудита, как сделал ygrek, собрать статистику при разных вводных величинах (изменения в статистике ведь можно и вручную в офлайне моделировать, вставляя и удаляя собственные записи в status-файле дополнительным скриптом) и затем уже представить её разрабам: хотели доказательства эффективности? Вот они.

    Какой бы ответ разработчиков не был – он не помешает нам написать такую утилиту и анализировать траффик, на данный же момент обсуждает что им говорить. Я не вижу ничего предосудительного в том, чтобы грамотно изложить свою простенькую теорию и метод защиты от атаки. Неужто вы предлагаете вообще ничего не отвечать и ждать пол года пока наберётся статистика и кто-то оформит всё в виде красивых графичков в pdf'ке с объяснениями? Нас никто не заставляет выкабениваться перед разработчиками: есть идея – пришли, сказали.

    Если подобный аналитический подход (независимо от конкретной модели? Вашей, uknown'а или ygrek'а)

    Это не разные "модели", и не надо делать явных подмен. Я предложил некую вещь, котрая реально будет работать если протокол таков как сказал unknown. Пока я не вижу ни одного поста после опубликования короткой сводки, где бы мне написали пример атаки, которую он не ловит. Есть претензии – пример атаки в студию. Что же касается unknown'а и его сравнений соседних шагов, в этом нет ничего физичного – по кр. мере я на данный момент не вижу как придать разумный смысл таким сравнениям. Благо, что сравнения соседних шагов пропускают замедленное инфицирование тор-кэша, а тем самым и соответствующую атаку от которой мы пытаемся защититься. Всё что остаётся от модели unknown'а после выкидывания сравнения соседних шагов – это дебаг-уровень – писать всю статистику для возможности последующего её сравнения, но это и я предложил – одна опция в конфиге и делов-то... Заметим, что изначально я предлагал написать старонний скрипт, который сможет сравнивать любые две статистики – хоть соседние, хоть в год разницы между ними. тор-клиент лишь должен вызывать подобный скрипт после скачки статистики для того чтобы уметь априори прореагировать на атаку.

    А так нам остаётся только бить себя в грудь, мол, прислушайтесь к нам, мы дело говорим.

    Если мы априори примем модель "разработчикам наплевать на собственный проект" – то да, можно вообще ничего не писать – вы правы.

    Всё, что Вы далее описываете, можно (и нужно) реализовать в виде сторонней утилиты. Это называется dry-run, когда программа только имитирует своё реальное поведение: собирает статистику, выводит в собственный лог сигналы об обнаружении аномальных с её точки зрения случаях и т.д. Это именно то, что следует передать разработчикам для анализа.

    Вначале письмо, а потом – всё остальное, продолжение, так сказать. Следует работать в кооперации с разработчиками – это продуктивнее, а не показывать свои "предъявы" когда нет на то никакой реальной необходимости.

    Будь я на месте Роджера (в разработке я немного понимаю), я бы не включил это даже в нестабильную ветку (тем более, что писать реализацию, будь я на месте Роджера, пришлось бы мне ;-).

    Для начала они могли бы реализовать хотя бы часть предложенного – пусть тор-клиент выводит сравнение скачанной статистики с трастед-статистикой, но не реагирует. Хотя бы что-то для начала.

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

    SATtva, я уже ответил: приведите пример атаки, котора не ловится моим методом+включение дебаг-уровня, когда ппишется вся статистика. А потом мы поговорим о взаимном дополнениии того что не ловит мой метод, зато ловит метод unknown'а (когда будут конкретные примеры). Вообще, вам уже стороние люди написали что надо сравнивать всё действительно с нулевой точкой отсчёта а не между соседними шагами по времени.

    Моя критика направлена только на избранный spinore'ом подход: первостепенную реализацию в Tor-клиенте. Я не вижу это реалистичным.

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

    Имеет ли смысл изучать такие величины отдельно друг от друга?

    В первом приближении? Думаю, нет. А до следующих приближений мы пока не добрались. Если есть подозрения что что-то не так – пишите реальный пример атаки которая должна ловиться алгоритмом и не ловится и тогда будем дорабатывать модель снова. Я пока такую атаку не вижу.

    Мне чего-то тоже кажется, что они там между собой тоже подумали (более вяло чем мы) и решили, что мороки много, толку мало.

    Всё нормально. Сейчас самое то изложить свои наработки, только надо постараться по-максимуму понятно это сделать.

    Всё равно это полумера или костыль, не устраняющий недостаток самого протокола.

    Вроде устраняет. Цитирую[link16]:

    Если все будут работать с трастед-статистиками и сраниваться друг с другом, DA не сможет сделать вообще ничего, ибо каждый её шаг вперёд будет зависеть от всех предыдущих. Так что, единственный раз, еслди в условный начальный момент времени все юзеры запаслись правильной статистикой и DA им ненаврал, то далее DA вообще не сможет дезынформировать пользователй.? Да, именно поэтмоу я отказался от форсирования включения тор-нод в PGP-сеть доверия, сказав что наша модель достаточна для отражения атаки.

    Возражений на этот пост не последовало. Где они?
    Я привёл только теоретическое обоснование. Далее уже можно думать как сделать обмен статистикой между юзерами удобным и практичным и т.п. – а пока мы пишем письмо только.

    Теоретически звучит хорошо, но как это будет выглядеть технически мне совершенно не понятно. Лично изучить несколько сотен нод и их график? А насколько он устойчив/меняется?


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

    ent1, то что вы предлагаете в первом приближении нефизично. Такой подход можно использовать в умозрительных построениях, но на практике он работать не будет. Если сильно глубоко копать, может быть можно будет далеко впоследствии на основе протокола обмена тор-статистикой между пользователями сооррудить нечто, что в реальном времени будет вычислять то что вы хотите – само, автоматически. Но это отдельный протокол, отдельный огромный геморой, свои оценки, куча сложных случаев и т.п. Здесь на одно обсуждение тривиального сравнения двух статистик ушло уже 13 страниц форума, а ведь эта задача на порядка 2 просче. В общем, как идея такое есть, но "явно не для 'сейчас'".

    Готовый код для клиента тор думаю никто из нас не напишет.

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

    Можно долго и нудно что-то доказывать человеку, приводить статистику, аналитические выкладки и тд, и все равно не убедить если ему не понравится идея, соотв реализации не будет.

    Подписываюсь.

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

    Естественно. Такие тесты лишь часть разработки функционала для тор-клиента. Пока наше дело – изложить теоретический базис и показать: что можно предпринять, как это теоретически могло бы работать и что бы это дало. Далее, либо они сами напишут скрипт, либо предложат нам его напистаь, либо впараллель. Следующим шагом будет умение тор-клиента после скачки статистики вызывать такой скрипт и принимать решения об останове на основе ограничителей выставленных в конфиге.
    — unknown (26/02/2008 09:49, исправлен 26/02/2008 10:05)   

    Да, отмечал окончание работы над которой работал последний год [можете поздравить :)]

    поздравляю :)

    По поводу стаистики:

    Вот статистика одной ноды (будет ругаться на серт.):

    https://node.xenobite.eu/

    график за день[link17]
    за неделю[link18]
    за месяц[link19]
    за год[link20]

    Это по пропускной способности, но общее впечатление о стабильности сети составить можно.

    А вот на что стоит внимательнее посмотреть:

    вот необновляющийся с 2007 года график за большой промежуток для всей сети Tor по количеству узлов[link21]

    число узлов за год[link22]

    число узлов за месяц[link23]

    число узлов за две недели[link24]

    число узлов за неделю[link25]

    Что за неделю, что за месяц число нод менялось в интервале примерно 10-15%.

    К сожалению только число узлов, а не графики изменения их ключей, которые никто не мерял.

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

    проект torstatus[link26] – не совсем то что нужно.

    tor control protocol[link27]

    Опция NEWDESC – это то, что нам нужно или нет?
    Гость (26/02/2008 10:14)   
    Опция NEWDESC – это то, что нам нужно или нет?

    Возможно, но м.б. в той опции ещё и много лишнего, что нам не нужно.
    — unknown (26/02/2008 12:20, исправлен 26/02/2008 12:22)   
    А что есть тогда C=N_k/N_k-1 и D=I/I_max=I/(min (N_k, N_k-1))
    если это мерять не за один шаг?

    Пусть имеется некоторое количество узлов.
    За месяц их число изменилось на 15%, допустим часть нод тоже сменилась по ключам (пока прикинем от фонаря) на 15%.
    Т.e. что будем считать просто, что не должно выходить за эти пределы и в следующий месяц?

    А если все меняют ключ в среднем раз в месяц? В две недели? Кто-нибудь это знает точно?
    Гость (26/02/2008 13:53)   
    А что есть тогда C=N_k/N_k-1 и D=I/I_max=I/(min (N_k, N_k-1))
    если это мерять не за один шаг?

    Эти формулы следует переопределить как
    C=N_k/N_0 и D=I_k/I_max=I/(min (N_k, N_0))
    Где N_0 – число ключей в трастед статистике, а N_k – в статистике на текущем шаге по времени, который мы и анализируем н вшивость.

    Пусть имеется некоторое количество узлов.
    За месяц их число изменилось на 15%, допустим часть нод тоже сменилась по ключам (пока прикинем от фонаря) на 15%.
    Т.e. что будем считать просто, что не должно выходить за эти пределы и в следующий месяц?

    Я уже раз 15 объяснил. Условно говоря,
    • Получаем и проверяем статистику, возводим её в ранг трастед.
    • В числа месяца от 1 до 30 сверяем её с трастед-статистикой.
    • В 31й день сверяем статистику с статистикой других пользователей. Если отклонений не обнаружено – снова возводим её в ранг трастед и идём спервого пункта.
    • Число S = (C-1)2+(D-1)2 должно быть не выше какого-то числа S_allowed на каждом сверке вновь скачиваемой статистики.

    Если не учитывать тонкости, то в вашем случае через месяц на каком-то 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 минут, только вот насколько легко и анонимно это можно будет делать – другой вопрос (иначе противник сможет подделывать статистику для всех пользователей, следящих за статистикой).
    — unknown (26/02/2008 15:22, исправлен 26/02/2008 15:23)   

    А если все меняют ключ в среднем раз в месяц?

    Если все будут менять ключ раз в месяц то I_k = 0 (ноль совпадающих ключей), и тогда сразу D = 0, значит S = (C-1)2+(0-1)2>=1 (гипотенуза больше каждого из катетов потому что). Как видите, число S сразу подскочило с 0.045 до большего 1, перепад существенный :)


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

    Если ключи меняются раз в месяц или чаще, то мы и будем получать S=1 и не сможем пользоваться месячным средним.
    Но допустим (и скорее всего так), сеть гораздо стабильнее.

    Но, даже если в месяц в норме меняется 20% ключей, противник может месяц подсовывать нам старый файл со статистикой,
    меняя в нём по одному ключу туда-сюда, а на 29 день дать файл, где 20% ключей поменялось, но на его фальшивые.

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

    Это при условии, что пошаговые скачки не регистрируются.

    Кстати, противник может подменить в первую очередь стабильные для пользователя адреса entry guard, входящих узлов, это существенно облегчит его задачу.
    — SATtva (26/02/2008 19:05)   
    Да, отмечал окончание работы над которой работал последний год [можете поздравить :)] – только что появилась в свободном доступе. Кстати, vadim_z в соавторах :)

    Мои поздравления обоим участникам! Хотя для меня что название работы, что резюме — китайская грамота.

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

    Я тоже только "за". Только консенсуса пока нет, что именно излагать разработчикам.

    Если мы априори примем модель "разработчикам наплевать на собственный проект" – то да, можно вообще ничего не писать – вы правы.

    Я этого не говорил. ;-)

    А вообще, spinore, тяжко Ваши посты читать. Многабукаф...
    — unknown (26/02/2008 21:06)   

    Я тоже только "за". Только консенсуса пока нет, что именно излагать разработчикам.


    Пока участников мало это разрулить легко. Можно изложить все точки зрения по пунктам.
    Первый пункт по любому общий – описание параметров. Другие – построение доверенной статистики и сравнение с ней;
    альтернатива – пошаговое сравнение, координация возможных действий пользователей (варианты с упором на "до" и "после", понятно, что
    "до" желательнее).


    Кстати, вот ещё что.

    Модифицированная версия атаки для обхода контроля статистики (более вероятностная, недетерминированная).

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

    А всем остальным узлам ключи не менять, но поменять для исходящих в их описании опцию с exit на middleman.
    Также нужно немного фальшивых middlemano'в

    Из этих исходящих 10 узлов половину сделать виртуальными, входящие – все.
    Если траффик идёт через настоящий middleman – делать фальшивый exit недоступными отпускать его в настоящий Tor
    неперехваченным. Как только клиент выберет ещё и фальшивый middleman из списка (пусть даже вероятность такой ситуации мала),
    то соединение пройдёт через [фальшивый entry guard]-[фальшивый middleman]-[фальшивый exit] с вероятностью 1/2.

    Защититься просто: кроме C и D для предотвращения подобных атак (вероятно возможны другие варианты) надо по типу D контролировать разность (difference) между описаниями нод, айпишниками и вообще всеми параметрами, которые можно извлечь из файла статуса сети.

    Другое дело, что противник всегда может подсмотреть используемый юзером список guard-узлов и не меняя их описание принудительно, поменять хотя бы только им ключи. Виртуальный фальшивый Guard – тоже штука малоприятная – противнику не нужно фильтровать трафик от этого узла в цепочке, юзер в нём один. И можно блочить соединения, имитируя что это происходит уже за этим узлом, заставляя пользователя лишний раз когда нужно противнику перестроить цепочку.

    Ну и атака с задержкой или подсовыванием устаревшей статистики, но с новым таймштампом позволяет профилировать юзера (уже тоже вероятностно, а не детерминированно).

    Всё-таки предполагаемый противник такого уровня обладает слишком большими возможностями для контроля.
    Гость (27/02/2008 10:25)   
    поздравляю :)


    Мои поздравления обоим участникам! Хотя для меня что название работы, что резюме? Китайская грамота.

    Спасибо :) [раскланялся на обе стороны]
    Ничего сверхъестественного в работе не было. На этом форуме все слышали про пресловутую "квантовую криптографию", что более точно есть всего лишь "квантовое распределние ключа". Так вот, когда Алиса передаёт ключ Бобу или ещё кому-то, она использует нечто, что математически описывается понятием "квантового канала". В работе как раз был рассмотрен один из типов квантовых каналов и было показано, что можно при определённых условиях увеличить скорость передачи по нему за счёт специфических квантовых корреляций ("энтанглемента") между используемыми квантовыми состояниями. (Сорри за офтоп :))

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

    Да, замечание справедливое. Я интуитивно предполагал что довольно редко (в среднем так же редко, как обычные пользователи меняют свои PGP-ключи).

    Но, даже если в месяц в норме меняется 20% ключей, противник может месяц подсовывать нам старый файл со статистикой, меняя в нём по одному ключу туда-сюда, а на 29 дней дать файл, где 20% ключей поменялось, но на его фальшивые.

    Да, uknown, вы молодец, атаковали систему с неожиданного для меня направления :) © SATtva. В этом случае я бы модифицировал вашу атаку для пущей определённости вот каким образом: оператор тор-машинки знает верную статистику, а значит он в реальном времени может детектить смену ключей для тех или иных нод. Как только нода меняет свой ключ и репортит сей факт на DA, оператор устраивает атаку стиля MITM, предъявляя пользователю не истиный новый ключ той ноды, а свой, и далее предъявляет уже только "инфицированную статистику" в которой со временем будет всё больше и больше фальшивых ключей. В этом случае через какое-то время злоумышленнику удастся подменить ключи ровно такого количества нод, которое меняло свои ключи за данный период. Атака сработает. В то же время если пользователь сделает "перекрёстную проверку" ключей с соседями ранее момента своей деанонимизации, он засечёт эту атаку. Видимо, Ваша атака устанавливает одну из границ на максимально допустимый (ещё секъюрный) период между двумя перекрёстными сверками(!!!) статистики. Красиво :)

    Что же касается дословно вашего описания атаки – она конкретно в таком виде не сработает. Если оппонент попытается "расшатать" статистику, введением левых ключей не учитывая "расписание" их смены для соответствующих нод, и конкретно сами ноды, то он добавит шума, что можно бдует обнаружить (+20% от естественной смены ключей +20% от смены ключей злоумышленника и -n% ключей из-за перекрывания множеств ключей, который менял злоумышленник и которые реально потом сменились).

    Это при условии, что пошаговые скачки не регистрируются

    Сама по себе информация об этих скачках всё равно ничего не даст для априорных действий. Выявить атаку можно будет только после перекрёстной сверки, но если вы возьмёте в какой-то момент времени свой последний файл статистики и сделаете эту сверку для него, также получите результат. Я призываю в первую очередь не к сравнению соседних по времени статистики, а к перекрёстной сверке. Сравнение соседних по времени важно только когда постфактум вы будете расследовать саму атаку и выявлять кто, когда и чьи ключи подменил.

    Я тоже только "за". Только консенсуса пока нет, что именно излагать разработчикам.

    Вроде уже движемся к концу, или нет? Может быть мы взялись за сильно амбициозную задачу, которая очень сложна, и постепенно будем находить всё больше и больше способов обойти алгоритм? Фактически это есть задача децентрализации доверия в сети тор, и к месту можно вспомнить про децентрализацию прав рута в системе – последняя задача отнюдь не из простых :)

    А вообще, spinore, тяжко Ваши посты читать. Многабукаф...

    Местами много повторений, которые можно было бы сжать (на что понадобилось бы больше времени для формулирования), но так не везде. Сложный баланс: если коротко без подробностей – не поймут, если с подробностями – много воды, оптимум достигается лишь при долгом и тщательным обдумывании каждого предложения перед опубликованием :)

    Защититься просто: кроме C и D для предотвращения подобных атак (вероятно возможны другие варианты) надо по типу D контролировать разность (difference) между описаниями нод, айпишниками и вообще всеми параметрами, которые можно извлечь из файла статуса сети.

    Не знаю есть ли такое уже или нет, а я бы сделал так: ключ ноды + её описание + всё остальное касающееся этой ноды + её ключ ">" файл, и берём от него ХЭШ. Вот хэши тогда и будем сравнивать между собственно ключами нод (будет статистика хэшей нод в изложенном ранее фигурировать а не статистика ключей).

    __Суммируя, 2 важных момента можно добавить к краткому описанию:
    • Предполагается, что ключи нод меняются редко. Частота их изменения со временем накладывает ограничения на допустимый безопасный интервал между перекрёстными сверками тор-статистики.
    • Вместо статистики ключей нод везде рассматриваем статистику хэшей от всей связанной с нодами информацией.__

    Ну что, ломаем дальше – я, вродь, отбился :)

    Всё-таки предполагаемый противник такого уровня обладает слишком большими возможностями для контроля.

    В принципе меня больше привлекает топорное предложение Гостя, основанное на том, что все мониторят статистику тор-нод, и выявляют стабильные ноды. Далее, отъявленные параноики используют в своих цепочках лишь те стабильные ноды. В пределе довольно стабильной сети это было бы подалуй самым изящным решением, правда остаётся вопрос о том как достоверно получить информацию о том, какие ноды стабильны а какие нет, когда ключи DA уже украдены.

    На совсем пожарный случай – заставлять ноды участвовать в PGP-сети доверия ещё можно. Это, конечно, неудобно и грубо, но зато надёжнее :) Впрочем, моя интуиция кажет что и в этом случае мощный оппонент, хорошо продумывающий свои шаги вперёд и владеющий ключами DA и в совершенстве знающий статистику тора, всё равно умудрится обмануть пользователя, просто атака будет выглядеть намного сложнее. Правда, это уже обсуждение атаки "глобальный наблюдатель", когда действительно у каждого провайдера кроме собственно сорма будет стоять ещё и антитор-машинка (возможно, как часть функционала сорм), и все такие машинки у разных провайдеров смогут общаться друг с другом.

    P. S.: мне иногда кажется, что зря это обсуждение ведётся в открытой дискуссии – пока мы говорим, бб может "взять, да и сделать...".
    Гость (27/02/2008 10:38)   
    Чем-то эта тема напоминает практикум по ИБ: сами создали – сами сломали, сами защитились – и снова сломали, и снова придумали защиту... и так ad infinitum.
    — unknown (27/02/2008 11:10)   
    Да, uknown, вы молодец, атаковали систему с неожиданного для меня направления :)

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

    Слишком ультимативно вопрос был поставлен: "придумайте атаку, которую не ловит мой способ". А если бы не придумал?
    Это же не значит, что система безопасна.
    Если мы все упускаем что-то ещё?


    Не знаю есть ли такое уже или нет, а я бы сделал так: ключ ноды + её описание + всё остальное касающееся этой ноды + её ключ ">" файл, и берём от него ХЭШ. Вот хэши тогда и будем сравнивать между собственно ключами нод (будет статистика хэшей нод в изложенном ранее фигурировать а не статистика ключей)


    Зачем? Можно каждое поле брать как параметр и поехали по вашей формуле: (A-1)2 + (B-1)2 + ... (Z-1)2.
    Вы же сами утверждали, что параметров может быть дофига.


    P. S.: мне иногда кажется, что зря это обсуждение ведётся в открытой дискуссии – пока мы говорим, бб может "взять, да и сделать..."


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

    Или лишний раз дать всем повод подумать, что из себя представляет Tor, не заложен ли в него такой скрытый функционал изначально.
    — unknown (27/02/2008 11:13, исправлен 27/02/2008 11:14)   
    Чем-то эта тема напоминает практикум по ИБ: сами создали – сами сломали, сами защитились – и снова сломали, и снова придумали защиту... и так ad infinitum.

    Потому что у нас нету уровня знаний для создания "provable security".
    А для анонимных протоколов "proof" вообще редко используется. Tor не является "provable secure". И вообще это "experimental software. Don't rely on it for strong anonimity". Вот мы и экспериментируем.
    — SATtva (27/02/2008 17:34)   
    Вопрос именно в том, что в данный момент, пока никто из здесь обсуждающих точно не знает как часто в среднем меняются ключи. Это надо проверить просто.

    Да, замечание справедливое. Я интуитивно предполагал что довольно редко (в среднем так же редко, как обычные пользователи меняют свои PGP-ключи).

    Думаю, всё-таки чаще. Смена ключа PGP связана с серьёзными затратами на введение нового ключа в сеть доверия. Для Tor-узлов такой проблемы не стоит. Практически, смена ключа вообще ни на что не влияет (ну, guard-узлом "новичок" не станет, нужен определённый срок стабильной работы).

    Вместо статистики ключей нод везде рассматриваем статистику хэшей от всей связанной с нодами информацией.

    Мне кажется, это приведёт ко множеству ложных срабатываний. Есть, скажем, такая вещь, как exit policy — список сетей/портов, куда экзит разрешает или запрещает исходящий трафик. Так вот этот список может редактироваться оператором узла довольно часто.

    Проблему можно решить, прибегнув к идее unknown'а и выбрав разные пороговые значения для срабатывания тревоги для разных полей:
    Зачем? Можно каждое поле брать как параметр и поехали по вашей формуле: (A-1)^2 + (B-1)^2 + ... (Z-1)^2.
    Вы же сами утверждали, что параметров может быть дофига.
    Гость (27/02/2008 22:25)   
    Слишком ультимативно вопрос был поставлен: "придумайте атаку, которую не ловит мой способ". А если бы не придумал? Это же не значит, что система безопасна.

    Ну как сказать... безопасность – это очень текучая формулировка. Можно, например, сравнить 2 системы: у одной сорс открыт, баги все активно ищут, известны сплоиты (например, FF), и оперу – код закрыт, сплоитов нет, известных багов меньше. – Что проще сломать? Тонко тут всё. Мы нашли атаку и рассказали об ней людям => злоумышленникам теперь проще атаковать. Ранее им понадобилась бы ещё изобрести саму атаку... С другой стороны можно подойти в лоб и сказать что об этой атаке злоумышленник мог знать уже давно, а потому мы никак не повлияли на защиту тора. В общем, я пока строгого определения "безопасности программного продукта" не читал чтоб сравнивать :-D

    Зачем? Можно каждое поле брать как параметр и поехали по вашей формуле
    Вы же сами утверждали, что параметров может быть дофига.

    Это всё можно, но надо понимать, что чем больше параметров тем громозче система и сложнее в управлении, менее чувствительна к возможным атакам, и более уязвима. Именно поэтому лучше сводить число используемых параметров к минимуму. Можно в лоб построить функцию хэшей: если они меняются действительно часто, то да, прийдётся рассматривать кучу параметров независимо. Мне хэши казались брутальней и надёжней: если они не порождают естественной большой дисперсии, то есть их достаточно для отлова атаки, то, имхо, оно самое то для нас. Хороший пример – недавняя новость про cold boot: были ли компьютеры ранее защищены больше лишь потому что широкая общественность не изнала о подобной возможности?

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

    Согласен... Была ба хорошая работа для студента :-D – написать такую тор-машинку.
    Гость (27/02/2008 23:09)   
    Ага, и еще ключи попросить, для сего агрегата. Похоже этот ключевой момент как-то начинает подзабываться.

    Ну, а в остальном-то да:

    злоумышленникам теперь проще атаковать.


    Гость (27/02/2008 23:38)   
    Вместо "срабатывания" лучше непрерывный индикатор, например от зелёного к красному.
    Гость (28/02/2008 00:37)   
    Ага, и еще ключи попросить, для сего агрегата. Похоже этот ключевой момент как-то начинает подзабываться.

    Для студенческой работы достаточно эмулировать на своей машине свою собственную тор-сеть со своими ключами и моделировать атаку на неё с помощью другой машины, на а уж бб может поиграться по-настоящему :)
    — unknown (28/02/2008 09:32, исправлен 28/02/2008 09:38)   

    Думаю, всё-таки чаще. Смена ключа PGP связана с серьёзными затратами на введение нового ключа в сеть доверия. Для Tor-узлов такой проблемы не стоит. Практически, смена ключа вообще ни на что не влияет

    Имено! Мы точно не знаем как меняются ключи в среднем, но есть ноды, которые загружаются с 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,
    когда скачивание статистики идёт не только в подписанном, но и зашифрованном виде. Тогда противник вообще не сможет понять, когда пользователь скачал реальную статистику и с какого узла, а когда подставную, может он работает уже с реальной статистикой?

    Получаем: или только атаку за один шаг (которая за один шаг и выявляется) или крайне неэффективную замедленную атаку, или если у противника есть способ осуществить замедленую атаку подменяя только часть узлов, но каким-то неведомым образом заставляя пользователя скачивать статусы только с подконтрольных (тогда он может обойти в принципе любой статистический контроль, если умеет так ловко работать с частично изменённой сетью).
    — unknown (28/02/2008 16:26, исправлен 28/02/2008 16:27)   
    Для студенческой работы достаточно эмулировать на своей машине свою собственную тор-сеть

    А для нестуденческой с изобретением нового TOR-протокола можно получить исследовательский грант[link28]
    Гость (29/02/2008 01:17)   
    В п.5 противник даёт скачать статус, где подменено только 10% ключей? (Это для простоты примера, в реальности это уже слишком заметно).

    дальше, если он не снимет блокировку, то пользователь сможет работать только с 10% подконтрольных нод, что тоже будет заметно.

    Это, интересно, каким таким образом заметно? Вы же сами объясняли, что если польхователь выбрает неподконтрольные ноды, то они проследуют только через реальный тор, а если подконтрольные ноды, то через виртуальную машинку + итиный тор.

    И того на следующий раз вероятность будет 20%. Но чтобы дойти до 100% нужно будет совместить девять событий с произведением вероятности

    Если предположить, что параметр S работает лишь как ограничитель на сравнение соседних скачанных статистик, а с исходной трастед-статистикой мы не сравниваемся, то через 10 скачиваний мы получим что противник подменил 100% ключей узолов. Если новая статистика скачивается каждые 15 минут, то на подмену полностью всей статистики понадобится примерно 2 с половиной часа, при это деанонимизация произойдёт почти точно раньше :-D

    P. S.: я предполагал для простоты, что протвник смог захватить ключи всех DA. Вносим это в предположение.
    — unknown (29/02/2008 09:13, исправлен 29/02/2008 09:40)   
    Это, интересно, каким таким образом заметно? Вы же сами объясняли, что если польхователь выбрает неподконтрольные ноды, то они проследуют только через реальный тор

    И скачает с любой из реальной ноды реальный, а не подставной статус и откатится назад, если не 100% ключей подменены. Поэтому и получим такую низкую вероятность. Скачивание может идти к тому же и с разных нод одновременно.
    Как сегодняшний Tor-клиент в такой ситуации обрабатывать будет нестыковки и противоречия? По самой последней дате на статусе? Не знаю.

    Или противник будет давать строить цепочки только через подставные узлы?
    Каждый раз? Тогда почти каждое построение цепочки будет заблокировано, пока подконтрольных узлов мало. А если отпускать неподконтрольные цепочки в реальный Tor неперехваченными, то ещё раз – клиент просто на очередном шаге скачает статус не с DA, а с любой ноды, как с зеркала. И соединение будет подписано, а при определённых настройках и зашифровано ключём этой ноды.

    Раз в 15 мин – это минимум. Реально, посмотрите свой кэш. Там обычно статус, устаревший от часа и больше. Раз в сутки он точно принудительно меняется. По какому принципу остальное время х.з.

    Заметно всё будет, если контролировать число изменившихся ключей, которое не может изменяться слишком медленно или изменится скачком назад к реальному значению, если противник не достигнет 100% подмены.
    Гость (29/02/2008 09:30)   
    Что-то закрузили вы меня, unknown...
    В общем, тезис я понял. А как по-вашему могла бы выглядеть в принципе атака delayed cache poisoning – чтоб всё работало и получалось?
    — unknown (29/02/2008 09:44, исправлен 29/02/2008 09:54)   
    Что-то закрузили вы меня, unknown...
    В общем, тезис я понял. А как по-вашему могла бы выглядеть в принципе атака delayed cache poisoning – чтоб всё работало и получалось?

    Это Вы меня загрузили! Я с самого начала утверждал, что при нынешнем дизайне она маловероятна, а Вы стали рассуждать, как будто она есть.

    В принципе противник может действительно вводить по 10% узлов за раз, а остальные блочить, чтобы не дать скачать реальные статусы, но это слишком топорно и заметно.

    Другие варианты пока в голову не приходят (это не значит что их в принципе нет).
    — unknown (29/02/2008 09:58)   
    И опять же: легко блокировать можно только первый узел, выбранный пользователем. Если он подконтролен, то тогда блокировать следующий за ним. Но если пользователь входит в сеть через неподконтрольный узел, далее он может достроить цепочку из неподконтрольных. Она будет может и лучше отслеживаема, но достаточна для скачивания реального статуса.
    Гость (29/02/2008 11:24)   
    И что теперь, написать Роджеру что атака скорее теоретическая чем практическая, а потому не стоит маяться дурью и пытаться защититься?
    — unknown (29/02/2008 11:56)   
    И что теперь, написать Роджеру что атака скорее теоретическая чем практическая, а потому не стоит маяться дурью и пытаться защититься?

    Да вернуться к началу обсуждения. Противник может подменять 100% или по крайней мере > 50% ключей за раз (если он хочет рисковать), что элементарно засекается пошаговым сравнением.

    Я предлагал, что если > 90% ключей сменилось за короткий период времени.

    После останова (а он при таких условиях будет редким) перепугавшиеся пользователи могут сравниваться между собой.

    Ещё контрмера – сравнить статусы принудительно скачанные со старых и новых нод-зеркал.

    — Гость (29/02/2008 11:24) <#> правка удалить
    верная ЭЦП от 29/02/2008 11:23 ключом пользователя unknoun
    И что т

    unknoun? Кто это?
    Гость (29/02/2008 12:04)   
    unknoun? Кто это?

    Я решыл полгядеть насколько быстро заметят – ведь всего одна буква... :)
    Ладно, щас удалю.

    Ну в общем, да. Тогда концептуальных нареканий к предыдущему письму вроде как нет, получается. Проверяем орфографию и отправляем?
    Гость (29/02/2008 12:08)   
    P. S.: параллельный вопрос: если ключ загружается на сайт непосредственно копипастом, а не с публичной кейсервера, то он пересылается автоматически ещё и на публичные сервера или нет?
    — unknown (29/02/2008 12:23)   
    Судя по задумке SATtv'ы да. С движком сайта Вы уже игрались (за что спасибо кстати), а вот распространять фальшивые ключи такого рода какой концептуальный смысл?
    — SATtva (29/02/2008 12:25)   
    Нет, не пересылается. Только периодически загружается с серверов.
    — unknown (29/02/2008 12:28)   
    Какая провидческая предусмотрительность!
    Гость (29/02/2008 12:30)   
    а вот распространять фальшивые ключи такого рода какой концептуальный смысл?

    Решил проверить насколько чётко реакция работает.
    Я не знаю что там на самом деле, но на subkeys ключ не появился.


    Если вдруг что, то отозванная версия:
    Гость (29/02/2008 12:33)   
    Нет, не пересылается. Только периодически загружается с серверов.

    Кстати, имхо это более правильно идеологически как раз, чем силком загружать ключи на сервера. Возможно, кому-то понадобится ключ, который лучше бы лишний раз не светился на серверах...
    — unknown (29/02/2008 13:03)   
    Ну в общем, да. Тогда концептуальных нареканий к предыдущему письму вроде как нет, получается. Проверяем орфографию и отправляем?

    А что делать с тремя вариантами: деление-умножение (связанные C и D), сумма дисперсий (несвязанные C и D) и пересечение множеств дескрипторов? Кратко перечислять всё?

    Что делать со средней статистикой за большие интервалы, которая вроде как не нужна?
    — SATtva (29/02/2008 13:10, исправлен 29/02/2008 13:12)   
    Кстати, имхо это более правильно идеологически как раз, чем силком загружать ключи на сервера. Возможно, кому-то понадобится ключ, который лучше бы лишний раз не светился на серверах...

    Именно. Такими причинами и руководствовался.
    Гость (29/02/2008 13:30)   
    А что делать с тремя вариантами: деление-умножение (связанные C и D), сумма дисперсий (несвязанные C и D) и пересечение множеств дескрипторов? Кратко перечислять всё?

    Там достаточно взять S = (1-C)2+(1-D)2
    C/D не стоит, наверное, рассматривать... хотя тоже меожете включить.

    пересечение множеств дескрипторов?

    Ну поюзать его, а что? Всё сводится лишь к тому, чтоб учесть существенные замечания и всё, всего навсего.

    Что делать со средней статистикой за большие интервалы, которая вроде как не нужна?

    Ничего не писать.
    — unknown (29/02/2008 22:15)   
    Вот ещё контраргумент против замедленной атаки.

    Пусть противнику на каком-то шаге удалось довести число ложных ключей и подменённых нод до половины:
    Тогда пользователь может построить случайным образом 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 стабильно высокий, да ещё и глюки с работой сети наблюдаютсяя очень заметные, то это отсекает и практически любую замедленную атаку тоже.
    — unknown (29/02/2008 22:16)   
    // 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"
    Гость (01/03/2008 06:17)   
    тестовое сообщение, удалите его
    Гость (01/03/2008 06:44)   
    The most
    likely scenario for any balance that we pick between too brittle and
    not brittle enough is that in about a year people will start seeing the
    warnings when no actual attack is occurring, and we'll wonder why the
    code is there.

    Наиболее вероятный сценарий любого баланса, в котором мы выбираем между слишком узким но не достаточно узким есть тот, э.. э.. э.. э.. in about YEAR PEOPLE... мой парсер сломалсо :-((

    time invarianted value

    time direction invarianted value (иначе можно опдумать о банальной однородности по времени, что не верно)

    Finally, calculate R = K*(1-Z), with K is the maximum distance in space [x, y, z].

    У нас был свой контекст, где мы проводили аналогии с n-dim, но здесь об этом не говорится, да и зачем им этим мозги пудрить. Достаточно положить K=1, ибо оно ни на что толком не влияет, либо по крайней мере сказать что K – есть аналог максимального расстояния как если бы мы были в конфигурационном пространстве. Иначе нас сочтут за сумасшедших (ввести x, y, z в торе [в тор-сети а не в бублике] :)) Скажем так, K они и сами догадаются ввести если оно им будет удобно (ибо это всего лишь рескэйлинг), а вот чем меньше лишних определений и букв, тем лучше.

    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

    В принципе мы начинали обсуждение, когда-то ещё давно, с того что противник режет загрузку статистики через тор-сеть, и позволяет её загружать только через DA напрямую. Итак, этого он делать не может, получается? Точно?

    alldiractionsprivate=1

    /мну уважает Dirac'а, но боится что конкретно в данном случае он не причём :-D
    alldirectionsprivate

    Another problem for adversary is too many broken connection

    connections

    In our another example user haves a half of false nodes and another half of real. He can select randomly 8 types of circuits:

    In our another example user has a half of false nodes and another half of real ones.
    Кроме того, здесь следует оговориться о том, что реальная вероятность будет зависеть от их задекларированной пропускной способности, так что если в качестве 10% подменённых нод будут фигурировать самые высокопропусные, то вероятность может резко подскочить :) Либо надо сказать "для простоты и демонстрации ради, здесь мы не учитываем корреляцию вероятности выбора с пропускной способностью нод".

    It's possible from this examples

    It's possible from these examples

    Ещё у меня лично есть вопрос о том, как часто клиент загружает статистику с тора. Слышал, что зависит от интенсивности трафика, пропускаемого через тор, или нет? Просто хотелось бы знать конкретные временные рамки: минимум – такой интервал, максимум – такой.

    can be performed with separate tools


    by the means of web of trust
    Гость (01/03/2008 07:17)   
    Ещё обсуждался беспредел с тем что в v2 протокола клиент не извещает пользователя о том что какой-то из DA не подписал статистику либо от него вообще не удалось получить ответа. Стоит ли об этом сказать Роджеру, или положиться на то что дизайн v3 совсем другой, а потому нечего городить?

    Также, мы начинали обсуждение с того, что когда пользователь после перерыва запускает вновь свой тор-клиент, атакующий может запретить ему строить цепочки по существующему статусу, чтобы заставить его обратиться к DA напрямую (вот тогда и можно ему сделать хоть 100% подмен). Вы, unknown, оговаривались, что появилась недавно какая-то опция в тор-клиенте, имеющая отношение как раз к этому, но то вроде было не совсем то. В нашем случае требуется конкретно возможность/опция загружать статистику принудительно по уже имеющейся старой статистике а не напрямую, не допускать принудительно прямого обращения к DA.

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

    Ещё было бы интересно узнать о том, сколько в среднем в каждый выбранный момент времени одновременно работает тор-нод, тор-экситов и тор-пользователей (с упором не на всё сообщество, включающееся время от времени, а на то, сколько одновременно). В оценочную упоминавшуюся цифру (100000 пользователей тора) я могу поверить от силы как в число всех, кто за много лет хотя бы раз запускал тор, но не более.
    Гость (01/03/2008 07:21)   
    s / не допускать принудительно прямого обращения к DA / принудительно не допускать прямого обращения к DA
    — unknown (01/03/2008 15:03)   

    В принципе мы начинали обсуждение, когда-то ещё давно, с того что противник режет загрузку статистики через тор-сеть, и позволяет её загружать только через DA напрямую. Итак, этого он делать не может, получается? Точно?

    Он делает это только один раз, чтобы сразу погрузить пользователя в виртуальный Tor, подменив все 100% ключей для нод. Если он это будет делать после каждого шага по частям, то у пользователя не будет работать большинство цепочек, даже если не предпринимать блокировки, а если ещё и неподконтрольные узлы блокировать, то ещё больше. И так по много раз подряд, пока пользователь не скачает весь фальшивый статус целиком. Это также заметно, как и атака за один шаг.

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

    Опции Directory Actions не в текущей, ни в альфа-версии не нашёл, хотя она была и обсуждалась у нас в теме (может название не так запомнил)?

    Сейчас есть:

    TunnelDirConns 0|1
    If non-zero, when a directory server we contact supports it, we will build a one-hop circuit and make an encrypted connection via its ORPort. (Default: 0)

    PreferTunneledDirConns 0|1
    If non-zero, we will avoid directory servers that don't support tunneled directory connections, when possible. (Default: 0)

    но лучше убрать тогда вообще упоминание об опциях, они меняются. А основной принцип будет ясен.


    Кроме того, здесь следует оговориться о том, что реальная вероятность будет зависеть от их задекларированной пропускной способности, так что если в качестве 10% подменённых нод будут фигурировать самые высокопропусные, то вероятность может резко подскочить :) Либо надо сказать "для простоты и демонстрации ради, здесь мы не учитываем корреляцию вероятности выбора с пропускной способностью нод".


    Верно. Мы не анализируем механизм выбора цепочек клиентом. Пока обойдёмся без конретики, чтобы не разводить новой теории. Our conjecture is "adaptive (or selective) blocking" of connections is possible but don't gives a significant advantages to adversary.


    Ещё у меня лично есть вопрос о том, как часто клиент загружает статистику с тора. Слышал, что зависит от интенсивности трафика, пропускаемого через тор, или нет? Просто хотелось бы знать конкретные временные рамки: минимум – такой интервал, максимум – такой.



    Ещё обсуждался беспредел с тем что в v2 протокола клиент не извещает пользователя о том что какой-то из DA не подписал статистику либо от него вообще не удалось получить ответа. Стоит ли об этом сказать Роджеру, или положиться на то что дизайн v3 совсем другой, а потому нечего городить?


    Я нашёл у себя в кэше после длительного периода работы через Tor пять статусов. Один от какого-то умершего DA, про который писали в рассылке, что он в дауне, он не обновлялся неделю. Один суточной давности. Один часовой. Один примерно 15 минутной. И один тоже старше суток.

    Вообще бардак полный :-) В третьей версии отдельных статусов не будет, будет один общий файл-консенсус, подписанный большинством DA. Думаю, что в среднем, он не чаще часа будет обновляться, а при серьёзных изменениях в сети не чаще 15 минут.


    Также, мы начинали обсуждение с того, что когда пользователь после перерыва запускает вновь свой тор-клиент, атакующий может запретить ему строить цепочки по существующему статусу, чтобы заставить его обратиться к DA напрямую (вот тогда и можно ему сделать хоть 100% подмен).


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


    Ещё было бы интересно узнать о том, сколько в среднем в каждый выбранный момент времени одновременно работает тор-нод, тор-экситов и тор-пользователей (с упором не на всё сообщество, включающееся время от времени, а на то, сколько одновременно).


    Про пользователей никто точно не скажет. А раскладку по нодам и их опциям можно посмотреть или в кэше или на странице xenobite, ссылку на которую я уже приводил. Порядка 1100 экситов из 2500 нод как ни странно. Только большинство похоже еле шевелятся, поэтому и адаптивные блокировки и подмены наиболее выбираемых узлов в какой-то мере возможны.


    принудительно не допускать прямого обращения к DA


    Вообще в логах что-то должно быть на этот случай: статус ещё не устарел, а после N попыток так и не смогли обновить статистику и пошли качать с DA.

    И в первом письме и в этом указывается, что большое число любых битых соединений совместно с большими изменениями в картине сети – признак атаки. Что из этого следует, разработчики лучше нас поймут надеюсь.
    — unknown (01/03/2008 15:17)   

    Наиболее вероятный сценарий любого баланса, в котором мы выбираем между слишком узким но не достаточно узким есть тот, э.. э.. э.. э.. in about YEAR PEOPLE... мой парсер сломалсо :-((


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

    Ну если они ещё заумнее нас пишут, то нас они точно лучше понимают :-)
    Гость (01/03/2008 20:14)   
    выйдет такой, что спустя примерно год люди увидят сообщения в логах безо всяких реальных атак, а мы будем думать для чего здесь нужен этот код?

    Да смысл-то я понял, конечно, только я не понял почему так писать на английском есть правильно. Мне такая грамматика не ведома.

    P. S.: коментариев/нареканий/возражений к вышесказанным замечаниям не имею.
    — unknown (01/03/2008 21:26)   

    Да смысл-то я понял, конечно, только я не понял почему так писать на английском есть правильно. Мне такая грамматика не ведома.


    Ну, некоторых носителей языка даже попытки слишком правильного изображения грамматики инглиша веселят: "букиш, букиш!"

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

    // 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"
    — unknown (01/03/2008 21:39)   
    готово[link29]
    Гость (02/03/2008 19:04)   
    Ясно, спасибо.
    Только они както очень странно зеркалируют письма: ни на уровень выше выйти, ни проглядеть дерево всей рассылки... там вроде две ссылки всего или я что-то путаю?
    — unknown (02/03/2008 22:40)   
    На уровень выше – письма за месяц, ещё выше – список месяцев за год.
    Дерево соответственно отображается только за месяц. Поскольку частота ответов за месяц невысока, то дерево не складывается. Если просматривать через почту, то рассылка выглядит стандартно со всеми деревьями.
    — ygrek (05/03/2008 00:34)   
    Усредненённая статистика по cached-status за несколько дней[link30]
    Исходники[link11]
    Нативный линуксовый и байт-кодовый бинарники[link31]

    Дальше надо собрать данные по количеству "новых" и "старых" нод.
    — unknown (05/03/2008 13:07)   
    В принципе согласуется с обычным изменением числа нод в сети.
    Непохоже, чтобы кто-то подменил вам 100% узлов ;-)
    Гость (05/03/2008 16:03)   
    Интересно было бы ещё увидеть распредление тор-узлов по их пропускной способности. Там из 2000 заявленных нод имхо большинство будет сидеть на хвосте распредления, а значит эффективное число используемых нод меньше (почти всегда только высокоскоростные узлы выбираются).
    — ygrek (13/03/2008 00:39)   
    Картинка изменения числа "новых" и "старых" нод[link32]. Линии span total и span exits показывают число нод, которые были онлайн в течении последних 4 часов. Пересчитать для любого другого интервала легко – были бы файлы истории. Забавно что exit'ов практически точно половина и абсолютно повторяют динамику изменения числа всех нод. Исходные данные – сохранённые копии cached-status от одного DA взятые с интервалом 20 мин.

    ЗЫ Кстати для меня было новостью что нода считается exit'ом тогда и только тогда когда её политика выхода включает два (или три) порта из трёх – 80 443 6667.
    Гость (13/03/2008 05:02)   
    для меня было новостью что нода считается exit'ом тогда и только тогда когда её политика выхода включает два (или три) порта из трёх? 80 443 6667

    А причём тут 6667, за что он отвечает? Какой сервис?
    Гость (13/03/2008 09:19)   
    6667 – стандартный порт IRC[link33]
    — SATtva (13/03/2008 10:15)   
    Занятно. Я считал, что экзит — это узел с любой политикой, отличной от reject *:*.
    Гость (13/03/2008 12:12)   
    Условие — тогда и только тогда, слишком сильное :) Для получения флага достаточно двух из трех, самое распространенное при такой схеме это 80 и 443 разрешенные. Однако даже запретив все эти три порта, но разрешив все остальные (например правило reject *:80, reject *:443, reject *:6667, accept *:*), узел всё равно будет Exit'ом. За подробностями — смотрите функцию exit_policy_is_general_exit(); Впрочем именно эта функция скажет что узел формально exit, даже если будет такой обман как reject *:1-65535, accept *:*

    Сам по себе флаг влияет только на коэффициент при взвешивании скоростей (в пользу щадящего использования exit'ов). Клиент при выборе кандидатов на взвешивание смотрит только на полиси. К примеру если будет требоваться один 80 порт, то в число претендентов на последний узел в цепи попадет формально не Exit узел, имеющий в разрешенных единственные нужный порт.
    — unknown (13/03/2008 21:02)   
    Очень хорошая статистика. Видно появление с момента работы и стабилизация небольшой дельты между "span" и остальными нодами.
    Кажется, что придумать метод постепенной селективной подмены без внесения существенных искажений в эту картину сложно, с учётом предположения о трудностях смешивания цепочек из подлинных и фальшивых узлов.

    Хотелось бы, чтобы авторы это сами доказали более строго.

    Другой вопрос, что метод с DA и другими централизованными доставщиками статусов сети в соответствующей литературе изначально считаетсяя недостаточно стойким (более того соответствующие исследования проводили сами разработчики TOR и они же предложили теоретически более стойкий метод получения клиентом информации о сети, скорее всего его пока невозможно реализовать практически.
    К сожалению есть только упоминания об этих работах, сами их я не находил и не читал, за то что я правильно понял цитаты не ручаюсь).

    Так что думаю наши изыскания их не особо удивляют. Ничего нового мы не открыли. Странно только, что среди моделей угроз сети Tor такой злоумышленник не рассматривается (умалчивается).
    Гость (13/03/2008 22:51)   
    К примеру если будет требоваться один 80 порт, то в число претендентов на последний узел в цепи попадет формально не Exit узел, имеющий в разрешенных единственные нужный порт.

    Русский язык пропарсить не смог :(
    — ygrek (14/03/2008 00:39)   
    Однако даже запретив все эти три порта, но разрешив все остальные (например правило reject *:80, reject *:443, reject *:6667, accept *:*), узел всё равно будет Exit'ом. За подробностями — смотрите функцию exit_policy_is_general_exit();

    Да, reject'ы там вообще не учитываются. Очевидно, бага.
    /** Return true iff <b>ri</b> is "useful as an exit node", meaning
    * it allows exit to at least one /8 address space for at least
    * two of ports 80, 443, and 6667. */

    Клиент при выборе кандидатов на взвешивание смотрит только на полиси.

    Ага, я именно про то что смотреть флаг exit в статистике не имеет смысла :)
    Вообще говорить "сервер такой-то это exit" некорректно, правильно говорить "сервер такой-то это exit по отношению к ip:port".
    Гость (14/03/2008 01:09)   

    Да, reject'ы там вообще не учитываются. Очевидно, бага.


    Не считаю это багой. Если узел, правило для своей политики завершает accept'ом, значит он уже что-то разрешил. Он exit по отношению к неопределенной группе адресов и портов.

    Данная функция рассчитана на более ограничительную политику, оканчивающуюся reject'ом. В таком случае важно проверить доступность по меньшей мере к определенной группе портов, и значительного диапазона адресов.

    В случае когда узел обманно (пример в предыдущем постинге) получит флаг, он не будет выбран в действительности, ни конечным звеном (по причине полиси), ни промежуточными (его будут стараться избегать как драгоценного exit'а). Он обманет сам себя.
    — poptalk (01/09/2008 16:59)   
    Как и рекомендовал unknown, задаю вопросы в этой ветке. В общих чертах алгоритм понятен, он сравнивает статистику сети, полученную от разных узлов, если статистики сильно отличаются, это считается проблемой. Так и не понял, алгоритм защитит от (захвата всех DA) + (медленного изменения статистики)?
    — unknown (02/09/2008 10:12, исправлен 02/09/2008 10:20)   
    В общих чертах алгоритм понятен, он сравнивает статистику сети, полученную от разных узлов, если статистики сильно отличаются, это считается проблемой.

    Это скорее алгоритм голосования между DA, в результате которого получается готовый документ (консенсус, статус), отправляемый узлам сети в качестве статистики.
    Если все DA коррумпированы, то они могут наголосовать что-угодно. Сами DA против собственного сговора этот алгоритм применить не могут.

    Мы думали о другом алгоритме – попытке мониторить этот статус и число неудачных соединений с узлами на предмет аномалий со стороны клиента.

    При медленном изменении статистики будет всплеск количества битых цепочек или постоянный откат к старой статистике по зеркалам.
    Вообще алгоритм мониторинга (если бы он был создан) не защитил бы, а предупредил-бы, о чём-либо подозрительном. Точных оценок вероятности сформулировать никто не решился, так же как и доводить до ума саму идею. Разработчики тозже не проявили энтузиазма.
    — poptalk (03/09/2008 10:58, исправлен 03/09/2008 11:19)   

    Да по-моему я правильно понял. Вы вычисляете величину 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-адресов, обслуживаемых одним компьютером. Что на это скажете?



    Да, я оговорился. Не защитить, а предупредить.
    — unknown (03/09/2008 13:24, исправлен 03/09/2008 13:31)   

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


    Или по зеркалам, соединения с которыми аутентифицированы ключами со старой статистики.

    постепенная подмена статистики затрудняет эмуляцию виртуальной сети tor, при смешивании реальных и подставных узлов эмулятор будет работать всё хуже из-за сбойных цепочек и есть большой шанс, что на каждом шаге пользователь соберёт и скачает реальную статистику от неподставных узлов или соединения с ними придётся разрывать?

    вот насчёт этого[link34]


    список DA составляется дядей Роджером. Смысл сравнивать файлы, сгенерированные одним человеком? Никакой разницы, свидетельствующей о злых намерениях, вы там не найдёте. :-) То есть возвращаемся к тому варианту, что дядя Роджер и является глобальным наблюдателем.


    Допустим все DA коррумпированы вместе с Роджером впридачу. Но им надо ухитриться незаметно подсунуть конкретному пользователю левую статистику, и разместить между ним и реальной Tor-сетью эмулятор. Это возможно, но сложно и задача для прицельного, а не глобального наблюдателя. Чем большему числу людей будут раздавать левую статистику, тем больше шансов поймать Роджера за руку.


    Хотел бы уточнить. Если я создал middleman или exit-node, то я рано или поздно должен появиться в статистике. Вы имеете в виду, что в статистике будет указан мой IP-адрес, но не мой ключ?


    И IP и ключ, и политику прохождения трафика, и e-mail для спама если пожелаете и ещё массу служебных полей.
    Или же меня могут вообще не включить в статистику, так ещё проще.

    Ну пара человек за всё время себя не увидело, пожаловалось в рассылку. Нашли проблемы у них в настройках.

    Вот вэб-парсер статистики:

    xenobite[link1] – сертификат сайта самоподписанный.


    Но есть лазейка: на каждый честный узел злоумышленник присоединяет к сети 9 подставных узлов. Так что честные узлы просто утонут. Ведь узлы — это не люди, а просто IP-адреса.


    Это возможно как и в любой сети вообще.

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

    Но пока сеть Tor не очень большая и пока плохо масштабируемая.
    — poptalk (03/09/2008 14:34)   

    Здесь ошибка. Что есть "реальная статистика"? Нет никакой статистики, кроме той, которую выдают DA. В текущей архитектуре сети так, и в v2 и в v3. Я разумеется рассматривал вариант когда Роджер куплен и всё что из этого следует. В этом случае гораздо проще обманывать всех, чем одного клиента.

    А если Роджер не куплен и среди DA есть хотя бы один честный, тогда я согласен, что ваш алгоритм будет обнаруживать ввод подставных узлов.

    Кстати, как и голосование DA будет обнаруживать это. Может, поэтому разработчикам ваше нововведение не понравилось.
    — unknown (03/09/2008 15:25)   
    В этом случае гораздо проще обманывать всех, чем одного клиента.

    Тогда каждый владелец независимого сервера tor может заметить, что в статистике его ключ подменён. Он может ещё попросить посмотреть своих знакомых.

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

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

    Или придётся заблокировать доступ резко ко всем узлам, дать скачать статистику только с DA и подменить все ключи разом, чтобы в реальную сеть пользователь не лез.

    Но если долго не пользоваться программой, то никакие проверки на резкие изменения статистики конечно не помогут.
    — poptalk (03/09/2008 16:09)   

    Нет, ключ не подменяется. Список узлов разбавляется подставными узлами.
    — unknown (03/09/2008 16:50)   
    Для всех подставные узлы можно и не вводить – можно действительно попытаться завести в сети много злонамеренных серверов.

    А если для изолированной группы пользователей посылать статистику, сильно разбавленную фальшивыми узлами, то при контакте с реальными узлами они будут получать обратно правильную (общую для всех статистику). Будут наблюдаться изменения количества узлов в сети.
    — unknown (22/01/2009 10:27, исправлен 22/01/2009 10:28)   
    Похоже, эту особенность дизайна сети тор кардинально не исправить:

    кто-то тоже спрашивает[link35].

    Всех призывают верить в честность шести DA. Ответ дал пользователь arma – это ник Роджера что-ли?
    — SATtva (22/01/2009 12:24, исправлен 22/01/2009 12:25)   
    Он самый. А анонимус — это не Вы, unknown? :-)
    — unknown (22/01/2009 13:02, исправлен 22/01/2009 13:11)   
    anonymous unknown или unknown anonymous! :-)
    — poptalk (23/01/2009 00:50)   
    Всех призывают верить в честность шести DA. Ответ дал пользователь arma – это ник Роджера что-ли?

    Этот 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.
    — unknown (23/01/2009 09:15, исправлен 23/01/2009 09:16)   
    В начале этого топика предполагалось, что некий "человек посредине" вклинится между конкретным клиентом и завернёт весь его трафик (перехватывая на уровне маршрутизатора или ISP) в специально запущенный для него полный эмулятор сети из одних фальшивых узлов, после чего может его расшифровывать.
    — spinore (01/08/2009 15:53)   
    Народ, наверное, в курсе, но тем не менее перепощу:
    Учёные из Sandia National Laboratories, Livermore, Калифорния, создали модель сети Интернет в рамках суперкомпьютера Dell Thunderbird. Машина имеет 4480 процессоров. На ней был запущен один миллион копий Linux c работающим WINE. Цель проекта – изучить поведение ботнетов и разработать эффективное средство подавления.
    ©[link36]. А ведь задача эмулировать Tor в принципе задача куда проще, чем эмуляция всей Сети.
    Гость (21/09/2009 06:52, исправлен 21/09/2009 12:13)   
    Встретил Роджера на на канале #tor, irc.oftc.net.

    Оказывается, такая машинка для эмитации тора уже была изобретена в 1995-2001, собственно на ней появился первый тор. Взял у Роджера интервью на плохом английском об истории тора, кому интересно, можете почитать:


    05:48 < Malkovich> Roger, im sorry for my molestation. But i just didn't meet on official site information, about how did you get source from Navy, could you give me link on full history?)
    05:48 <@arma> i didn't get the source from the navy. they have pretty not been related to tor's source.
    05:49 <@arma> the source originally came from a nice game named matej from slovenia, who was an undergrad at cambridge england under another anonymity researcher
    05:49 <@arma> it was gpl. we convinced him to offer it to us under 3-clause bsd if we promised to make it available for a while.
    05:49 <@arma> this was many years ago. pretty much none of his code remains in tor.
    05:50 <@arma> but you can see remnants of the name 'or' (rather than 'tor') in some places, like the mailing list names, and the code directory name.
    05:51 <@arma> a bit more history at http://www.onion-router.net/
    05:51 < Malkovich> but navy was engineer tor, as i know..
    05:53 <@arma> hm?
    05:56 < Malkovich> one moment
    05:58 < Malkovich> Who uses Tor?
    05:58 <@arma> https://www.torproject.org/torusers.html.en
    05:58 < Malkovich> It was originally developed with the U. S. Navy in mind, for the primary purpose of protecting government communications. Today, it is used every day for a ...
    05:58 <@arma> depending on what you mean by that
    05:58 < Malkovich> www.torproject.org/torusers.html.en
    05:58 <@arma> ah. yep.
    05:58 <@arma> the general design of onion routing was developed by a guy named paul syverson who works at nrl
    05:58 <@arma> he was one of the authors on the tor design paper, in 2004
    05:59 <@arma> and it was his funding that got tor started in 2002-2004
    05:59 <@arma> but the actual code was written by matej originally, and then adapted by me and later me and nick
    05:59 <@arma> "developed with the navy in mind" is different from "developed by the navy"
    06:00 < keb> well the internet was developed by the army, but that doesnt mean much nowadays
    06:01 <@arma> indeed. government funding makes the world go 'round, alas
    06:03 < keb> why are some of the links on the torusers page bolded
    06:04 <@arma> whoever wrote it thought that ten pages of text with nothing standing out would make people stop reading
    06:04 < Malkovich> so, as i understand, navy developed, publish, one gay from England/Slovenia make some science work about, and you connected?
    06:04 < keb> s/gay/guy/
    06:05 < Malkovich> okay
    06:05 <@arma> malkovich: the navy made a design, and wrote lots of research papers about it. they have a prototype too, with lots of users, but the whole network was running on only one computer.
    06:05 <@arma> then somebody from england/slovenia wrote a better prototype
    06:05 <@arma> then i picked that up and turned it into tor
    06:06 < Malkovich> cool
    06:06 < Malkovich> respect to you)
    06:06 <@arma> the timelines for these three events are "1995-2000", "2001", and "2002-2009"
    06:07 < Malkovich> so, what do you think about next generation of onion network's, when will it come/
    06:07 < Malkovich> ?
    06:07 <@arma> you mean after tor?
    06:07 < Malkovich> yes
    06:07 <@arma> i suspect the next generation will be named tor also. :)
    06:08 < Malkovich> be cool


    Гость (21/09/2009 10:51)   
    Основная мысль интервью:
    <@arma> "developed with the navy in mind" is different from "developed by the navy"
    — DDRTL2009 (21/09/2009 12:21)   
    а в чем отличия?
    Гость (21/09/2009 14:50)   
    "Разработанное на основе navy (используя только идею/интерфейсы, но не общий код)" versus "разработанное navy'ей".
    Гость (21/09/2009 15:22)   
    "developed with the navy in mind" можно ещё понимать как "имея ввиду интересы navy" (нави?)
    — SATtva (21/09/2009 16:20)   
    "developed with the navy in mind" можно ещё понимать как "имея ввиду интересы navy" (нави?)

    Так правильнее.
    — unknown (08/04/2013 10:40)   
    Майк Пэрри из Torproject предлагает подключиться[link37] к решению проблемы, практически в том виде, как мы её излагали (обмен статистикой между пользователями и её сверка постфактум с подписанными архивами торпроджекта — независимый аудит системы).

    На данный момент созрели API для удобного снятия статистики тор-процесса и можно написать модуль контроллера на Python.
    Гость (08/04/2013 11:35)   
    Предлагают студенту заняться на уровне GSoC :)

    Ссылки
    [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