id: Гость   вход   регистрация
текущее время 16:57 28/03/2024
Владелец: unknown редакция от 25/10/2012 17:23 (автор: unknown) Печать
Категории: софт, tor
создать
просмотр
редакции
ссылки

Это старая редакция страницы Библиотека / Статьи / 8 Y / Part 01 за 25/10/2012 17:23.


Часть 1

1. Получение данных об узлах и протокол директорий


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


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


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


Ранние версии Tor решали эту проблему с помощью такого объекта как "Директория" — каждый сервер генерировал подписанный "дескриптор роутера" и загружал его в один из небольшого набора (всего трёх) "корневых директорий". Каждая из этих директорий генерировала подписанный объединённый список роутеров и раздавала этот список клиентам через HTTP.


Эта система имела некоторое число существенных проблем:


  • Клиентам нужно было без конца загружать одни и те же десрипторы, неважно, нужны они им или нет.
  • Каждый клиент должен доверять каждому серверу корневой директории, из числа тех, с которыми он общался в самый последний раз: вместо того, чтобы обеспечить распределённое доверие, каждый сервер директорий был полностью доверяем сам по себе и любой некорректно функционирующий сервер директорий мог полностью скомпрометировать всех клиентов, которые с ним общались.
  • За счёт отклонения части запросов, серверы корневых директорий создают неравномерность в сведениях клиентов, что в наихудшем варианте позволяло противнику разделять клиентов, основываясь на знании того, с какого сервера директорий клиент чаще получал статистику.
  • Нагрузка на сервера директорий стремилась к чрезмерному росту, т.к. каждый клиент контактировал с каждым корневым сервером директорий.
  • Содержимое директорий посылалось в незашифрованном виде, что позволяло его легко прослушать по пути к клиенту.

Ранние изменения в системе директорий версии 1


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


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

Вторая версия директорий (устаревашая)


В Tor 0.1.1.8-alpha (октябрь 2005) мы сделали первую попытку решения проблемы доверия. Теперь у нас каждый корневой сервер директорий стал подписывать полный бюллетень статуса сети, включая список всех узлов, которые, как он полагает, должны быть в сети, отпечаток открытого ключа каждого узла, и отпечаток каждого дескриптора роутера узла. Клиенты должны были загружать один из этих документов, подписанный каждым корневым сервером, а затем вычислять, основываясь на всех имеющихся у них документах, какой набор узлов, представляет консенсусный взгляд всех корневых серверов.


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


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


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


Все проделанные до этого изменения были ориентированы на снижение нагрузки по сетевому трафику на серверной стороне: мы считали, что у клиентов достаточно пропускной способности и хотели избежать перегрузки корневых серверов и кэшей. Но как только мы захотели добавить больше корневых серверов директорий (количество около 5 — это всё ещё неудобно малое число), начальная загрузка клиентов требовала получения большего количества сетевых статусов от каждого нового сервера корневых директорий. В начале 2008 года, каждый документ статуса содержал суммарный список из 2500 узлов и имел размер около 175 Кб в сжатом виде, означающем, что требовалось 875 Кб документов статуса для старта, а затем ещё мегабайт дескрипторов после этого. И мы не могли добавить больше корневых серверов директорий, не сделав проблему ещё хуже.

3 версия: консенсус и голосование по директориям


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


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


Алгоритм голосования разработан для данного случая (ad hoc) и не подразумевает передовые технологии и устойчивость. Решением в случае сбоев в достижении консенсуса (что к счастью происходит крайне редко) является поиск неисправностей и устранение их вручную.


Оглавление | Дальше