03.11 // 10 способов раскрытия бридж-узлов Tor

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

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

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

#1: Перегрузка стратегий, основанных на открытом распространении адресов

Китай нарушил стратегию распространения бриджей через https в сентябре 2009 только за счёт имитации достаточного количества целевых легитимных пользователей путём использования различных подсетей интернета. Они также нарушили стратегию распространения бридж-узлов через GMail в марте 2010. Это было лёгкой атакой, поскольку количество доступных адресов для бриджей было мало по сравнению с возможностями атакующего (на тот момент 176 бриджей было роздано через https, 201 через GMail, 165 другими способами, такими как социальные сети), но вопрос не в масштабировании: нужна лучшая стратегия, которая требовала бы от атакующего значительно больших затрат работы, чем от благонамеренных пользователей.

#2: Запуск несторожевых неисходящих переотправляющих узлов для отслеживания соединений с непереотправляющих узлов

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

Эта атака лежала на поверхности пока не была задокументирована Женем и др., см. работу Extensive Analysis and Large-Scale Empirical Evaluation of Tor Bridge Discovery.

Защита, которую мы планируем, состоит в том, чтобы цепочки через бридж-узлы также использовали и сторожевые узлы. Наивный способ заключается в том, чтобы клиент выбирал множество сторожевых узлов в качестве своего следующего шага после бридж-узла; но тогда каждый новый клиент, использующий бридж-узел повышает свою раскрываемость. Лучшим способом будет предоставить посредством Tor-протокола свободно выбирать сторожевые узлы самому бридж-узлу для всех используемых им соединений: фактически это прозрачный слой над дополнительной одноузловой цепочкой внутри клиентской цепочки. Тем, кому знакома конструкция Babel, будет виден здесь трюк, называемый "inter-mix detours".

Использование слоя сторожевых узлов после бриджей даёт две возможности: первая — это полное удаление особенности "бриджи напрямую соединяются с несторожевыми узлами", превращая атаку из детерминированной в вероятностную. Во-вторых, это снижает раскрытие бриджей перед остальной частью сети, так как лишь только небольшое число переотправляющих узлов могут видеть прямое соединение с ними. К сожалению, компромисс смещается в сторону худшей производительности для пользователей бридж-узлов. См. proposal 188.

#3: Запуск сторожевых узлов и поиск различий в протоколе

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

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

#4: Запуск сторожевого узла и проведение тайминг-анализа

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

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

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

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

#5: Запуск переотправляющего узла, который пытается сделать обратное соединение с каждым обращающимся к нему клиентом на определённых портах

Многие бридж-узлы слушают входящие клиентские соединения на портах 443 и 9001. Противник может запустить переотправляющий узел и активно сканировать порты каждому соединяющемуся с ним клиенту, чтобы смотреть какой из этих сервисов работает на Tor-протокол. Эта атака опубликована Евгением Вассерманом Membership-concealing overlay networks и Джоном МакЛахланом On the risks of serving whenever you surf: Vulnerabilities in Tor's blocking resistance design, обе в 2009.

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

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

#6: Сканирование интернета в целях поиска сервисов, отвечающих на Tor-протокол

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

Существуют коварные комбинации #5 и #6 если представить себя на месте противника государственного масштаба: если наблюдать свой государственный файрволл на наличие SSL-соединений (поскольку Tor старается быть неотличимым от SSL-трафика), то можно проводить активные сканирования для всех видимых узлов соединений. Для компромисса в сторону эффективности взамен точности можно вести белый список уже проверенных узлов. Атака такого масштаба требует некоторой серьёзной разработки для большой страны, но ранние признаки указывают, что именно в этом направлении делает шаги Китай.

Ответом может быть предоставление бридж-узлом некоторого секрета для пользователя, по которому он узнаёт адрес бриджа и доказательство знания этого секрета до того как бридж позволит узнать о своём Tor-протоколе. Например, можно представить запуск вебсервера Apache SSL с модулем pass-through, который туннелирует трафик к переотправляющему узлу Tor в случае предоставления правильного пароля. Или Tor мог бы сам производить такую аутентификацию. В публикации BridgeSPA: Improving Tor Bridges with Single Packet Authorization предложено SPA-решение с недостатком в виде необходимости иметь root на обеих сторонах и специфичное по отношению к ОС.

Другое направление исследований состоит в помещении бридж-адресов за системы Telex, Decoy Routing или Cirripede.
Такие системы позволяют пользователю приватным образом внести метку в трафик (например в SSL-согласование) и таким образом разделить помеченный поток к Tor-узлу, в то время как непомеченный пойдёт как обычно. Так мы можем развернуть немодифицированный Apache в одном месте и немодифицированный Tor-бридж в другом. Связка Tor-клиента потребует некоторых программных доработок, также как некоторые детали разработки и развёртывания таких систем.

#7: Проведение взломов, затрагивающих инфраструктуру Tor

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

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

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

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

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

Одно из решений — децентрализация тестирования, так что мониторинг одного местоположения не даст информации о полном списке бридж-узлов. Но то, как и что распространять, снова выглядит переусложнённым неаккуратным решением с управленческой и исследовательской точек зрения. Другой метод в том, чтобы бриджи сами выстраивали частоту тестов доступности (они сейчас производят самотестирование перед публикацией, давая быстрый ответ оператору в случае ошибочных настроек). Тогда бриджи будут лишь анонимно публиковать аутентифицированное сообщение "всё ещё здесь" каждый час, так что (считая, что они говорят правду) директории бриджей никогда не будут делать никаких тестов. Но такое самотестирование также позволяет атаки пересчёта, поскольку мы строим цепочку через случайный переотправляющий узел и затем пытаемся продлить её обратно к адресу нашего бриджа! Может быть бриджи будут запрашивать свои сторожевые узлы по поводу самотестирования — они ведь сторожа, не так ли?

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

#9: Просмотр файрвола и глубокая инспекция пакетов (DPI) для потоков Tor

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

Эта проблема была исправлена за счёт того, что удалось сделать Tor-хэндшейк более похожим на SSL-хэндшейк, но было бы удивидительно, если в этой битве хоть когда-нибудь можно реально победить. Лучший ответ — это поощрение распространения модульного Tor транспорта, такого как obfsproxy и надеяться на то, что остальная часть исследовательского сообщества заинтересуется в создании инструментально-нейтральных средств передачи, с которыми легче смешиваться.

#10: Зиг-заг между бридж-узлами и пользователями

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

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

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

Дэн Бонех предложил альтернативное решение на основе хэширования с ключом адреса пользователя и отпечатков его бридж-узлов и возврата всем бриджам, которые соответствуют отпечатку пользователя после хэширования, первых b битов. Результатом становится кластеризация пользователей вокруг известных им бриджей. Эта особенность ограничивает ущерб от зиг-заг атаки, но не увеличивает ли он риск для некоторых стратегий распространения бриджей? Особенное беспокойство вызывает то, что стратегии основанные на социальных сетях, приводят к возникновению связей пользователей вокруг бриджей, аналогичных их социальным связям. Если изолировать социально связанных пользователей в одних и тех же областях, не усугубит ли это проблему? Также это предложение требует дополнительных исследований на предмет того, всегда ли можно получить примерно k-битовые результаты, даже если адресные пулы будут расти и без повторного внедрения зиг-заг уязвимостей.

11#: Что-нибудь ещё?

Источник: The Tor Project Blog