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