id: Гость   вход   регистрация
текущее время 09:39 06/10/2024
Владелец: unknown (создано 25/10/2012 12:19), редакция от 06/11/2012 08:28 (автор: SATtva) Печать
Категории: софт, tor
создать
просмотр
редакции
ссылки

Часть 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) и не подразумевает передовые технологии и устойчивость. Решением в случае сбоев в достижении консенсуса (что к счастью происходит крайне редко) является поиск неисправностей и устранение их вручную.

Экономия байтов при помощи микродескрипторов


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


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


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


Это наблюдение позволило нам перейти (в Tor 0.2.3.1-alpha, май 2011) к дизайну, где корневые узлы, в качестве части процесса своего голосования, создают аббревиатурную версию каждого рекомендованного ими дескриптора. На текущий момент она содержит только краткое описание политики исходящих соединений роутера и его текущий onion-ключ. Теперь клиенты могут загружать эти аббревиатурные "микродексрипторы", которые снижают количество информации, загружаемой с каждого узла примерно на 75%. В дальнейшем, поскольку данные здесь меняются сравнительно нечасто, это в конечном итоге снижает и частоту, с которой клиенты получают информацию о каждом роутере.

Туннелирование соединений с корневыми серверами директорий через Tor


В 0.1.2.5-alpha (январь 2007), мы добавили поддержку по умолчанию для клиентов — загружать все документы директорий по HTTP через Tor, вместо того, чтобы контактировать с корневыми серверами и кэшами по нешифрованному HTTP. Это изменение помогает клиентам избегать профилирования.


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

2. Улучшение безопасности скрытых серверов

Децентрализованная система директорий скрытых сервисов


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


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

Улучшенная модель авторизации на скрытых сервисах


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

3. Ускоренное создание цепочки первого шага с помощью CREATE_FAST


На каждой стадии продолжения цепочки на один шаг, клиент осуществляет протокол согласования ключей Диффи-Хеллмана (DH) с узлом для этого шага. Это обеспечивает конфиденциальность (и наперёд заданную секретность) полезного содержимого ячеек, перенаправляемых для прохождения промежуточных узлов. Изначально Tor также осуществлял DH и на первом шаге, даже несмотря на то, что DH-обмен уже выполнен как часть TLS-протокола. DH очень дорого обходится в вычислительном отношении для обеих сторон, так что Tor 0.1.1.10-alpha (декабрь 2005) прекратил использование DH-согласования на первом шаге за счёт отправки ячейки CREATE_FAST (в отличие от просто CREATE), что позволяет генерировать ключевой материал просто путём хэширования случайных чисел, посылаемых клиентом и сервером.

4. Организация очереди и планировщик ячеек


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


Ранние версии Tor обрабатывали ячейки в порядке получения исходящих соединений, зашифровывали/расшифровывали их и немедленно отдавали их следующему узлу цепочки или соответствующему входящему или исходящему соединению. Однако, такой подход часто создавал большую буферизацию на выходе, в которой ячейкам из слабых цепочек было не протолкнуться.


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


После того, как впервые были выполнены такие очереди ячеек в 0.2.0.1-alpha (июнь 2007), мы выбирали, какие ячейки доставлять за счёт ротации каждой цепочки по round-robin алгоритму. В Tor 0.2.2.7-alpha (январь 2010) мы начали вместо этого привязывать цепочки к каждому соединению, так что цепочки с небольшими и нечастыми объёмами ячеек станут получать меньше задержек, чем цепочки, используемые для передачи большого объёма данных. (В особенности когда мы помещаем ячейку в исходящее соединение, мы выбираем цепочку с наименьшим общим числом экспоненциального распада ячеек. В настоящее время период полураспада каждой ячейки составляет 30 секунд).


Во второй части мы рассмотрим изменения в том, как Tor выбирает пути и его новых антицензурных свойствах.


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


 
Несколько комментариев (9) [показать комментарии/форму]
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3