Часть 2

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

5. Сторожевые узлы

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

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

Для того, чтобы помочь в улучшении данной ситуации в Tor 0.1.1.2-alpha были впервые внедрены сторожевые узлы (изначально называемые "вспомогательными", которые были изобретены Wright, Adler, Levine и Shields и предложены в использовании для Tor Шverlier и Syverson ). В Tor 0.1.1.11-alpha они были доступны по умолчанию. Сейчас Tor-клиент выбирает небольшое количество Tor-узлов в качестве сторожевых и использует один из них в качестве первого шага для всех цепочек (до тех пор, пока эти узлы остаются функционирующими).

Это не затрагивает вероятность того, что будет скомпрометирован первый узел в цепочке, но это значит, что если сторожевые узлы, выбранные пользователем, не контролируются атакующим, то все его будущие цепочки будут безопасны. С другой стороны, пользователи, которые выбрали сторожевые узлы, контролируемые атакующим, будут иметь порядка M/N своих цепочек скомпрометированными, где M — количество сетевых ресурсов, контролируемых атакующим и N — полные ресурсы сети. Без сторожевых узлов все цепочки имели шанс быть скомпрометированными с вероятностью (M/N)².

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

6. Мостовые узлы, устойчивость к цензуре и сменные транспортные протоколы

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

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

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

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

7. Изменения и усложнения в алгоритмаъ выбора пути

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

Взвешенный выбор узлов пропорционально пропускной способности

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

Поэтому Tor 0.0.8rc1 начал давать клиентам возможность выбора узлов по объявленной пропускной способности серверов, так что сервер с 10-кратным превосходством в пропускной способности мог бы получать в 10 раз больше цепочек и вследствие этого (вероятностно) в 10 раз больше трафика.

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

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

Корневые узлы, содержащие сведения о пропускной способности

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

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

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

Избегание узлов одинаковых семейств в одной цепочке

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

С этой целью клиенты не используют какие-либо узлы, IP-адреса которых принадлежат той же самой подсети /16 — когда мы проектировали сеть, было намного сложнее получить большое количество совсем отличающихся адресов, чем большое количество сконцентрированных адресов. (На Роджера и Ника оказала влияние студенческая жизнь в MIT, где их общежитие полностью заняло 18.244.0.0/16). Это решение несовершенно, но возможно оно лучше, чем ничего.

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

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