Как GFW обнаруживает и блокирует full encrypted трафик

1. Введение

1.1. Полностью зашифрованные протоколы обхода цензуры

Полностью зашифрованные протоколы обхода цензуры являются краеугольным камнем решений по обходу цензуры. В то время как протоколы, такие как TLS, начинаются с рукопожатия, которое включает в себя байты открытого текста, полностью зашифрованные (рандомизированные) протоколы, такие как VMess, Shadowsocks и Obfs4, разработаны таким образом, что каждый байт в соединении функционально неотличим от случайного. Идея за этими «выглядит как ничто» протоколами состоит в том, что их должно быть сложно идентифицировать цензорами, и, следовательно, дорого их блокировать.

1.2. Новый механизм цензуры в Китае

6 ноября 2021 года пользователи Интернета в Китае сообщили о блокировках своих серверов Shadowsocks и VMess. 8 ноября разработчик Outline сообщил о внезапном снижении использования со стороны Китая. Начало этой блокировки совпало с шестой пленарной сессией 19-го Центрального комитета Коммунистической партии Китая, которая проводилась с 8 по 11 ноября 2021 года. Блокировка этих инструментов обхода цензуры представляет собой новую возможность в Великом китайском файерволе (GFW). Насколько нам известно, хотя Китай с мая 2019 года активно зондировал такие протоколы, это первый случай, когда цензор смог блокировать полностью зашифрованные прокси массово в режиме реального времени, полностью основываясь на пассивном анализе трафика. Важность полностью зашифрованных протоколов для всей экосистемы противодействия цензуре и загадочное поведение GFW побуждают нас исследовать и понять лежащие в основе механизмы обнаружения и блокировки.

1.3. Цель и вклад

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

Из-за черного ящика GFW наши выведенные правила могут быть неполными; однако мы оцениваем наши выведенные правила на реальном трафике с сетевого отвода в CU Boulder и предоставляем доказательства того, что наши правила имеют значительное пересечение с правилами GFW. Мы также обнаруживаем, что выведенный алгоритм обнаружения заблокировал бы примерно 0,6% всех соединений на нашем сетевом отводе. Возможно, чтобы снизить чрезмерную блокировку, вызванную ложными срабатываниями, наши сканирования Интернета показывают, что GFW стратегически отслеживает только 26% соединений и только к определенным диапазонам IP-адресов популярных дата-центров.

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

Из нашего понимания этого нового механизма цензуры мы выводим различные стратегии обхода цензуры. Мы ответственно и своевременно поделились нашими выводами и предложениями по обходу с разработчиками различных популярных инструментов противодействия цензуре, включая Shadowsocks, V2Ray, Outline, Lantern, Psiphon и Conjure. Эти стратегии обхода цензуры были широко приняты и развернуты с января 2022 года, помогая миллионам пользователей обойти эту новую форму блокировки. По состоянию на февраль 2023 года все стратегии обхода цензуры, принятые этими инструментами, как сообщается, по-прежнему эффективны в Китае.

2. Предыстория

2.1. Стратегии сокрытия трафика

Тшанц и др. делят подходы к сокрытию трафика обхода цензуры на два типа: стеганографические и полиморфные. Цель стеганографических прокси - заставить трафик обхода цензуры выглядеть как разрешенный трафик; цель полиморфизма - заставить трафик обхода цензуры не выглядеть как запрещенный трафик.

Два наиболее распространенных подхода к достижению стеганографии - это имитация и туннелирование. Хоумсадар и др. делают вывод, что имитация протокола в корне ошибочна и предлагают туннелирование через разрешенные протоколы в качестве более устойчивого к цензуре подхода. Фролов и Устроу демонстрируют, что даже при использовании туннелирования все равно требуется приложить усилия, чтобы идеально согласовать отпечатки пальцев протоколов с популярными реализациями, чтобы избежать блокировки по отпечаткам пальцев протоколов. Например, в 2012 году Китай и Эфиопия развернули глубокую проверку пакетов, чтобы обнаружить трафик Tor по его необычным наборам шифрования. Продавцы оборудования для цензурных межсетевых экранов ранее идентифицировали и блокировали трафик meek на основе его отпечатка TLS и значения SNI.

Чтобы избежать этой сложности, многие популярные прокси-серверы выбирают полиморфные конструкции. Распространенный способ достижения полиморфизма - полное шифрование полезной нагрузки трафика, начиная с первого пакета в соединении. Без каких-либо отпечатков пальцев открытого текста или фиксированной структуры заголовка цензор не может легко идентифицировать трафик прокси-сервера с помощью регулярных выражений или путем поиска определенных шаблонов в трафике. Этот дизайн был впервые представлен в Obfuscated OpenSSH в 2009 году. С тех пор он используется Obfsproxy, Shadowsocks, Outline, VMess, ScrambleSuit, Obfs4 и частично используется в Geph4, Lantern, Psiphon3 и Conjure.

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

В 2015 году Ван и др. использовали длину и высокую энтропию Шеннона полезной нагрузки первого пакета в соединении для идентификации рандомизированного трафика, такого как Obfs4. Аналогичным образом, в 2017 году Чжисин Ван выпустил демонстрационную программу, которая использовала высокую энтропию Шеннона полезной нагрузки первых трех пакетов в соединении для идентификации трафика Shadowsocks. Madeye расширил программу, добавив использование распределения длины полезной нагрузки для обнаружения трафика ShadowsocksR. Хе и др. и Лян и др. использовали алгоритм обнаружения частоты единичного бита, а не энтропию Шеннона, для измерения случайности трафика Obfs4. В 2019 году Алис и др. обнаружили, что GFW использует длину и энтропию первого пакета данных в каждом соединении, чтобы заподозрить трафик Shadowsocks.

2.2. Атаки активного зондирования и защита от них

В атаках активного зондирования цензор отправляет специально сформированные полезные данные на предполагаемый сервер и измеряет его ответ. Если сервер отвечает на эти зонды идентифицируемым образом (например, позволяет цензору использовать его в качестве прокси), цензор может заблокировать его. Еще в августе 2011 года было замечено, что GFW отправляет, казалось бы, случайные полезные данные на внешние SSH-серверы, которые принимали вход в SSH из Китая. В 2012 году GFW впервые искал уникальный набор шифрования TLS для идентификации трафика Tor; затем он отправлял активные зонды на предполагаемые серверы, чтобы подтвердить свое предположение. В 2015 году Энесифи и др. провели подробный анализ атак активного зондирования GFW против различных протоколов. С мая 2019 года Китай развернул систему цензуры для обнаружения и блокировки серверов Shadowsocks в два этапа: сначала он использует длину и энтропию полезной нагрузки первого пакета в каждом соединении для пассивной идентификации возможного трафика Shadowsocks, а затем отправляет различные зонды на разных этапах, чтобы подтвердить свое предположение. В ответ исследователи предложили различные механизмы защиты от атак активного зондирования, включая согласованные реакции сервера и фронтирование приложений. Shadowsocks, Outline и V2Ray включили в себя устойчивые к зондированию конструкции, что сделало их разблокированными в Китае с сентября 2020 года, до недавней блокировки в ноябре 2021 года.

3. Методология

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

3.1. Хронология экспериментов и точки наблюдения

Мы суммировали временную шкалу и использование точек наблюдения всех основных экспериментов в таблице 1. В общей сложности мы использовали десять VPS в TencentCloud Пекин (AS45090) и один VPS в AlibabaCloud Пекин (AS37963). Мы не наблюдали никаких различий в поведении цензуры между нашими точками наблюдения в Китае или любыми затронутыми внешними точками наблюдения. Мы использовали четыре VPS в DigitalOcean Сан-Франциско (AS14061): три из них были затронуты новой цензурой, а один - нет. Мы превратили эти четыре VPS в серверы-приемники; то есть серверы прослушивают все порты с 1 по 65535 для приема TCP-соединений, но не отправляют никаких данных обратно клиенту. Мы также использовали две машины в CU Boulder (AS104) для сканирования Интернета и анализа реального трафика. Мы проверили IP-адреса наших VPS в базе данных IP2Location, подтвердив, что их географические местоположения соответствуют заявленным их поставщиками.

3.2. Вызов цензуры

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

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

Аналогично тому, как GFW блокирует многие другие протоколы, после того, как соединение запускает цензуру, GFW блокирует все последующие соединения, имеющие тот же 3-кортеж (IP-адрес клиента, IP-адрес сервера, порт сервера) в течение 180 секунд. Эта остаточная цензура позволяет нам подтвердить блокировку, отправляя последующие соединения с того же клиента на тот же порт сервера. Мы устанавливаем пять TCP-соединений одно за другим с интервалом в одну секунду между ними. Если все пять соединений завершаются сбоем, мы делаем вывод, что 3-кортеж заблокирован. Как только 3-кортеж заблокирован, мы не используем его для дальнейших тестов в течение следующих 180 секунд.

3.4. Учет вероятностной блокировки с помощью повторяющихся тестов

Нам часто приходилось устанавливать несколько соединений с одной и той же полезной нагрузкой, прежде чем мы наблюдали блокировку. В разделе 6.3 мы объясняем, что это связано с тем, что GFW использует стратегию вероятностной блокировки, когда цензура запускается только примерно в четверти случаев. Чтобы учесть это вероятностное поведение, мы отправляем одну и ту же полезную нагрузку вплоть до 25 соединений, прежде чем сделать вывод о блокировке (или неблокировке). Если мы можем успешно установить 25 соединений с одной и той же полезной нагрузкой подряд, то мы делаем вывод, что полезная нагрузка (или сервер) не затронута этой цензурой. Если после отправки полезной нагрузки хотя бы один раз последовательность из 5 последующих попыток соединения завершается с тайм-аутом (из-за остаточной цензуры), мы помечаем полезную нагрузку (и сервер) как затронутую цензурой. Мы используем этот метод повторяющихся соединений для измерения заблокированных полезных нагрузок во всех тестах на протяжении всего нашего исследования.

4. Характеристика новой системы цензуры

Мы проводим эксперименты, чтобы понять, как GFW обнаруживает и блокирует полностью зашифрованные соединения. Подробно описанные в таблице 1, с 6 ноября 2021 года по 18 мая 2022 года мы использовали три VPS в Китае и три сервера-приемника в США, чтобы провести наши эксперименты. В течение того же периода мы также использовали один VPS в AlibabaCloud Пекин (AS37963), чтобы повторить все наши эксперименты. Мы не наблюдали никаких различий в поведении цензуры между нашими точками наблюдения в Китае или любой затронутой внешней точкой наблюдения. 16 февраля 2023 года мы повторили наши эксперименты и подтвердили, что все правила обнаружения по-прежнему действуют. На этот раз мы использовали один VPS в TencentCloud Пекин и один сервер-приемник в DigitalOcean Сан-Франциско.

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

4.1. Исключение по энтропии (Ex1)

Мы наблюдали, что доля установленных бит влияет на то, блокируется ли соединение. Чтобы определить это, мы отправляли повторяющиеся соединения на наш сервер и наблюдали, какие из них были заблокированы. В каждом соединении мы отправляли один из 256 различных байтовых шаблонов, состоящий из 1 байта, повторяющегося 100 раз (например, \x00\x00\x00…, \x01\x01\x01…, …, \xff\xff\xff…). Мы отправляли каждый шаблон в 25 соединениях на наш сервер и наблюдали, вызывали ли какие-либо шаблоны блокировку последующих соединений, указывая на то, что полезная нагрузка вызывает блокировку. Мы обнаружили, что 40 байтовых шаблонов вызывали блокировку, в то время как оставшиеся 216 шаблонов не вызывали. Примеры шаблонов, которые были заблокированы, включают \x0f\x0f\x0f…, \x17\x17\x17… и \x1b\x1b\x1b… (и 37 других).

Все заблокированные шаблоны состоят из байтов, в которых ровно 4 (из 8) бита равны 1 (например, \x1b в двоичном виде - это 00011011). Мы предположили, что количество установленных бит (1 бит) на байт может играть роль, поскольку равномерно случайные данные будут иметь близкое к одинаковому количеству общих 1 и 0 в двоичном коде. По сути, это измерение энтропии бит в пакете клиента.

Мы подтвердили это, отправив комбинации байтов, которые были индивидуально разрешены, но вместе привели к блокировке. Например, \xfe\xfe\xfe… и \x01\x01\x01… не блокировались по отдельности, но эти байты, отправленные вместе как \xfe\x01\xfe\x01…, привели к блокировке. Мы отмечаем, что \xfe\x01 имеет 8 (из 16) бит, установленных в 1 (в среднем 4 бита на байт установлено), в то время как \xfe имеет 7 из 8, а \x01 имеет 1 из 8 установлено, что объясняет, почему по отдельности они разрешены, но вместе они блокируются.

Конечно, случайные или зашифрованные данные не всегда будут иметь ровно половину бит, установленных в 1. Мы проверили, насколько близко к половине GFW нужно, чтобы заблокировать, отправив последовательность из 50 случайных байтов (400 бит) с увеличивающимся количеством установленных бит. Мы создали 401 битовую строку с 0–400 бит, установленных в 1, и перетасовали каждую строку, получив набор случайных строк с 0–8 бит, установленных на байт (с шагом 0,02 бита/байт). Для каждой строки мы устанавливали 25 соединений и отправляли строку, чтобы наблюдать, вызывала ли она блокировку последующих соединений. Мы обнаружили, что все строки с ≤ 3,4 или ≥ 4,6 бит/байт, установленных в 1, не блокировались, в то время как строки с 3,4–4,6 бит/байт, установленных в 1, блокировались.

Было одно исключение из этого правила для строки с 4,26 бита/байт, установленных в 1, которое, как мы определили, не блокировалось из-за наличия более 50% байтов, являющихся печатными символами ASCII; далее мы показываем, что это правило исключения (Ex2). Мы повторили наш эксперимент и подтвердили, что другие строки с тем же количеством установленных бит, но с меньшим количеством печатных символов ASCII, действительно блокируются.

В итоге мы обнаруживаем, что GFW исключает соединение, если доля установленных бит в первом пакете данных клиента отклоняется от половины. Это соответствует грубому измерению энтропии: случайные (зашифрованные) данные будут иметь близкое к половине количество бит, установленных в 1, в то время как другие протоколы обычно имеют меньше 1 бит на байт из-за открытого текста или заполненных нулями заголовков протокола. Например, Google Chrome версии 105 отправляет приветствие TLS-клиента со средним значением только 1,56 бита, установленного на байт, выходящего за пределы диапазона цензуры, из-за заполнения нулями.

4.2. Исключение по символам ASCII (Ex2-4)

Мы наблюдали несколько исключений из правила подсчета бит, которое мы обнаружили в разделе 4.1. Например, шаблон \x4b\x4b\x4b… не был заблокирован, несмотря на то, что в нем было ровно 4 бита, установленных на байт. Действительно, существует 70 символов (8 выбрать 4), которые имеют ровно 4 бита, установленных в 1, но наш анализ показал, что только 40 из них вызывали цензуру. Как насчет остальных 30?

Эти остальные 30 значений байтов попадают в диапазон байтов, который включает печатные символы ASCII, 0x20–0x7e. Мы предполагаем, что GFW исключает символы, предположительно, чтобы разрешить «открытый текст» (читаемые человеком) протоколы.

Мы обнаружили три способа, которыми GFW исключает соединения, основанные на печатных символах ASCII в первом пакете полезной нагрузки от клиента: если первые шесть байтов являются печатными (Ex2); если более половины байтов являются печатными (Ex3); или если он содержит более 20 последовательных печатных байтов (Ex4).

Первые шесть байтов являются печатными (Ex2). Мы наблюдаем, что GFW исключает блокировку, если первые 6 байтов соединения попадают в диапазон печатных байтов 0x20–0x7e. Если в первых 6 байтах есть символы за пределами этого диапазона, то соединение может быть заблокировано, если у него нет других исключающих свойств (например, менее 3,4 бит на байт, установленных в 1). Мы проверили это, сгенерировав сообщения, где первые n байтов были взяты из разных наборов символов (например, печатные символы ASCII), а остальные байты сообщения были бы случайными непечатными символами. Мы обнаруживаем, что при n < 6 мы наблюдаем цензуру, но при n≥ 6, где первые n байтов - это печатные символы ASCII, блокировки не происходит.

Половина первого пакета являются печатными (Ex3). Если более половины всех байтов в первом пакете попадают в диапазон печатных символов ASCII 0x20–0x7e, GFW исключает соединение. Мы проверили это, отправив пакеты, состоящие из 10 байтов символов за пределами этого диапазона (например, 0xe8), с последующей повторяющейся последовательностью из 6 байтов: 5 в пределах диапазона (например, 0x4b) и один за пределами. Мы повторяем эту 6-байтовую последовательность 5 раз, а затем заполняем конец строки n байтами за пределами диапазона (в обозначении Python: ” \xe8”*10 + (” \x4b”*5 + “\xe8”)*5 + “\xe8”*n). Этот эксперимент дает нам шаблон переменной длины, который уменьшает долю байтов в диапазоне печатных символов ASCII по мере увеличения n. Мы обнаруживаем, что при n < 10 соединения не блокируются, в то время как при n≥ 10 они блокируются. Это соответствует блокировке, когда доля печатных символов меньше или равна половине, и неблокировке, когда она больше половины.

Мы проектируем наши зонды, чтобы избежать запуска других исключений GFW, таких как подсчет бит (Ex1), печатные префиксы (Ex2) или последовательности печатных символов (Ex4). Например, мы используем 0x4b и 0xe8 в качестве наших печатных и непечатных символов соответственно, поскольку оба они имеют ровно 4 бита, установленных в 1. Это предотвращает исключение GFW нашего соединения из блокировки из-за правила подсчета бит (Ex1), обсуждавшегося ранее. Кроме того, мы избегаем наличия последовательных последовательностей печатных символов 0x4b, поскольку мы наблюдали, что такие последовательности могут также исключать соединение из блокировки, что мы обсудим далее. Мы повторили наши эксперименты с другими шаблонами, которые также удовлетворяли этим ограничениям (например, 0x8d и 0x2e), и наблюдали те же результаты.

Более 20 последовательных байтов являются печатными (Ex4). Последовательная последовательность печатных символов может также исключать блокировку, даже если общая доля печатных символов меньше половины. Чтобы проверить это, мы отправили шаблон из 100 байтов символа за пределами печатного диапазона (0xe8) с различным количеством последовательных байтов из печатного диапазона (мы использовали 0x4b). Наша полезная нагрузка начиналась с 10 байтов 0xe8, за которыми следовали n байтов 0x4b, а затем 90−n байтов 0xe8, общая длина составляла 100 байтов. Мы варьировали n от 0 до 90 и отправляли каждый из 91 вариантов полезной нагрузки в 25 соединениях на наш сервер. Мы обнаружили, что при n ≤ 20 соединение блокировалось. При n > 20 соединение не блокировалось, что указывает на наличие последовательности печатных символов, исключающих блокировку. Конечно, при n > 50 соединение также будет исключено из-за Ex3.

Другие кодировки. Мы проверили, исключаются ли китайские символы в первом пакете из блокировки так же, как печатные символы ASCII. Мы использовали строки из 6–36 китайских символов, закодированных в UTF-8, а также в GBK (идентично GB2312 для символа, который мы использовали). Все эти тесты были заблокированы, что говорит о том, что для китайских символов нет исключения. Возможно, наличие китайских символов в этих кодировках встречается редко или разбор этих кодировок добавляет неоправданную сложность, поскольку трудно определить, где начинается или заканчивается закодированная строка.

4.3. Исключение распространенных протоколов (Ex5)

Чтобы избежать случайной блокировки популярных протоколов, мы наблюдаем, что GFW явно исключает два популярных протокола. GFW, по-видимому, выводит протоколы из первых 3–6 байтов пакета клиента: если они соответствуют байтам известного протокола, соединение исключается из блокировки, даже если остальные пакеты не соответствуют протоколу. Мы протестировали шесть распространенных протоколов и обнаружили, что протоколы TLS и HTTP явно исключены. Этот список может быть неполным, так как могут быть другие исключенные протоколы, которые мы не тестировали.

TLS. Соединения TLS начинаются с сообщения TLS Client Hello, и первые три байта этого сообщения заставляют GFW исключать соединение из блокировки. Мы наблюдаем, что GFW исключает любое соединение, первые три байта которого соответствуют следующему регулярному выражению:

[\x16-\x17]\x03[\x00-\x09]

Это соответствует типу записи в один байт, за которым следует двухбайтовая версия. Мы перечислили все 256 шаблонов ‘XX\x03\x03’, за которыми следуют 97 байтов случайных данных, и обнаружили, что все шаблоны блокируются, за исключением тех, которые начинаются с 0x16 (соответствующего типу записи TLS Handshake, используемому в Client Hello) или 0x17 (соответствующего типу записи Application Data). В то время как обычные соединения TLS не начинаются с Application Data, когда TLS используется поверх Multipath-TCP (MPTCP), часто бывает, что один из TCP-подпотоков используется для Client Hello, а другие подпотоки отправляют Application Data сразу после установления TCP-соединения. По состоянию на сегодняшний день определены только версии TLS 0x03[0x00-0x03], но GFW разрешает даже более поздние (еще не определенные) версии.

HTTP. Байтовый шаблон, используемый цензором для идентификации трафика HTTP, - это просто метод с пробелом. Если сообщение начинается с GET, PUT, POST или HEAD, соединение будет исключено из блокировки. Пробел (0x20) после каждого глагола необходим для исключения соединений из блокировки. Не включение этого пробела или его замена на любой другой байт не исключат соединение. Остальные методы HTTP (OPTIONS, DELETE, CONNECT, TRACE, PATCH) попадают под исключение по печатным символам ASCII (Ex2), так как первые 6 байтов являются печатными символами. Мы обнаруживаем, что метод нечувствителен к регистру: GeT, get и аналогичные варианты исключены. Опечатки в глаголе (например, TEG) не исключены.

Неисключенные протоколы. Мы протестировали другие распространенные протоколы: SSH, SMTP и FTP будут исключены, так как все они начинаются с по меньшей мере 6 байтов печатных символов ASCII (правило Ex2). DNS-over-TCP исключен из-за того, что он содержит большую долю нулей, что делает его исключенным по правилу Ex1. Однако, если после сообщения DNS-over-TCP будет добавлена достаточно большая часть случайных данных, оно будет заблокировано.

Это наблюдение поднимает вопрос, почему цензор имеет явные правила исключения TLS и HTTP, но не других протоколов. В конце концов, цензору не нужно явно исключать эти два протокола: HTTP обычно исключается печатными символами ASCII для первых 6 байтов (правило Ex2), а сообщения TLS Client Hello имеют относительно низкую битовую энтропию (правило Ex1) из-за многих нулевых полей. Тем не менее, цензор может использовать эти простые, но эффективные правила, чтобы быстро исключить большую часть трафика (TLS и HTTP) из более глубокого анализа, такого как подсчет бит, доля ASCII и т. д.

4.4. Как GFW нарушает соединения

Как только GFW обнаруживает полностью зашифрованный трафик с помощью Алгоритма 1, он блокирует последующий трафик, как описано ниже.

Пакеты отбрасываются с клиента на сервер. Мы вызвали блокировку GFW и сравнили захваченные пакеты как от отправляющего клиента, так и от получающего сервера. Мы наблюдаем, что после запуска блокировки пакеты клиента отбрасываются GFW и не доходят до сервера. Однако пакеты, отправленные сервером, не блокируются и все еще принимаются клиентом.

UDP-трафик не затронут. Новая система цензуры ограничена TCP. Отправка UDP-датаграммы со случайной полезной нагрузкой не может вызвать блокировку. Кроме того, как только 3-кортеж (IP-адрес клиента, IP-адрес сервера, порт сервера) блокируется из-за запускающего TCP-соединения, UDP-датаграммы на или с того же (IP-адрес сервера, порт сервера) не затрагиваются. Отсутствие блокировки UDP может отражать менталитет цензора «хуже - значит лучше». С практической точки зрения, текущая блокировка TCP уже может эффективно парализовать эти популярные инструменты обхода цензуры, в то время как использование цензуры UDP требует дополнительных ресурсов и добавляет дополнительную сложность в систему цензуры.

Трафик на всех портах может быть заблокирован. Мы настроили сервер-приемник, прослушивающий все порты с 1 по 65535 в США. Затем мы позволили нашему клиенту в Китае непрерывно устанавливать соединения с 50-байтовой случайной полезной нагрузкой на каждый порт сервера в США и останавливаться, когда порт блокировался. Мы обнаруживаем, что блокировка может произойти на всех портах с 1 по 65535. Следовательно, запуск серверов обхода цензуры на необычном порту не может смягчить блокировку. Мы также не наблюдаем никаких различий в поведении цензора между портами.

Продолжительность остаточной цензуры зависит от количества действующих блокировок. Мы обнаруживаем, что как только эта новая система цензуры блокирует соединение, она продолжает отбрасывать все последующие TCP-пакеты, имеющие тот же 3-кортеж (IP-адрес клиента, IP-адрес сервера, порт сервера) в течение 120 или 180 секунд. Это поведение часто называют «остаточной цензурой». В отличие от некоторых других систем остаточной цензуры, таймер остаточной цензуры GFW не сбрасывается при отправке дополнительных пакетов.

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

4.5. Как GFW собирает потоки

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

Необходимо полное TCP-рукопожатие. Мы наблюдаем, что отправка пакета SYN с последующим пакетом PSH+ACK, содержащим случайные данные (без завершения сервером своей части рукопожатия), недостаточно для запуска блокировки. Таким образом, блокировку сложнее использовать для атак остаточной цензуры.

Только пакеты от клиента к серверу могут вызвать блокировку. Мы обнаруживаем, что GFW не только проверяет, отправляются ли случайные данные на IP-адрес назначения, который попадает в затронутый диапазон IP-адресов, но также анализирует и блокирует только в том случае, если случайные данные отправляются с клиента на сервер. Сервер здесь определяется как хост, который отправляет SYN+ACK во время TCP-рукопожатия.

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

GFW анализирует только первые пакеты данных. GFW, по-видимому, анализирует только первый пакет данных в TCP-соединении, не собирая потоки с несколькими пакетами данных. Мы проверили это с помощью следующего эксперимента. После TCP-рукопожатия мы отправляем первый пакет данных с полезной нагрузкой только в один байт \x21. Дождавшись секунды, мы затем отправляем второй пакет данных с 200-байтовой случайной полезной нагрузкой. Мы повторили эксперимент 25 раз, но соединения никогда не блокировались. Это происходит потому, что после просмотра первого пакета данных GFW уже исключил соединения по правилу Ex1, поскольку он содержал 100% печатных символов ASCII в полезной нагрузке. Другими словами, если бы GFW собирал несколько пакетов в поток во время своего анализа трафика, он смог бы заблокировать эти соединения.

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

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

Наш клиент завершил TCP-рукопожатия, а затем ждал 100, 180 или 300 секунд, прежде чем отправлять 200 байтов случайных данных. Затем мы повторили эксперимент, но использовали правила iptables для отбрасывания любых пакетов RST или TCP keepalive, если они помогали GFW поддерживать активное состояние соединения. Мы обнаружили, что эти соединения все равно вызывали блокировку, что говорит о том, что GFW поддерживал состояние соединения в течение как минимум пяти минут.

5. Взаимосвязь с системой активного зондирования

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

5.1. Эксперимент с активным зондированием

До развертывания этой новой системы блокировки в реальном времени вывести алгоритм анализа трафика системы активного зондирования было крайне сложно, если вообще возможно. Это связано с тем, что GFW использует произвольную задержку между обнаружением запускающего соединения и отправкой активных зондов, что затрудняет учет того, какие зонды GFW вызываются какими соединениями, которые мы отправляем. Теперь, когда мы вывели список правил обнаружения трафика этой новой системы блокировки в разделе 4, мы можем проверить, будет ли полезная нагрузка, исключенная Алгоритмом 1, также не вызывать подозрения у системы активного зондирования.

Мы провели эксперименты в период с 19 мая 2022 года по 8 июня 2022 года. Как показано в таблице 2, мы создали 14 различных типов полезных нагрузок: три из них - это случайные данные с длинами 2, 50 и 200 байтов; оставшиеся 11 - это данные с различными длинами, которые будут исключены только одним из правил исключения в Алгоритме 1. Затем мы отправили те же 14 полезных нагрузок с VPS в Tencent Cloud Пекин, Китай, на 14 портов двух разных узлов в DigitalOcean Сан-Франциско, США. Один узел в США, как известно, затронут текущей системой блокировки, в то время как другой узел в США не затронут. Таким образом, если мы получили какие-либо зонды от GFW, мы знаем, что определенные правила исключения, используемые текущей системой блокировки, не используются системой активного зондирования.

В общей сложности наш клиент в Китае отправил около 170 000 соединений на каждый порт двух серверов в США. Затем мы предприняли шаги, чтобы изолировать зонды GFW от других сканеров Интернета. Мы проверяем исходный IP-адрес каждого зонда в базе данных IP2Location и AbuseIPDB. Мы не рассматриваем его как зонд от GFW, если он был некитайским IP или от известного спамерского IP-адреса. Мы дополнительно проверяем, принадлежит ли зонд к любому из известных типов зондов, отправляемых GFW.

Две системы работают независимо. Новая машина цензуры принимает решения о блокировке исключительно на основе пассивного анализа трафика, не полагаясь на хорошо известную инфраструктуру активного зондирования Китая. Мы знаем это, потому что, хотя GFW по-прежнему отправляет активные зонды на серверы, в более чем 99% тестов GFW не отправлял никаких активных зондов на сервер до блокировки соединения. Например, как показано в таблице 2, мы установили 33 119 соединений, но получили только 179 активных зондов. Действительно, аналогично выводам предыдущей работы, активные зонды запускаются редко.

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

Система активного зондирования применяет пять правил исключения с одним дополнительным правилом длины, чтобы заподозрить трафик. Этот эксперимент предполагает два момента. Во-первых, аналогично выводам Алис и др., система активного зондирования применяет дополнительное правило для проверки длины соединения. В нашем случае только соединения с 200-байтовой полезной нагрузкой запускали активное зондирование, а не с 2 байтами или 50 байтами. Во-вторых, трафик, исключенный любым из пяти правил, обнаруженных в Алгоритме 1, также не будет запускать систему активного зондирования.

Система активного зондирования эволюционировала с 2019 года. Мы хотим узнать, использовались ли те же правила обнаружения в Алгоритме 1 исторически для запуска активного зондирования. Чтобы проанализировать это, мы получили 282 полезные нагрузки, которые были воспроизведены (и, таким образом, однажды запустили GFW) в эксперименте с низкой энтропией от Алис и др. Затем мы написали программу, чтобы определить, будет ли полезная нагрузка исключена текущей системой блокировки, и запустили программу с полученными 282 полезными нагрузками. В результате 45 зондов, которые ранее запускали активное зондирование, были исключены (по правилу Ex3). 19 мая 2022 года мы многократно отправляли эти 45 полезных нагрузок через GFW, подтверждая, что они действительно были исключены из текущей блокировки. Для каждой полезной нагрузки мы устанавливали 25 соединений с ней с VPS в TencentCloud Пекин на сервер-приемник в DigitalOcean Сан-Франциско. Этот результат говорит о том, что GFW, вероятно, обновил модуль анализа трафика своей системы активного зондирования с 2020 года. Кроме того, зонды, отправляемые текущим GFW, также отличаются от тех, которые наблюдались в 2020 году. Новые зонды, по сути, являются случайными полезными нагрузками, которые распределены тройками по 16, 64 и 256 байтам. Для каждой из этих длин GFW отправлял примерно одинаковое количество зондов: 48, 46 и 47 на один сервер и 238, 228 и 233 на другой.

6. Понимание стратегий блокировки

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

6.1. Эксперимент по сканированию Интернета

12 мая 2022 года мы провели 10% сканирование IPv4 Интернета на TCP-порту 80 с сервера, расположенного в CU Boulder. Следуя предыдущим работам, которые идентифицируют ненадежные узлы в сканированиях Интернета, мы удаляем IP, которые отвечают TCP-окном 0 (поскольку мы не можем отправить им данные) или не принимают последующее соединение. Это оставляет нам 7 миллионов сканируемых IP-адресов. Затем мы случайным образом и равномерно разделили эти 7 миллионов IP-адресов на девять подмножеств и назначили каждое из них нашим девяти точкам наблюдения в дата-центре TencentCloud Пекин. Затем мы использовали измерительную программу, которую мы написали и установили во всех девяти точках наблюдения для эксперимента. Для каждого IP программа последовательно подключается к его порту 80 до 25 раз с интервалом в одну секунду между ними. В каждом соединении мы отправляем те же 50 байтов случайных данных, которые могут вызвать блокировку. Если мы видим, что 5 последовательных соединений завершаются с тайм-аутом (не удается подключиться) после того, как мы отправили данные, мы помечаем IP как затронутый. В противном случае, если все 25 соединений завершаются успешно, мы помечаем IP как незатронутый. Мы помечаем IP, к которым мы вообще не можем подключиться, как неизвестные (например, сервер отключен или сбой сети, не связанный с GFW, препятствует нашему подключению в первую очередь).

Мы также повторили этот процесс, но отправили 50 байтов \x00, что не вызывает блокировку GFW. Если сервер помечен как затронутый в этом тесте, это, вероятно, связано с тем, что сервер блокирует нас, а не GFW, и мы удаляем эти IP из наших результатов. Это оставляет чуть более 6 миллионов IP-адресов.

Наконец, мы удаляем «неоднозначные» результаты, которые могут быть связаны с периодическими сбоями сети или ненадежными точками наблюдения. В частности, мы удаляем IP, которые в наших сканированиях случайных или нулевых данных были помечены как неизвестные (мы никогда не могли подключиться) или имели периодические тайм-ауты соединения (например, несколько соединений завершились с тайм-аутом, но не 5 подряд). Это оставляет 5,5 миллионов IP-адресов, которые мы можем легко пометить как незатронутые (все 25 соединений завершились успешно) или затронутые (в какой-то момент они оказались заблокированными после того, как мы отправили случайные данные).

6.2. Не все подсети/AS одинаково затронуты

Из 5,5 миллионов обработанных IP-адресов 98% не затронуты блокировкой GFW, что говорит о том, что Китай довольно консервативен в применении этой новой цензуры. Мы группируем эти 5,5 миллионов IP-адресов по их выделенным IP-префиксам и AS, используя pyasn с базой данных AS от апреля 2022 года. Для IP-префиксов больше, чем /20, мы разбиваем выделение на набор префиксов /20, чтобы сохранить выделения примерно одинакового размера. Наши 5,5 миллионов IP-адресов включают 538 уникальных AS, которые имеют по меньшей мере 5 результатов, и подавляющее большинство из них в значительной степени не затронуты блокировкой GFW.

Рисунок 3 показывает распределения доли затронутых AS и префиксов /20. Мы обнаружили, что более 90% AS затронуты в режиме «все или ничего»: либо все IP-адреса, которые мы тестировали в AS, затронуты блокировкой GFW, либо ни один из IP-адресов, которые мы тестировали в AS, не затронут. Мы также наблюдаем, что затронуто только несколько AS: более 95% AS видят, что менее 10% их IP-адресов затронуты, и только 7 AS видят, что более 30% их IP-адресов затронуты.

Рисунок 4 показывает самые затронутые AS. Хотя это искажено в сторону более крупных AS (у которых в нашем сканировании больше IP-адресов), он показывает как AS, которые сильно затронуты (например, Alibaba US, Constant), так и те, которые не затронуты (Akamai, Cloudflare). Кроме того, некоторые AS имеют комбинацию затронутых и незатронутых префиксов (Amazon, Digital Ocean, Linode). Все затронутые или частично затронутые AS, которые мы видим, - это популярные поставщики VPS, которые можно использовать для размещения прокси-серверов, в то время как крупные незатронутые AS обычно не продают VPS-хостинг индивидуальным клиентам (например, CDN).

6.3. Характеристика вероятностной блокировки

Как было представлено в разделе 3, мы отправляем до 25 соединений с одной и той же полезной нагрузкой, прежде чем сделать какие-либо выводы о блокировке. Это необходимо, потому что цензор реализует блокировку вероятностно. Другими словами, простая отправка случайной полезной нагрузки на затронутый сервер один раз только иногда вызовет блокировку; однако, если продолжать устанавливать соединения с той же полезной нагрузкой на затронутый сервер, блокировка произойдет в конечном итоге. Это поднимает вопрос о том, какова вероятность блокировки соединения, и почему цензор реализует блокировку только вероятностно.

Оценка скорости блокировки. Из нашего 10% сканирования Интернета (раздел 6.2) было 109 489 IP-адресов, которые мы помечаем как заблокированные. Как показано на рисунке 5, распределение количества успешных соединений со случайными данными, которые мы можем установить с каждым IP-адресом, прежде чем он будет заблокирован, соответствует геометрическому распределению. Этот результат говорит о том, что блокировка каждого соединения происходит независимо с вероятностью 26,3%.

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

7. Оценка правил обнаружения GFW

В этом разделе мы оцениваем частоту ложных срабатываний и полноту правил обнаружения GFW, которые мы вывели в разделе 4. Чтобы определить влияние, которое эта блокировка может оказывать на обычный трафик, мы моделируем выведенные правила обнаружения для трафика в нашей университетской сети, не блокируя фактически какой-либо трафик. В отличие от GFW, мы моделируем правила обнаружения по отношению ко всем наблюдаемым TCP-соединениям, не ограничивая обнаружение 26% соединений к определенным диапазонам IP-адресов популярных дата-центров. Мы ожидаем увидеть мало или вообще не увидеть трафика обхода цензуры в этой сети, и любой трафик, который был бы заблокирован по правилам обнаружения, скорее всего, представляет собой ложную блокировку. Мы обнаруживаем, что выведенный алгоритм обнаружения заблокировал бы примерно 0,6% всех соединений в нашей сети. Из-за черного ящика GFW наши выведенные правила могут быть лишь подмножеством того, что использует GFW; однако мы показываем, что все соединения, которые Алгоритм 1 заблокировал бы, действительно были заблокированы, когда мы отправляли их префиксы вместе со случайными данными через GFW, что говорит о том, что наши выведенные правила имеют хорошее покрытие того, что использует GFW.

7.1. Эксперимент по анализу трафика

У нас есть доступ к 40-гигабитному сетевому отводу в CU Boulder, который позволяет нам обрабатывать копии всех входящих и исходящих пакетов в нашем кампусе. Используя это, мы собрали набор данных, включающий только номера портов назначения и первые 6 байтов данных полезной нагрузки для соединений, которые уже не удовлетворяют другим правилам исключения в Алгоритме 1. Точнее, мы реализовали собственный инструмент анализа пакетов с помощью PF_RING. Для каждого соединения мы проверяли первый пакет данных, отправленный клиентом. Мы убедились, что пакет имеет правильную контрольную сумму TCP и что его номер последовательности - это первый ожидаемый пакет данных после TCP-рукопожатия в соединении (убедившись, что мы не пропустили первый пакет данных). Для соединений, которые не исключены Алгоритмом 1, то есть тех, которые, как мы ожидаем, будут заблокированы, мы записывали порт назначения и первые шесть байтов соединения, чтобы помочь идентифицировать его протокол.

Мы проводили эту коллекцию с июля 2022 года по сентябрь 2022 года. В общей сложности мы проанализировали 1,7 миллиарда соединений и записали 442 928 уникальных 6-байтовых префиксов соединений, которые могли бы быть заблокированы. Для каждого из этих 442 928 6-байтовых префиксов мы добавляем к нему те же 194 байта случайных данных, чтобы создать 200-байтовую полезную нагрузку. Затем мы многократно отправляли каждую полезную нагрузку через реальный GFW в сентябре 2022 года, чтобы проверить, были ли они действительно заблокированы или вместо этого были исключения, которые мы ранее не идентифицировали. Для каждой полезной нагрузки мы устанавливали до 25 соединений с ней с VPS в TencentCloud Пекин на сервер-приемник в DigitalOcean Сан-Франциско.

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

Оценка частоты ложных срабатываний. В общей сложности мы проанализировали 1,7 миллиарда соединений в нашей сети в период с июля 2022 года по сентябрь 2022 года. Для каждого соединения мы определяем, какие правила в Алгоритме 1 исключили бы его из блокировки. Как показано на рисунке 6, мы наблюдаем в среднем, что 0,6% TCP-соединений с нашего отвода были бы заблокированы по правилам обнаружения GFW, которые мы вывели.

Существует по меньшей мере две стратегии, которые цензор применяет для снижения частоты ложных срабатываний. Во-первых, как было представлено в разделе 6, GFW применяет эту цензуру только к части IP-подсетей. Это решение может быть попыткой смягчить проблему базовой ставки, с которой сталкивается цензор. Поскольку относительно небольшое количество соединений в целом являются прокси-соединениями, даже небольшая частота ложных срабатываний (например, 0,6%) привела бы к блокировке преимущественно доброкачественного трафика, если бы она применялась широко. Сужая область действия IP, к которым она применяется, Китай может снизить сопутствующий ущерб от своей цензуры. Во-вторых, как было исследовано в разделе 6.3, даже для трафика, направленного на этот набор IP-подсетей, GFW, как наблюдается, блокирует только около четверти всего трафика, снижая частоту ложных срабатываний до четверти.

Возможно, что 0,6% соединений, которые мы определили, могут быть полностью зашифрованными прокси. Чтобы исследовать эту возможность, мы ведем учет количества уникальных 6-байтовых префиксов, которые мы видим в каждом соединении, которое было бы заблокировано по правилам GFW. Если все эти соединения действительно являются полностью зашифрованными прокси, мы ожидаем увидеть равномерное распределение по 2566 возможным значениям 6-байтов. В противном случае, если есть 6-байтовые значения, которые встречаются часто, это могут быть заголовки популярных протоколов, что указывает на ложные срабатывания в блокировке GFW.

Рисунок 7 показывает распределение первых 6 байтов всех 9,7 миллионов соединений с нашего отвода, которые были бы заблокированы по правилам GFW, которые мы вывели. Кроме того, таблица 3 показывает 10 лучших 6-байтовых значений из соединений, которые могли бы быть заблокированы. Хотя мы не можем идентифицировать многие из этих протоколов, их частота наряду с низкой энтропией указывает на то, что они, скорее всего, не являются полностью зашифрованными прокси.

Оценка полноты выведенных правил. Среди 442 928 полезных нагрузок, которые мы создали и отправили через реальный GFW, мы обнаружили, что только один префикс был исключен GFW, что предупредило нас об исключении префикса TLS Application Data (\x17\x03[\x00-\x09]). Мы добавили это исключение к нашим выведенным правилам (Ex5). Этот результат говорит о том, что наши выведенные правила имеют хорошее покрытие того, что использует GFW.

8. Стратегии обхода цензуры

Наше понимание этой новой системы цензуры позволяет нам вывести несколько стратегий обхода цензуры. В разделе 8.1 и 8.2 мы представляем два широко принятых контрмеры, которые помогают пользователям в Китае обходить цензуру с января 2022 года и октября 2022 года соответственно. Мы обсуждаем другие стратегии обхода цензуры в Приложении A. Мы ответственно и своевременно поделились нашими выводами и предложениями с разработчиками различных популярных инструментов противодействия цензуре, у которых миллионы пользователей, что мы подробно изложим в разделе 8.3.

8.1. Настраиваемые префиксы полезной нагрузки

Правила исключения Ex2 и Ex5 из Алгоритма 1 рассматривают только первые несколько байтов в соединении, что позволяет GFW эффективно исключать незашифрованный трафик; однако это создает возможность для потенциальной контрмеры. В частности, мы предлагаем предварительно добавить настраиваемый префикс к полезной нагрузке первого пакета в (обходном) соединении.

Настраиваемый заголовок IV. Соединения Shadowsocks начинаются с вектора инициализации (IV), который имеет длину 16 или 32 байта в зависимости от используемых шифров шифрования. Как было представлено в разделе 4.2, преобразование первых шести (или более) байтов IV в печатные символы ASCII исключит соединения по правилу Ex2. Аналогичным образом, преобразование первых трех, четырех или пяти байтов IV в заголовки распространенных протоколов исключит соединения по правилу Ex5 (например, преобразование первых трех байтов IV в 0x16 0x03 0x03). Эти контрмеры требуют минимальных изменений в клиенте и никаких изменений в сервере, и поэтому были приняты многими популярными инструментами обхода цензуры. Ограничение первых нескольких байтов 32-байтового IV для печатных символов ASCII не уменьшит случайность до такой степени, чтобы это повлияло на безопасность шифрования. Например, даже фиксация первых шести байтов для печатных символов ASCII все равно оставляет 26 случайных байтов IV, что все еще больше, чем обычный 16-байтовый IV.

Ограничения. Это временное решение, и цензор может довольно легко заблокировать его. Цензор может пропускать первые несколько байтов и применять правила обнаружения к остальным данным в соединении. Имитация протокола также затруднительна на практике. Цензор может ввести более строгие правила обнаружения или активно зондировать сервер, чтобы проверить, действительно ли он работает с TLS или HTTP. Тем не менее, тот факт, что эта стратегия по-прежнему работает по состоянию на февраль 2023 года, более чем через год после ее принятия многими популярными инструментами обхода цензуры в январе 2022 года, подчеркивает, что даже простые решения могут быть эффективны против цензоров с ограниченными ресурсами.

8.2. Изменение popcount

Как было представлено в разделе 4.1, GFW исключает соединение, если его первый пакет данных имеет средний popcount на байт ≤ 3,4 или ≥ 4,6 (Ex1). Основываясь на этом наблюдении, можно увеличить (уменьшить) popcount, вставив дополнительные единицы (нули) в пакет, чтобы обойти цензуру. Мы представляем и анализируем гибкую схему, которая изменяет popcount на байт до любого заданного значения или диапазона. Мы реализовали эту схему в Shadowsocks-rust и Shadowsocks-android, помогая пользователям в Китае обходить цензуру с октября 2022 года. В январе 2023 года крупная служба обхода цензуры в Китае (которая попросила не называть ее) также реализовала версию этой схемы и обнаружила аналогичный успех.

На высоком уровне мы берем исходные полностью зашифрованные пакеты в качестве входных данных: работая только с шифртекстами, мы не рискуем нарушить конфиденциальность. При отправке пакета мы сначала вычисляем его средний popcount на байт; если значение больше 4, то мы определяем, сколько единичных бит нам нужно добавить в пакет, чтобы получить popcount больше 4,6. И наоборот, если popcount меньше 4, то мы определяем, сколько нулевых бит нам нужно добавить, чтобы уменьшить popcount до значения менее 3,4. В любом случае мы добавляем необходимое количество единичных или нулевых бит к исходному шифртексту, а затем добавляем 4 байта, обозначающие количество добавленных бит, что в конечном итоге дает нам битовую строку B, которая имеет popcount на байт, который не подвергает ее цензуре.

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

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

Эта схема имеет несколько преимуществ. Во-первых, схема поддерживает параметризуемый popcount на байт на случай, если GFW обновит свое правило popcount, чтобы блокировать еще больший диапазон. Во-вторых, из-за ее продуманной конструкции нет очевидных отпечатков пальцев, которые сигнализировали бы цензору, что это пакет с измененным popcount. Наконец, она имеет низкие накладные расходы; она добавляет только столько единиц (или нулей), сколько строго необходимо (дополненных до ближайшего байта). В худшем случае, когда popcount увеличивается с 4 до 4,6, это приводит к увеличению накладных расходов всего на 17,6%. В результате его можно реализовать не только для первого пакета, но и для каждого пакета в соединении, тем самым изолируя его от будущих обновлений цензора, которые могут смотреть за первый пакет.

8.3. Ответственное раскрытие информации

16 ноября 2021 года, через 10 дней после того, как GFW начал использовать эту новую блокировку, мы раскрыли информацию об этой новой блокировке общественности. С развитием нашего понимания этой новой блокировки мы вывели и оценили различные стратегии обхода цензуры. Мы ответственно и своевременно поделились нашими выводами и предложениями с разработчиками различных популярных инструментов противодействия цензуре, у которых миллионы пользователей, включая Shadowsocks, V2Ray, Outline, Lantern, Psiphon и Conjure. Ниже мы подробно рассмотрим наше раскрытие информации и ответы сообщества по противодействию цензуре.

13 января 2022 года мы поделились нашей первой стратегией обхода цензуры с группой разработчиков. Это решение, описанное в разделе 8.1, требует минимальных изменений в коде клиентов и никаких изменений на стороне сервера. К 14 января 2022 года разработчик Shadowsocks-rust zonyitoo, разработчик V2Ray Xiaokang Wang и разработчик Sagernet nekohasekai уже добавили это решение по обходу цензуры в качестве опции для своих клиентов. 4 октября 2022 года database64128 реализовал настраиваемую пользователем версию этой стратегии в Shadowsocks-go. 25 октября 2022 года разработчики Outline приняли высоконастраиваемое решение для своего клиента. 14 октября 2022 года мы выпустили модифицированный Shadowsocks, который использовал стратегию изменения popcount, описанную в разделе 8.2.

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

Хотя мы не изучали другие страны, кроме Китая, наши предложенные стратегии обхода цензуры, как сообщается, также работают в Иране, еще одной стране, которая, как сообщается, блокирует и ограничивает скорость полностью зашифрованных прокси. 13 февраля 2023 года разработчики Lantern сообщили, что принятый протокол «составил большинство нашего трафика из Ирана» с января 2023 года. 13 февраля 2023 года другой поставщик услуг обхода цензуры сообщил, что после включения функции смягчения Outline в ноябре 2022 года их услуги перешли из полностью заблокированных в состояние, когда они обслуживают 850 000 пользователей в день из Ирана.