Как GFW обнаруживает и блокирует Shadowsocks

Shadowsocks – один из самых популярных инструментов обхода цензуры в Китае. С мая 2019 года появилось множество сообщений о блокировке Shadowsocks для китайских пользователей. В этом исследовании мы раскрываем, как Великий Китайский Файрвол (GFW) обнаруживает и блокирует Shadowsocks и его варианты. Используя экспериментальные измерения, мы обнаружили, что GFW использует длину и энтропию первого пакета данных в каждом соединении для идентификации вероятного трафика Shadowsocks, а затем отправляет семь различных типов активных зондов на соответствующие серверы, чтобы проверить правильность своего предположения.

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

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

Ключевые слова: Shadowsocks, Великий Китайский Файрвол, активное зондирование, обход цензуры

1. Введение

Shadowsocks – это протокол обхода цензуры в Интернете, особенно популярный в Китае. Согласно исследовательскому опросу, проведенному в июле 2015 года, 21% из 371 преподавателя и студента Университета Цинхуа использовали Shadowsocks для обхода цензуры в Китае. Популярность Shadowsocks обусловлена его простотой. Его легковесный дизайн сводит к минимуму нагрузку на проксируемый трафик и упрощает его реализацию на различных платформах. Большой рынок реселлеров прокси-серверов, ориентированный на получение прибыли, а также многочисленные учебные пособия и сценарии установки в один клик упростили установку и использование Shadowsocks, сделав его популярным даже среди нетехнических пользователей.

Начиная с октября 2017 года пользователи в Китае сообщали о том, что их серверы Shadowsocks становятся ненадежными или блокируются Великим Китайским Файрволом (GFW), особенно в политически чувствительные периоды. Самое последнее такое событие произошло в середине сентября 2019 года, когда пользователи Shadowsocks сообщили о внезапном увеличении числа блокировок. В разделе 2.2 обобщена информация о прошлых событиях блокировки. Несмотря на косвенные доказательства того, что GFW способен обнаруживать и блокировать серверы Shadowsocks, мало что известно о том, как именно он это делает. Важность Shadowsocks для обхода цензуры и загадочное поведение GFW побуждают нас изучить и понять лежащие в основе механизмы обнаружения и блокировки.

Рисунок 1: Как работает активное зондирование. Подлинный клиент Shadowsocks подключается к серверу Shadowsocks; Как только GFW пассивно определяет, что соединение может быть Shadowsocks, он направляет свои активные зонды, чтобы подтвердить это предположение.

Наше систематическое исследование показывает, что GFW начал идентифицировать серверы Shadowsocks, используя комбинацию пассивного анализа трафика и активного зондирования. На рисунке 1 показана общая идея: GFW сначала обнаруживает подозрительный трафик Shadowsocks, используя такие характеристики, как размер и энтропия первого пакета данных в каждом соединении. Как только сервер попадает под подозрение, GFW отправляет ему активные зонды на разных этапах, чтобы подтвердить, действительно ли этот сервер является сервером Shadowsocks. Зонды представляют собой частичные повторы прошлых легитимных соединений и случайные зонды различной длины. Мы подозреваем, что зонды предназначены для атаки на уязвимости обнаружения в различных реализациях Shadowsocks. Известно, что GFW использует активное зондирование против различных инструментов обхода цензуры с 2011 года, но методы, используемые сейчас против Shadowsocks, являются новыми и более сложными, чем сообщалось ранее.

Вкратце, наша работа вносит следующий вклад:

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

2. Справочная информация о Shadowsocks

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

Важно знать несколько деталей работы шифрования Shadowsocks, чтобы оценить конструкцию зондов, описанную в разделе 3.2. Shadowsocks определяет два основных класса криптографических конструкций, известных в контексте протокола как «потоковые шифры» и «шифры AEAD». Потоковая конструкция шифра криптографически слабая – она обеспечивает только конфиденциальность, но не целостность или аутентификацию, и по этой причине не рекомендуется к использованию. Конструкция шифра AEAD (аутентифицированное шифрование с присоединенными данными) была разработана для устранения недостатков потоковой конструкции шифра и обеспечивает конфиденциальность, целостность и аутентификацию. Обе конструкции основаны на главном пароле, который совместно используют клиент и сервер, и обе предполагают, что клиент должен продемонстрировать знание общего пароля перед использованием прокси-сервера (хотя, как мы увидим, с потоковыми шифрами это требование не является строгим).

Таблица 1: Временная шкала всех основных экспериментов. Три набора экспериментов охватывают недели и месяцы. Shadowsocks, Sink и Brdgrd относятся к экспериментам в разделе 3.1, разделе 4.1 и разделе 7.1 соответственно.

С потоковыми шифрами сетевой поток в обоих направлениях представляет собой один длинный зашифрованный текст, которому предшествует случайный вектор инициализации:

[IV переменной длины][зашифрованные данные...]

Клиент и сервер используют один и тот же ключ шифрования, но разные векторы инициализации. Длина вектора инициализации может составлять 8, 12 или 16 байт в зависимости от того, какой шифр настроен.

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

[соль переменной длины][зашифрованная длина, 2 байта][тег длины, 16 байт][зашифрованные данные][тег данных, 16 байт][зашифрованная длина, 2 байта][тег длины, 16 байт][зашифрованные данные][тег данных, 16 байт]...

Весь поток предваряется солью, которая объединяется с общим секретным паролем для создания ключа сеанса для каждого направления. Соль может быть 16, 24 или 32 байта.

В обеих конструкциях первыми данными, отправляемыми клиентом по туннелю, является спецификация цели «хост:порт», структура которой заимствована из прокси-протокола SOCKS. Первый байт – это тип адреса, указывающий формат следующих байтов. Существует три типа адресов:

[0x01][IPv4-адрес, 4 байта][порт, 2 байта]

[0x03][длина, 1 байт][имя хоста][порт, 2 байта]

[0x04][IPv6-адрес, 16 байт][порт, 2 байт]

Существует множество реализаций Shadowsocks, и они различаются поддерживаемыми функциями. Не каждая реализация поддерживает все возможные криптографические конструкции; например, OutlineVPN поддерживает только шифры AEAD, но не потоковые шифры. Некоторые реализации предпринимают шаги для предотвращения атак с повторением, а некоторые – нет. Это означает, что зондирующий злоумышленник может столкнуться с разной реакцией на зонды в зависимости от того, какая реализация Shadowsocks используется. В этой работе мы сосредоточимся на двух наиболее популярных реализациях – Shadowsocks-libev и OutlineVPN, но описанные нами уязвимости могут относиться и к другим реализациям.

2.1. Исторические уязвимости и средства защиты

В августе 2015 года BreakWa11 обнаружил уязвимость активного зондирования в потоковых шифрах Shadowsocks, связанную с отсутствием защиты целостности. Злоумышленник может установить множество соединений с подозреваемым сервером Shadowsocks и воспользоваться податливостью зашифрованного текста, чтобы перебрать все возможные значения байта, соответствующего типу адреса в спецификации цели. Поскольку только 0x01, 0x03 и 0x04 являются допустимыми типами адресов, известная часть соединений будет иметь тайм-аут, отличный от остальных. Разработчики Shadowsocks устранили уязвимость, заставив сервер не разрывать соединение немедленно, если спецификация цели содержит неизвестный тип адреса.

Разработчики Shadowsocks попытались дополнительно решить эту проблему, введя режим «одноразовой аутентификации», в котором каждый блок данных будет иметь собственный аутентификатор. Но отсутствие защиты целостности в префиксах длины блока привело к появлению еще одной уязвимости активного зондирования. В феврале 2017 года шифры AEAD стали частью спецификации протокола, что устранило эту проблему аутентификации.

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

2.2. Прошлая блокировка Shadowsocks

Начиная с октября 2017 года пользователи Интернета в Китае сообщали о блокировке своих серверов Shadowsocks по порту или IP-адресу. О заметных случаях блокировки сообщалось в октябре 2017 года и январе 2018 года, одновременно с двумя важными политическими съездами в Китае. После двух съездов многие пользователи сообщили, что их серверы разблокированы. Противоположные данные поступили от Уайли и др., которые в то время ежедневно проверяли доступность Shadowsocks из разных стран мира, но сообщили, что не видели никаких доказательств блокировки Shadowsocks где-либо.

Сообщалось, что крупномасштабные блокировки происходили в основном в политически чувствительные периоды, в том числе во время 30-летия протестов на площади Тяньаньмэнь 1989 года, 70-летия Китайской Народной Республики и 4-го пленума Центрального комитета Коммунистической партии Китая 19-го созыва. Самая последняя волна сообщений началась примерно 16 сентября 2019 года.

3. Характеристика зондов и инфраструктуры зондирования

Здесь мы описываем эксперименты, которые мы провели, чтобы собрать и понять активные зонды GFW. Основываясь на коллекции из 51 837 активных зондов, обнаруженных в ходе ряда экспериментов, мы отвечаем на следующие вопросы:

• Какие типы зондов наблюдаются и при каких условиях?
• Откуда берутся зонды?
• Есть ли у зондов какие-либо «отпечатки пальцев», которые раскрывают информацию о базовой инфраструктуре зондирования?
• Какова задержка между легитимным соединением и зондами, которые на него реагируют?

3.1. Эксперимент с сервером Shadowsocks

Мы настроили собственные серверы Shadowsocks и попытались спровоцировать GFW на их зондирование. Для этого мы подключались к нашим серверам, используя клиенты Shadowsocks, и отправляли трафик HTTP и HTTPS через зашифрованный прокси-туннель, используя веб-браузеры и curl в качестве автоматизированных драйверов. Мы фиксировали пакеты на обоих концах для анализа. Во всех наших экспериментах мы использовали немодифицированные клиенты и серверы, не создавали никаких специальных правил брандмауэра и не устанавливали никаких плагинов обфускации. Как кратко изложено в таблице 1, эксперименты проводились в течение четырех месяцев – с 29 сентября 2019 года по 21 января 2020 года.

Поскольку мы не могли заранее знать, какие функции GFW может использовать для идентификации Shadowsocks, мы максимально расширили охват, используя разные реализации и версии Shadowsocks, а также выбирая разные алгоритмы шифрования. Мы использовали две реализации: Shadowsocks-libev и OutlineVPN.

Shadowsocks-libev. Мы установили клиенты Shadowsocks-libev на пяти VPS в центре обработки данных Tencent Cloud Beijing и серверы Shadowsocks-libev на пяти VPS в центре обработки данных Digital Ocean UK. Каждый клиент был настроен на подключение только к одному из серверов. Две пары клиентов и серверов использовали Shadowsocks-libev версии 3.1.3, а остальные три пары – версии 3.3.1. В качестве контроля мы настроили дополнительный VPS в том же центре обработки данных в Великобритании и никогда не подключались к нему, фиксируя только весь входящий трафик.

Мы генерировали клиентский трафик с помощью curl. Через прокси-сервер Shadowsocks мы постоянно получали один из веб-сайтов с заданной частотой: https://www.wikipedia.org, http://example.com и https://gfw.report.

OutlineVPN. Мы установили сервер OutlineVPN версии 1.0.7 в университетской сети США. Мы использовали последнюю по состоянию на октябрь 2019 года версию клиента OutlineVPN. Клиент находился в домашней сети в Китае. Трафик клиента обеспечивался экземпляром Firefox, настроенным на автоматический просмотр подмножества миллиона лучших сайтов Alexa, подвергающихся цензуре в Китае.

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

3.2. Типы зондов

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

Первая категория зондов, основанных на повторах, имеет полезную нагрузку, полученную из первого пакета данных некоторого ранее записанного легитимного соединения. Мы присваиваем типам зондов в этой категории имена, начинающиеся с «R», что означает «повтор»:

• Тип R1: Идентичный повтор.
• Тип R2: Повтор с измененным байтом 0.
• Тип R3: Повтор с измененными байтами 0–7 и 62–63.
• Тип R4: Повтор с измененным байтом 16.
• Тип R5: Повтор с измененными байтами 6 и 16.

Зонды типов R3, R4 и R5 были получены только в эксперименте OutlineVPN, но не в эксперименте Shadowsocks-libev. В наших экспериментах было получено только два зонда типа R5.

Другая категория зондов, кажущихся случайными, имеет разную длину. Их содержимое не похоже на предыдущее легитимное соединение никаким образом, который мы можем идентифицировать. Мы даем типам зондов в этой категории имена, начинающиеся с «NR», что означает «без повтора»:

• Тип NR1: Зонды длиной 7–9, 11–13, 15–17, 21–23, 32–34, 40–42 или 48–50 байт.
• Тип NR2: Зонды длиной ровно 221 байт.

На рисунке 2 показано распределение зондов типов NR1 и NR2.

Рисунок 2: Количество появлений случайных зондов (типы NR1 и NR2) по длине. Обратите внимание на две разные вертикальные оси. Длины зондов типа NR1 равномерно распределены в тройках (n − 1, n, n + 1) для n = 8, 12, 16, 22, 33, 41, 49. Зонды типа NR2 имеют длину 221 и примерно в три раза чаще встречаются, чем все зонды NR1 вместе взятые.

Длины зондов NR1 распределены в тройках с центрами в 8, 12, 16, 22, 33, 41 и 49 байт. Подробнее об этом распределении мы расскажем в разделе 5.2.

3.3. Происхождение зондов

Простая идея защиты от активного зондирования – обнаружить IP-адреса зондов и запретить их. Ниже мы покажем, что реализовать такую защиту может быть сложно, поскольку GFW зондирует из большого и разнообразного пула IP-адресов с высокой текучестью.

IP-адреса. 51 837 активных зондов были отправлены с 12 300 уникальных исходных IP-адресов, все из которых находятся в Китае. На рисунке 3 показано распределение количества зондов, отправленных на уникальный IP-адрес. В отличие от предыдущей работы, в которой было обнаружено, что «95% адресов появляются только один раз», в наших тестах более 75% адресов отправили более одного зонда. Наиболее распространенные IP-адреса зондов приведены в таблице 2.

Рисунок 3: Кумулятивное количество зондов на IP-адрес зонда.

Таблица 2: Наиболее распространенные IP-адреса зондов и количество их появлений.

Мы сравнили наш список IP-адресов зондов с 934, которые, как было замечено, отправляли активные зонды на серверы Tor в 2018 году (по данным Данны и др.), и 22 000, которые, как было замечено, отправляли различные типы активных зондов в период с 2010 по 2015 год (по данным Энсафи и др.). На рисунке 4 показано, что три набора пересекаются лишь незначительно. Отметим, что IP-адрес 202.108.181.70, на который приходилось чрезмерное количество зондов в предыдущей работе, в наших данных не фигурирует. Небольшое перекрытие неудивительно, учитывая, что в прошлых работах наблюдалась высокая текучесть IP-адресов зондов.

Рисунок 4: Пересечение исходных IP-адресов зондов в независимо собранных наборах данных.

Автономные системы. Распределение зондов по автономным системам (AS) показано в таблице 3. Двумя AS, на которые приходится наибольшее количество зондов Shadowsocks, являются AS4837 (CHINA169-BACKBONE CNCGROUP China169 Backbone) и AS4134 (CHINANET-BACKBONE № 31, улица Цзиньжун). Эти две были наиболее распространенными и в предыдущей работе. Другими AS, которые пересекаются с предыдущей работой, являются AS17816, AS9808, AS56046, AS17638, AS56047 и AS17622. На AS17622 (CNCGROUP-GZ China Unicom Guangzhou network) приходится гораздо большая доля зондов, чем в предыдущей работе. Другие ранее подтвержденные AS в наших данных отсутствуют, в том числе AS7497 (CSTNET-AS-AP Computer Network Information Center), которая была третьим по распространенности источником зондов, замеченным Энсафи и др. В нашем наборе данных также есть AS, которые ранее не были задокументированы как источники активных зондов.

Таблица 3: Количество уникальных IP-адресов зондов на автономную систему во всех экспериментах.

3.4. Дактилоскопия зондов

Как и в предыдущей работе, мы снимаем отпечатки пальцев на уровне пакетов активных зондов. На IP-уровне мы исследуем поля ID и TTL. На TCP-уровне мы смотрим на исходные порты и временные метки.

IP ID и TTL. Мы снимаем отпечатки пальцев IP ID и TTL пакетов PSH/ACK, отправляемых зондами. Как и в работе Энсафи и др., мы не находим четкой закономерности в последовательностях IP ID и видим, что TTL остается в диапазоне 46–50.

Исходные порты TCP. Около 90% зондов поступило с исходных портов в диапазоне 32 768–60 999. Этот диапазон, выделенный на рисунке 5, оказывается диапазоном исходных портов по умолчанию для многих ядер Linux. Зонды никогда не использовали исходный порт ниже 1024 (точный минимум, который мы видели в одном эксперименте, составлял 1212). Эти результаты отличаются от результатов предыдущей работы, в которой наблюдалось использование всех портов, и никакой диапазон портов не был более распространенным, чем любой другой.

Рисунок 5: КФР номеров исходных портов TCP зондов в одном эксперименте, включая 1576 зондов.

Временная метка TCP (TSval). Временная метка TCP – это 32-битный счетчик, который увеличивается с фиксированной скоростью, прикрепленный к каждому TCP-сегменту, кроме RST. Это не абсолютная временная метка, а относительная, показывающая, как и когда был инициализирован счетчик, а скорость его увеличения варьируется в зависимости от операционной системы. На рисунке 6 показано значение временной метки, прикрепленное к сегменту SYN каждого зонда. На рисунке показано, что, хотя зонды используют тысячи исходных IP-адресов, они не могут быть полностью независимыми, поскольку используют небольшое количество последовательностей временных меток TCP. В данном случае существует не менее семи различных физических систем или процессов, причем на одну из семи приходится подавляющее большинство зондов. Мы говорим «не менее» семи, потому что мы не смогли бы различить два процесса, последовательности TSval которых очень близки (что может произойти, например, если оба процесса были перезапущены примерно в одно и то же время). Мы измерили, что наклон линейных последовательностей составляет почти ровно 250 Гц, за исключением одного небольшого кластера из 22 близко расположенных точек, наклон которых ближе к 1000 Гц. Есть два случая, когда последовательность достигла максимального значения 2³² − 1 и перешла к 0. Сравните рисунок 6 с рисунком 11(c) из работы Энсафи и др., где также показаны последовательности 250 Гц и 1000 Гц.

Рисунок 6: Независимые процессы, выявленные по общим последовательностям временных меток TCP. Помеченные линии маркеров имеют наклоны ровно 250 Гц и 1000 Гц. Небольшой кластер из 22 невоспроизводящих зондов на линии 1000 Гц локально имеет наклон 1009 Гц, но здесь измерение менее достоверно, поскольку они охватывают только около 3,5 с. Линия 1000 Гц не становится линией 250 Гц, даже если ее соединить с одной из разреженных точек данных без повтора у левого края рисунка.

3.5. Задержка атак с повторением

GFW может записать первый пакет данных подлинного клиентского соединения и воспроизвести его позже, возможно, с изменениями, в качестве активного зонда. На рисунке 7 показана вариабельность задержки между моментом установления легитимного соединения и моментом отправки GFW зондов, основанных на повторении, полученных из этого соединения. Поскольку полезные нагрузки зондов могут воспроизводиться более одного раза (до 47 раз в одном случае), мы представляем два распределения – с повторяющимися полезными нагрузками и без них. Оранжевая линия представляет задержку первого появления каждой полезной нагрузки зонда, основанного на повторении, а синяя линия показывает задержку всех зондов, основанных на повторении, включая повторяющиеся полезные нагрузки. Общее количество зондов составляет 3269 для первых появлений и 11 137 для всех появлений.

Рисунок 7: КФР задержки зондов, основанных на повторении. Обратите внимание на логарифмическую ось x.

Более 20% первых повторов поступили в течение одной секунды; более 50% – в течение одной минуты; и более 75% – в течение 15 минут. Зонды, основанные на повторении, могут отправляться практически немедленно или могут храниться на удивление долго перед отправкой. Кратчайшая задержка, которую мы наблюдали, составляла 0,28 секунды, а самая продолжительная – 570 часов.

4. Что запускает активное зондирование

Существуют альтернативные гипотезы о том, как GFW может обнаруживать серверы Shadowsocks. Одна из них – это широкомасштабное упреждающее сканирование портов; другая – это реактивное зондирование, запускаемое легитимными соединениями. Тот факт, что неиспользуемый хост управления в предыдущем разделе не получил никаких активных зондов, заставляет нас отбросить гипотезу о упреждающем сканировании. Вместо этого мы предполагаем, что зонды отправляются только тогда, когда система зондирования видит подозрительное соединение Shadowsocks.

Что же тогда представляет собой подозрительное соединение Shadowsocks с точки зрения GFW? В этом разделе мы рассмотрим следующие вопросы:

• Сколько трафика требуется для запуска активных зондов?
• Почему зонды типов R3, R4 и R5 отправлялись только на сервер OutlineVPN, но не на сервер Shadowsocks-libev?
• Учитывает ли GFW длину пакетов?
• Учитывает ли GFW энтропию полезной нагрузки пакета?
• Приводят ли соединения извне внутрь (когда клиент находится за пределами Китая, а сервер – внутри) к такому же активному зондированию, как и соединения изнутри наружу?

4.1. Эксперименты

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

Нам помогают два наблюдения. Во-первых, байтовые потоки, отправляемые между клиентами и серверами Shadowsocks, по своему замыслу неотличимы от случайных. Это означает, что может оказаться ненужным использовать реальную клиентскую реализацию Shadowsocks; мы можем запускать активные зонды, отправляя случайные данные. Во-вторых, как описано в разделе 3.5, зонды с повторением могут отправляться уже через 0,28 секунды после легитимного пакета данных. GFW мог видеть только самое начало потока от клиента к серверу, прежде чем решить, что трафик подозрительный.

Руководствуясь этими двумя наблюдениями, мы реализовали TCP-клиент, который подключается к TCP-серверу и отправляет один пакет данных с заданной длиной и энтропией Шеннона. Мы реализовали сервер с двумя режимами работы: режимом поглощения и режимом ответа. В режиме поглощения сервер принимает TCP-соединения, но не отвечает никакими данными и закрывает соединения через 30 секунд. В режиме ответа сервер отвечает на зонды – но не на наши собственные клиенты – от 1 до 1000 байт случайных данных.

В таблице 4 кратко описан дизайн экспериментов со случайными данными. В таблице 1 показан временной интервал эксперимента. Клиенты работали на разных VPS в одном и том же центре обработки данных Tencent в Пекине. Все серверы работали в одном и том же центре обработки данных Digital Ocean в США. IP-адреса клиентов и серверов не использовались повторно в разных экспериментах.

Таблица 4: Сводная информация об экспериментах со случайными данными. [x, y] означает, что значение выбирается случайным образом и равномерно из диапазона независимо для каждого соединения. В эксперименте 1 сервер был переключен из режима поглощения в режим ответа через 310 часов; мы пометили два подэксперимента как 1.a и 1.b.

4.2. Результаты и анализ экспериментов

Для запуска активных зондов требуется мало трафика. Наш сервер поглощения, несмотря на то, что он не был настоящим сервером Shadowsocks и никогда не отправлял данные, получал много тех же типов зондов, что и в эксперименте с сервером Shadowsocks в разделе 3.1. После TCP-квитирования достаточно одного пакета данных от клиента к серверу, чтобы запустить активные зонды.

Воспроизводятся только определенные длины. Хотя наши клиенты отправляли пакеты данных длиной от 1 до 2000 байт, практически все зонды, которые были определены как повторы, имели длину полезной нагрузки от 160 до 700 байт, а максимальная длина составляла 999 байт. На рисунке 8 показано распределение длин зондов в эксперименте 1.a. Распределение длин демонстрирует ступенчатый характер, отражающий тот факт, что определенные длины с большей вероятностью будут воспроизведены. А именно, длины зондов с повторением, как правило, имеют определенные остатки от деления на 16. Рассматривая зонды типа R1 (тип R2 аналогичен), из 376 зондов, длина которых находится в интервале 168–263 байта, 72% имеют длину, остаток от деления которой на 16 равен 9; из 1558 в интервале 384–687 байт 96% имеют длину, остаток от деления которой на 16 равен 2; а из 749 в среднем интервале 264–383 байта есть смесь остатков 9 (37%) и 2 (32%). Результаты показывают, что GFW учитывает длину пакета при классификации трафика Shadowsocks. Длина пакета – это разумная характеристика для использования, поскольку Shadowsocks не дополняет содержимое туннеля, лишь случайно изменяя распределение длины базового пакета, добавляя префикс заголовка адреса (см. раздел 2) и, с шифрами AEAD, префиксы и теги длины. Таким образом, распределение длины полезной нагрузки трафика Shadowsocks напоминает распределение базового трафика, который часто представляет собой HTTP или TLS.

Рисунок 8: КФР длин полезной нагрузки зондов, основанных на повторении, за 310 часов эксперимента 1.a. Длины зондов с повторением демонстрируют ступенчатый характер.

Пакеты с высокой энтропией с большей вероятностью будут воспроизведены. В поддержку этого вывода свидетельствуют два факта. Во-первых, на рисунке 9 показано, что, хотя пакеты со всеми энтропиями могут быть воспроизведены, пакет с высокой энтропией на байт, равной 7,2, почти в четыре раза чаще воспроизводится, чем пакет с низкой энтропией, равной 3,0. Во-вторых, эксперименты 1.a и 2 отличаются только энтропией пакетов, и за тот же период времени сервер в эксперименте 1.a получил значительно больше зондов, чем в эксперименте 2.

Рисунок 9: Доля зондов, основанных на повторении, на легитимное соединение в эксперименте 3, в зависимости от энтропии на байт легитимного соединения.

Зонды типов R3 и R4 не отправляются, пока сервер не ответит на зонды типов R1 и R2. Тысячи зондов, полученных в экспериментах 1.a, 2 и 3, можно было бы классифицировать как типы R1, R2 или NR2. Другими словами, нам не удалось запустить зонды типов R3, R4, R5 или NR1 в этих экспериментах. Этот результат напомнил нам о том, что в эксперименте, описанном в разделе 3.1, зонды типов R3, R4 и R5 были получены только серверами OutlineVPN, но не серверами Shadowsocks-libev.

Как будет подробно рассказано в разделе 5.3, одно из основных отличий Shadowsocks-libev от используемой нами версии OutlineVPN заключается в том, что Shadowsocks-libev имеет фильтр для защиты от атак с повторением, а OutlineVPN – нет. (По крайней мере, в той версии, которую использовали мы, – с тех пор в OutlineVPN добавлена защита от повторов.) По этой причине серверы Shadowsocks-libev не отвечают на точные повторы предыдущих соединений, в отличие от серверов OutlineVPN.

Поэтому мы предполагаем, что GFW не отправляет зонды типов R3, R4 и R5, пока сервер не ответит на зонды типов R1 и R2. Мы переключили сервер в эксперименте 1.a в режим ответа через 310 часов работы в режиме поглощения. Вскоре после того, как сервер начал отвечать на зонды типов R1 и R2, он начал получать большое количество зондов типов R3 и R4. Сервер продолжал получать зонды типов R1 и R2.

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

Мы не знаем, почему зонды типов R5 и NR1 не появились ни в одном из наших четырех экспериментов со случайными данными.

Обнаружены новые типы зондов. Серверы поглощения/ответа получали зонды, которые не соответствовали типам зондов, замеченным в нашем предыдущем эксперименте с Shadowsocks-libev и OutlineVPN. В эксперименте 1.b мы увидели 11 зондов, основанных на повторении, у которых были изменены байты с 16 по 32. Кроме того, мы увидели много невоспроизводящих зондов во всех четырех экспериментах. В общей сложности было 9 зондов по 53 байта, 5 зондов по 56 байт, 3 зонда по 169 байт, 1 зонд по 180 байт и 1 зонд по 402 байта.

GFW не делает различий между направлениями трафика. Мы настроили сервер Shadowsocks в Китае и подключались к нему извне. Проксируемый трафик генерировался путем автоматического просмотра подмножества миллиона лучших сайтов Alexa. Сервер получил большое количество запросов активного зондирования. Этот результат показывает, что GFW зондирует подозрительные серверы независимо от того, находится ли сервер внутри или за пределами Китая. Это двунаправленное поведение запуска отличается от наблюдения Винтера и Линдскога о том, что соединения Tor извне внутрь не запускали активное зондирование. С другой стороны, известно, что GFW не различает направленность трафика для многих протоколов, включая DNS, HTTP и TLS. Чувствительность GFW к направленности даже менялась со временем, как в случае с блокировкой TLS ESNI, которая была двунаправленной в течение двух недель, прежде чем стать однонаправленной.

5. Намерение, стоящее за зондами

Как обсуждалось в разделе 3.2, мы обнаружили семь различных типов активных зондов к нашим серверам Shadowsocks. Естественный вопрос: какую информацию GFW может получить из этих зондов? В отличие от предыдущей работы, для нас на этот вопрос нельзя ответить, просто взглянув на зонды. Мы предполагаем, что если зонды вызывают реакции сервера Shadowsocks, отличные от реакций серверов, не относящихся к Shadowsocks, GFW может быть уверен в классификации сервера как сервера Shadowsocks.

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

5.1. Эксперимент с симулятором зондов

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

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

Случайные зонды. Для имитации случайных зондов симулятор просто отправляет определенное количество случайных байтов. Обоснование здесь заключается в том, что реакция серверов на случайные зонды GFW ничем не отличается от их реакции на случайные зонды. Для полноты картины мы позволили симулятору отправлять случайные зонды длиной от 1 до 99 байт, а также зонды длиной 221 байт.

Выбор серверов. Мы выбрали набор реализаций Shadowsocks, который имеет значительный охват экосистемы обхода цензуры Shadowsocks. В частности, мы протестировали реализации Shadowsocks, которые соответствуют любому из следующих условий: 1) доступны в репозитории основного дистрибутива Linux; 2) доступны в репозитории pip; 3) являются последней версией; 4) широко используются любым популярным скриптом установки в один клик; 5) имеют недавнее исправление любых различимых реакций в результате предварительного отчета об этих атаках; или 6) были рекомендованы нам разработчиками. В результате этого процесса выбора мы остановились на Shadowsocks-libev (версии 3.0.8, 3.1.3, 3.2.5, 3.3.1 и 3.3.3) и OutlineVPN (версии 1.0.6, 1.0.7 и 1.0.8).

5.2. Намерение, стоящее за случайными зондами

5.2.1. Реакция серверов на случайные зонды.

На рисунке 10 обобщена реакция различных реализаций Shadowsocks на случайные зонды разной длины. Для каждой реализации мы сначала группируем доступные методы шифрования по потоковым шифрам и шифрам AEAD, а затем по размеру их вектора инициализации (IV) или соли. Например, среди потоковых шифров, поддерживаемых Shadowsocks-libev, – «aes-128-ctr» и «aes-256-cfb». Оба они имеют 16-байтовый IV, поэтому мы сгруппировали их в строке «16 байт». Значение IV и соли в контексте протоколов Shadowsocks см. в разделе 2.

Реакция сервера на рисунке 10 представлена кодами «TIMEOUT», «RST» и «FIN/ACK». TIMEOUT означает, что сервер ожидает дополнительных данных, пока он сам или зонд не достигнут тайм-аута. GFW обычно истекает менее чем за 10 секунд, в то время как значение тайм-аута по умолчанию для многих реализаций Shadowsocks составляет 60 секунд. Следовательно, TIMEOUT обычно означает, что зонд, а не сервер, первым отправляет FIN/ACK, чтобы закрыть соединение. FIN/ACK и RST означают, что сервер отправляет FIN/ACK или RST немедленно. Выбор FIN/ACK или RST может зависеть от обработки сокетов на уровне ОС. Фролов и др. показали, что при закрытии сокета в Linux FIN/ACK будет отправлен, если приложение прочитало все данные из своего буфера сокетов ядра; в противном случае будет отправлен RST.

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

Рисунок 10: Реакция серверов Shadowsocks на синтетические случайные зонды разной длины. Рисунок 10a предназначен для серверов, использующих потоковые шифры, а рисунок 10b – для шифров AEAD. Длина полезной нагрузки, которую, как наблюдалось, отправляет GFW, выделена красным цветом. «TIMEOUT» означает, что сервер ждет, пока не истечет время ожидания зонда или его собственное. «RST» означает, что сервер немедленно отправляет TCP RST. «FIN/ACK» означает, что сервер первым отправит FIN/ACK, чтобы закрыть соединение.

Shadowsocks-libev версий 3.0.8–3.2.5 с потоковыми шифрами. Возьмем в качестве примера первую строку на рисунке 10a. Серверы Shadowsocks-libev версий 3.0.8–3.2.5 с 8-байтовым IV демонстрируют три реакции в зависимости от длины случайного зонда. Когда длина зонда составляет от 1 до 8 байт, на сервере всегда истекает время ожидания. Это связано с тем, что сервер получил только (частичный) IV и ожидает указания цели.

Когда длина зонда составляет от 9 до 14 байт, сервер обычно отправляет немедленный RST, потому что не получил полное указание цели. Кратчайший случайный зонд, который может быть декодирован в значимую спецификацию, составляет 15 байт, что соответствует минимальному требованию к длине полной спецификации IPv4 (см. раздел 2). Спецификация имени хоста может быть немного короче 15 байт, но только если 1-байтовое поле длины имени хоста будет декодировано в значение 1 или 2.

Когда длина зонда составляет 15 или более байт, сервер может иметь любую из трех возможных реакций: RST, TIMEOUT или FIN/ACK. Реакция зависит от того, декодируется ли случайная полезная нагрузка в значимую спецификацию цели. Первое требование к значимой спецификации цели заключается в том, что тип адреса должен быть одним из значений 0x01, 0x03 или 0x04; любое другое значение приводит к немедленному сбросу RST. Поскольку тип адреса представляет собой 1-байтовое поле, мы могли бы ожидать немедленного сброса RST в 1 − 3/256 тестов. Что мы видим на самом деле, так это дробь, более близкую к 1 − 3/16. Причина этого в том, что Shadowsocks-libev маскирует старшие 4 бита поля (артефакт схемы «одноразовой аутентификации», упомянутой в разделе 2.1). Вероятность реакции RST уменьшается с увеличением длины зондов, поскольку более длинные зонды с большей вероятностью содержат полную спецификацию адреса IPv6 или длину имени хоста, соответствующую длине пакета.

Получив полное указание цели, сервер Shadowsocks пытается подключиться к заданной цели. В частности, когда поле типа адреса декодируется в 0x04, сервер пытается разрешить имя хоста; когда тип адреса равен 0x01 или 0x03, сервер отправляет пакет SYN на IP-адрес и порт получателя. Поскольку это поведение представляет собой подключение к по сути случайному IP-адресу или имени хоста, подключения почти всегда терпят неудачу; и когда это происходит, сервер отправляет клиенту FIN/ACK, чтобы закрыть соединение. Если удаленное соединение не разрывается немедленно (например, если удаленный хост не отвечает, а сервер Shadowsocks тратит время на повторную передачу пакетов SYN), зонды GFW первыми закроют соединение с помощью FIN/ACK.

Shadowsocks-libev версий 3.0.8–3.2.5 с шифрами AEAD. С шифрами AEAD серверы имеют другой набор реакций, по которым можно снять отпечатки пальцев. Первая строка на рисунке 10b представляет собой шифр AEAD с 16-байтовой солью. Когда длина зонда меньше или равна 50 байтам, на сервере истекает время ожидания дополнительных данных. Он хочет, чтобы данных было достаточно как минимум для соли (16 байт), зашифрованного префикса длины (2 байта), зашифрованного тега длины (16 байт) и еще одного тега (16 байт) для первой зашифрованной полезной нагрузки данных. Как только получено 51 байт или более, сервер пытается расшифровать полученные данные, что неизменно заканчивается ошибкой аутентификации. (В отличие от потоковых шифров, где случайные данные могут случайно расшифроваться во что-то значимое, с шифрами AEAD вероятность этого ничтожно мала.) Сервер отправляет немедленный RST из-за ошибки аутентификации.

Изменения в Shadowsocks-libev версий 3.3.1–3.3.3. Логика синтаксического анализа для Shadowsocks-libev версий 3.3.1–3.3.3 очень похожа на ту, которую мы только что описали выше для Shadowsocks-libev версий 3.0.8–3.2.5. Единственное отличие, как показано на рисунке 10b, заключается в том, что сервер всегда ждет, а не иногда отправляет немедленный RST.

OutlineVPN версии 1.0.6. OutlineVPN использует исключительно конструкцию шифра AEAD Shadowsocks и только с методом «chacha20-ietf-poly1305», который имеет 32-байтовую соль. В OutlineVPN версии 1.0.6, когда длина зонда меньше 50 байт, на сервере истекает время ожидания. Серверу требуется 50 байт для анализа следующей структуры:

[соль, 32 байта][зашифрованная длина, 2 байта][тег длины, 16 байт]

В отличие от Shadowsocks-libev, сервер OutlineVPN не ждет дополнительно, пока данных будет достаточно для второго тега. Что еще более уникально, сервер OutlineVPN немедленно отправляет FIN/ACK, когда получает зонд ровно из 50 байт. Когда длина зонда превышает 50 байт, сервер отправляет немедленный RST из-за сбоя аутентификации.

OutlineVPN версий 1.0.7–1.0.8. Начиная с OutlineVPN версии 1.0.7, разработчики исправили различимые реакции сервера. Как и в более новых версиях Shadowsocks-libev, использующих шифры AEAD, сервер всегда ждет, независимо от длины зонда.

5.2.2. Как злоумышленник может использовать информацию, полученную от случайных зондов.

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

Злоумышленник может с высокой степенью достоверности идентифицировать сервер Shadowsocks, используя статистический анализ его реакций на случайные зонды. В частности, злоумышленник может отправить на сервер набор зондов разной длины и записать его реакции. Собрав достаточное количество реакций, злоумышленник может выполнить статистический анализ. Сервер, реакции которого укладываются в одну строку на рисунке 10, с очень большой вероятностью является сервером Shadowsocks. Тот факт, что GFW требуется всего один зонд для обнаружения и блокировки сервера Tor, но набор из нескольких зондов перед блокировкой сервера Shadowsocks, говорит о том, что GFW проводит некоторый статистический анализ такого рода для обнаружения Shadowsocks.

Злоумышленник может даже определить длину IV в старых реализациях Shadowsocks. Более того, когда IV оказывается равным 12 байтам, злоумышленник знает, что используется шифр «chacha20-ietf», поскольку это единственный поддерживаемый шифр с 12-байтовым IV.

По аналогии злоумышленник может определить, какая реализация Shadowsocks используется, и ее приблизительную версию. Например, приведет ли ошибка аутентификации к RST или TIMEOUT, можно использовать, чтобы определить, запущена ли на сервере старая или новая реализация. Будет ли вероятность RST около 1 − 3/256 или 1 − 3/16, определяет, применяет ли реализация Shadowsocks маску к полю типа адреса.

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

Длина зондов, отправляемых GFW, отмеченная красным цветом на рисунке 10, совпадает с пороговыми значениями, при которых меняются реакции в некоторых реализациях Shadowsocks. Например, сервер, использующий шифры с 8-байтовым IV, будет ждать 8-байтовые зонды и немедленно отправлять RST 9-байтовые зонды. GFW покрывает эту точку перехода, отправляя зонды длиной 7, 8 и 9 байт. Однако стоит отметить, что зонды типа NR1 длиной 32–34 байта и 40–41 байт, а также зонды типа NR2 длиной 221 байт не совпадают ни с какими серверными порогами. Однако они все же могут быть полезны для идентификации серверов Shadowsocks. В зависимости от реализации эти зонды могут использоваться для расчета эмпирической вероятности отправки сервером RST. Если вероятность близка к 1 − 3/256 или 1 − 3/16, злоумышленник может сделать вывод, что сервер Shadowsocks использует потоковые шифры.

5.3. Намерение, стоящее за зондами, основанными на повторении

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

Реализации без механизма защиты от повторов. Реакция сервера на идентичные повторы типа R1 зависит от того, есть ли у него механизм защиты от повторов. Серверы без механизма защиты от повторов, такие как OutlineVPN версий 1.0.6–1.0.8, отвечают на идентичный повтор потоком данных в одном или нескольких пакетах. Как только зонд получает данные, он подтверждает их получение и отправляет FIN/ACK, чтобы закрыть соединение.

Злоумышленник может даже угадать, какой протокол проксируется, проверив, всегда ли длина ответов сервера одинакова для данной воспроизведенной полезной нагрузки. Хотя ответы серверов Shadowsocks зашифрованы, постоянная длина ответа может указывать на то, что базовое сообщение является ответом HTTP или TLS ServerHello, например.

Таблица 5: Реакция серверов на идентичные повторы (тип R1) и повторы с измененными байтами (типы R2–R5) различается в зависимости от обнаружения повторов и потоковых/AEAD-шифров. R: Сброс, T: Тайм-аут, F: FIN/ACK, D: Отправка данных. Здесь мы предполагаем, что все повторы достаточно длинные, чтобы содержать полный IV и спецификацию цели.

Ключевое наблюдение заключается в том, что смещения байтов, которые изменяются в зондах типов R2, R3 и R5, содержат IV или соль. Это означает, что реакция сервера Shadowsocks на эти зонды ничем не отличается от случайных зондов, рассмотренных в разделе 5.2. Зонды типа R4 могут быть атакой с выбранным зашифрованным текстом, нацеленной на серверы Shadowsocks, использующие потоковые шифры с 16-байтовым IV. По сравнению с зондами типов R2, R3 и R5, которые также по сути являются атаками с выбранным зашифрованным текстом, тип R4 является более точным, поскольку цензор может получить точную вероятность каждой реакции, перебрав все 255 измененных значений байтов.

Реализации с механизмом защиты от повторов. Даже с механизмом защиты от повторов поведение реализации Shadowsocks может быть различимым. Например, Shadowsocks-libev реализует свою защиту от повторов с помощью фильтра Блума, который запоминает, какие IV и соли уже были получены.

Как показано в таблице 5, при использовании шифров AEAD реакции серверов на идентичные повторы и повторы с измененными байтами согласованы. Однако при использовании потоковых шифров реакции серверов на идентичные повторы и повторы с измененными байтами не согласованы. Для идентичных повторов Shadowsocks-libev версий 3.0.8–3.2.5 гарантированно немедленно отправит RST; в то время как тот же сервер, получающий повторы с измененными байтами, будет иметь одну из трех различных реакций: сброс, тайм-аут или FIN/ACK.

Более того, с помощью потоковых шифров злоумышленник может обнаружить наличие фильтра повторов. Например, злоумышленник может дважды отправить на сервер один и тот же случайный зонд. Если первый зонд случайно вызовет исходящее подключение к какому-либо удаленному серверу, а второй зонд будет заблокирован фильтром повторов, разница во времени ответов покажет злоумышленнику, что фильтр повторов установлен. Хотя мы не можем подтвердить, что это та самая логика, которую использует GFW, мы действительно наблюдали, что около 10% зондов типа NR2 отправлялись на один и тот же сервер более одного раза.

7. Обход блокировок

Обнаружение Shadowsocks происходит в два этапа: 1) пассивная идентификация подозрительных соединений Shadowsocks, затем 2) активное зондирование сервера. Следовательно, чтобы избежать блокировки, можно 1) обойти пассивный детектор или 2) отвечать на активные зонды таким образом, чтобы это не приводило к блокировке. Ниже мы представляем и обсуждаем эти две стратегии обхода блокировок. Мы поделились нашими выводами и предложили защиту разработчикам Shadowsocks-libev и OutlineVPN, что привело к улучшению этих инструментов (см. Раздел 11).

7.1. Защита от анализа трафика

Изменение длины полезной нагрузки в потоке клиент-сервер эффективно.

В разделе 4.2 мы показали, что GFW учитывает длину первого пакета данных в соединении для идентификации трафика Shadowsocks. Это открытие предполагает, что мы можем уменьшить атаку GFW с анализом трафика, изменив длину пакетов.

Brdgrd (bridge guard) - это программное обеспечение, которое может работать на сервере Shadowsocks, что заставляет клиент разбивать свой Shadowsocks-handshake на несколько пакетов меньшего размера. Brdgrd изначально предназначался для нарушения обнаружения мостов Tor, вынуждая GFW выполнять сложную сборку TCP, но здесь мы используем его способность изменять размер пакетов клиента.

Рисунок 11. Интенсивность активного зондирования уменьшается, когда brdgrd активен.

В качестве теста мы настроили сервер Shadowsocks и позволили клиенту Shadowsocks устанавливать 16 подключений к нему каждые 5 минут. Мы включали и отключали brdgrd в случайное время и измеряли скорость активного зондирования в обоих условиях. В таблице 1 обобщена продолжительность эксперимента.

На рисунке 11 показано количество зондов, полученных сервером Shadowsocks с течением времени. Это показывает, что зондирование падает до нуля в течение нескольких часов после активации brdgrd. Как только мы снова отключили brdgrd, активное зондирование возобновилось. Во второй раз, когда мы включили brdgrd, зондирование полностью прекратилось примерно на 40 часов, но позже поступило еще несколько зондов. Обратите внимание, что получение нескольких активных зондов не обязательно означает, что изменение размера пакетов неэффективно, потому что сервер все еще получал небольшое количество зондов даже через 50 часов после того, как мы деактивировали клиент. Снижение интенсивности зондирования, пока brdgrd был активен, - это не просто совпадение, потому что на контрольном сервере, на котором не был установлен brdgrd, существенных изменений в количестве активных зондов не наблюдалось.

Мы также настроили сервер, на котором brdgrd был включен с самого начала, до того, как к нему подключился какой-либо клиент Shadowsocks. Хотя к обоим серверам было выполнено одинаковое количество подключений, этот сервер получил даже меньше зондов, чем сервер, который не включал brdgrd до запуска.

Эти наблюдения дополнительно подтверждают, что модуль анализа трафика GFW учитывает размер сегмента TCP трафика от клиента к серверу при обнаружении трафика Shadowsocks. Изменение размера пакетов может значительно уменьшить активное зондирование, нарушив первый шаг классификации.

Ограничения Brdgrd. Хотя brdgrd может эффективно уменьшать активное зондирование в настоящее время, его нельзя рассматривать как постоянное решение для блокировки Shadowsocks по следующим причинам.

Во-первых, чтобы сделать brdgrd менее узнаваемым, размер окна TCP выбирается случайным образом из диапазона. Однако объявление о несогласованном размере окна TCP само по себе может быть узнаваемым признаком. Эту проблему можно смягчить, придерживаясь фиксированного размера окна TCP в течение определенного времени.

Во-вторых, brdgrd придется объявить размер окна TCP, который необычно мал, в отличие от любого реального TCP-реализации.

В-третьих, brdgrd может привести к разрыву соединения для некоторых реализаций Shadowsocks. Как показано на рисунке 10, некоторые реализации Shadowsocks немедленно сбрасывают соединение RST, когда первый пакет с данными недостаточно длинный, чтобы содержать полную спецификацию целевого объекта. Brdgrd нередко разбивает пакеты на такие мелкие части, что запускает немедленный RST.

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

7.2. Защита от активного зондирования

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

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

Фильтрация повторов на основе одноразовых номеров и времени. Мы показали в разделе 3.5, что реалистичная модель злоумышленника для активного зондирования должна позволять цензору выполнять атаки с повторением после произвольно долгой задержки. Такая модель выявляет асимметрию между атакой и защитой для механизма защиты от повторов, основанного исключительно на одноразовых номерах. Хотя для GFW не требуется больших ресурсов для записи нескольких легитимных полезных нагрузок и их воспроизведения после довольно долгой задержки, серверам Shadowsocks дорого и сложно запоминать одноразовые номера всех аутентифицированных подключений навсегда или до тех пор, пока не будет изменен главный пароль. Сервер Shadowsocks должен запоминать эти одноразовые номера даже после перезапуска; в противном случае фильтр повторов будет неэффективен против повторов, которые охватывают перезапуск. К счастью, эту несправедливую игру можно обратить вспять, добавив механизм защиты на основе времени: сервер отвечает только на аутентифицированные подключения, которые не являются повторами и метка времени которых находится в пределах времени истечения срока действия, аналогично тому, как это делают серверы VMess. Таким образом, серверу не нужно запоминать одноразовые номера навсегда, а только на ограниченное время.

Последовательность в реакциях серверов. Как обсуждалось в разделе 5, протоколы обхода должны реагировать согласованно не только при нормальной работе, но и при возникновении ошибки. Цензоры могут намеренно запускать крайние случаи протокола, пытаясь идентифицировать серверы. Используя несоответствия, аналогичные тем, что мы обнаружили в Shadowsocks-libev и OutlineVPN, Фролов и др. продемонстрировали, что различные прокси-серверы, включая Shadowsocks-python и OutlineVPN, можно идентифицировать по TCP-флагам и метаданным времени после того, как серверы закроют соединение. Они предполагают, что прокси-серверы должны считывать данные вечно при возникновении ошибок, а не разрывать соединение. Это не только позволяет избежать раскрытия определенного значения тайм-аута, но также позволяет серверу закрывать соединение с согласованными TCP-флагами в случае отсутствия ошибок.

8. Связанные работы

Проведены многочисленные исследования анализа трафика Shadowsocks. В некоторых работах предполагается более сильный противник, чем тот, которого мы наблюдали на практике. Например, Цзэн и др. предполагают, что злоумышленник учитывает поведение DNS хостов при построении своей модели обнаружения. Разработано множество экспериментальных инструментов для обнаружения трафика Shadowsocks. Чжисинь Ван предложил атаку, основанную на высокой энтропии первых нескольких пакетов. Madeye использовал распределение длины пакетов для идентификации трафика Shadowsocks и ShadowsocksR. Кроме того, Ван и др. продемонстрировали, что анализ трафика на основе энтропии может точно идентифицировать протоколы обхода цензуры, такие как obfs3, obfs4 и FTE.

Многие исследования и отчеты эмпирически показывают, что GFW применяет методы активного зондирования для обнаружения инструментов обхода цензуры. Известные целевые протоколы включают Tor, obfs2, VPN Gate и другие VPN-сервисы. Винтер и др. изучили, как GFW обнаруживал ретрансляторы Tor с помощью активного зондирования еще в 2012 году. Данна и др. пересмотрели активное зондирование против Tor в 2018 году. Энсафи и др. сняли отпечатки зондов GFW, нацеленных на разные протоколы, и сделали вывод о базовой инфраструктуре зондирующих машин. Разработчики V2Ray сообщили, что серверы V2Ray подвергались атакам с повторением еще в 2017 году. Насколько нам известно, самое раннее упоминание об использовании активного зондирования против Shadowsocks было в июне 2019 года.

Было предложено множество теоретических атак и защит с активным зондированием. В частности, Фролов и др. идентифицировали различные прокси-серверы, используя TCP-флаги и информацию о времени закрытия соединения сервером. Фролов и Вюстроу демонстрируют многообещающее направление борьбы с активным зондированием, а именно, скрытие прокси-серверов за популярными приложениями. Эта концепция, известная как маскировка под приложение, была принята во многих популярных инструментах обхода цензуры.

9. Будущие работы

В этой работе мы сосредоточились на активном зондировании GFW, направленном specifically против Shadowsocks. Однако ряд свидетельств из наших наблюдений позволяет предположить, что GFW нацеливает активное зондирование на другие, неизвестные протоколы обхода цензуры. Во-первых, как указано в разделе 4.1, нам удалось запустить активное зондирование, используя случайные данные. Поскольку другие протоколы обхода цензуры, например, VMess, также полностью шифруют свой трафик, они, вероятно, тоже будут обнаружены. Во-вторых, как указано в разделе 4.2, мы обнаружили новые типы зондов, которые не получали наши серверы Shadowsocks и OutlineVPN. Если эти зонды не направлены на Shadowsocks, то на что они направлены? В-третьих, в июне 2020 года было обнаружено, что VMess уязвим для активного зондирования. Мы хотим проверить, использовался ли этот уязвимость GFW на практике.

10. Этика

Исследования измерения цензуры несут в себе элемент риска, который может варьироваться от регистрации конфиденциального запроса до юридических последствий. Мы приняли меры для минимизации риска при проведении наших измерительных экспериментов. Во-первых, эта работа не связана с участием людей. Весь сетевой трафик генерировался автоматически программами, находящимися под нашим контролем. Во-вторых, хотя риск того, что конфиденциальные запросы будут обнаружены цензором, может быть невелик, мы постарались ограничить количество таких конфиденциальных запросов. В частности, только в одном из наших экспериментов мы использовали хост в Китае в качестве сервера Shadowsocks. В этом эксперименте мы изначально настроили сервер на проксирование трафика просмотра подмножества веб-сайтов из списка Alexa Top 1 миллион. После 45 часов работы эксперимента мы решили удалить из списка просматриваемых веб-сайтов сайты, подвергнутые цензуре, чтобы хост в Китае не устанавливал соединения с конфиденциальными веб-сайтами за пределами брандмауэра. В-третьих, мы минимизировали потенциальный побочный ущерб от блокировки, используя выделенные IP-адреса для наших серверов обхода цензуры. Мы арендовали наши сетевые хосты, не связанные с цензурой, у VPS-провайдера, который разрешает Shadowsocks и OutlineVPN и фактически даже предлагает автоматическую установку OutlineVPN.

11. Заключение

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

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