Отпечатки прокси-трафика с инкапсулированными TLS-рукопожатиями

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

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

1. Введение

Последние десятилетия стали свидетелями глобальной эскалации цензуры и слежки со стороны различных национальных государств. Среди наиболее ярких примеров - Китай, где Великий китайский файрвол (GFW) блокирует доступ к зарубежным веб-сайтам, фильтрует результаты поиска и вмешивается в частные коммуникации. В Иране правительство блокирует социальные сети и ограничивает доступ к определенным протоколам в периоды политической нестабильности. В России “Суверенный Интернет” ограничивает доступ к новостям и СМИ во время войны в Украине, демонстрируя, как легко цензоры могут создавать информационные пузыри и изолировать отдельные регионы от остального Интернета.

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

С другой стороны, такие достижения, как глубокий анализ пакетов (DPI) операторского класса, позволили цензорам перейти от базовой фильтрации IP-адресов или ключевых слов к более сложным методам обнаружения. Это привело к продолжающейся гонке вооружений между разработчиками средств обхода цензуры, которые внедряют механизмы обфускации, чтобы избежать обнаружения, и цензорами, которые стремятся обойти такую обфускацию: цензоры используют активное зондирование для выявления прокси-серверов, что вынуждает разработчиков прокси внедрять механизмы защиты от зондирования. Цензоры блокируют прокси-серверы по их уникальным TLS-шифрокостюмам, в ответ на что прокси меняют свои шифрокостюмы, чтобы имитировать популярные браузеры. Цензоры блокируют полностью зашифрованные прокси на основе высокой энтропии. Разработчики прокси затем изменяют байтовые шаблоны, чтобы уменьшить энтропию. Такие взаимные действия представляют собой текущее состояние гонки вооружений в области обхода цензуры, когда цензоры используют недостатки дизайна и реализации отдельных протоколов-оболочек, а разработчики исправляют недостатки и экспериментируют с новыми протоколами. В сообществе распространено мнение, что каждый новый протокол-оболочка требует от цензора своего собственного набора функций и отдельного анализа для блокировки.

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

В этой статье мы фокусируемся на одном конкретном отпечатке такого рода, называемом инкапсулированными TLS-рукопожатиями, и на практичности его использования для обнаружения трафика анонимных прокси. Инкапсулированные TLS-рукопожатия - это TLS-рукопожатия, которые происходят внутри зашифрованного или обфусцированного протокола-оболочки. Как показано на рисунке 2 (красный цвет), эти рукопожатия генерируются пользовательскими приложениями (например, браузерами), а протокол прокси-сервера затем шифрует и передает их на прокси-сервер, который, в свою очередь, пересылает их конечному получателю (например, веб-серверам). Это отличает их от стандартных TLS-рукопожатий, которые имеют незашифрованную структуру и видны сетевым посредникам. Мы объясняем, как наличие инкапсулированных TLS-рукопожатий указывает на вложенное или избыточное наложение протоколов, что, в свою очередь, сигнализирует о том, что соединение несет проксируемый трафик. Хотя инкапсулированные TLS-рукопожатия не могут быть легко идентифицированы с помощью анализаторов протоколов, мы показываем, что пакеты, которыми обмениваются во время (инкапсулированного) TLS-рукопожатия, демонстрируют четкие закономерности в своем размере, времени и направлении. Эти закономерности остаются видимыми даже после шифрования, что позволяет цензору надежно идентифицировать инкапсулированные рукопожатия, не нарушая шифрование протокола-оболочки.

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

Мы протестировали 23 конфигурации анонимных прокси, включая основные протоколы обхода цензуры, используемые миллионами людей по всему миру, такие как shadowsocks, vmess, trojan и vless, а также протоколы, предложенные в предыдущих исследованиях, такие как httpt. Мы обнаружили, что все протестированные протоколы анонимных прокси в своих стандартных конфигурациях уязвимы для снятия отпечатков на основе инкапсулированных TLS-рукопожатий, при этом уровень истинных срабатываний (TPR) во всех случаях превышает 70%. Такие показатели TPR имеют серьезные последствия (§ 3), особенно с учетом того, что одно обнаружение может привести к блокировке цензором всех последующих подключений к соответствующему прокси-серверу. Даже продвинутые конфигурации, инкапсулирующие прокси-трафик в дополнительные уровни-оболочки, такие как shadowsocks внутри websocket внутри TLS, обеспечивают ограниченную защиту и лишь незначительно снижают вероятность обнаружения. Вопреки распространенному мнению, мы обнаружили, что случайное заполнение немного усложняет снятие отпечатков, но не настолько, чтобы предотвратить эксплойт. Мы демонстрируем, что даже для более агрессивных схем заполнения, таких как XTLS-vision и obfs4, цензоры могут легко адаптировать свои статистические модели и полагаться только на порядок и направление пакетов, а не на их размер, для обнаружения.

В ходе 30-дневной оценки наше развертывание в Merit обработало более 110 миллионов потоков, поддерживая максимальный уровень ложных срабатываний на уровне 0,0544%. Такая точность ставит нашу атаку с использованием снятия отпечатков в один ряд с подходами, ранее применявшимися реальными цензорами. Примечательно, что наш метод остается полностью пассивным, не зависит от незаполненных обфусцированных протоколов и может быть адаптирован для идентификации заполненных вариантов.

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

2. Предпосылки и связанные работы

2.1 Интернет-цензура и ее обход

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

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

Обход на основе каналов требует механизмов обфускации. Большинство механизмов обфускации либо маскируют каналы под разрешенные протоколы (т.е. мимикрия), либо скрывают каналы так, чтобы они не были похожи на запрещенные протоколы (например, рандомизация). Обфускация на основе мимикрии имитирует характеристики трафика популярных разрешенных протоколов (например, HTTP, Skype). Некоторые даже доводят подход мимикрии до крайности, туннелируя трафик обхода цензуры через реальные легитимные сетевые сервисы, такие как облачное хранилище, электронная почта, VoIP и DNS, что приводит к более правдоподобным отпечаткам протоколов. С другой стороны, подходы к обфускации на основе рандомизации направлены на устранение всех отпечатков путем шифрования трафика в биты, неотличимые от случайных. Примерами этого являются shadowsocks, vmess и obfs4, которые противостоят анализаторам протоколов, не имея фиксированной структуры протокола.

2.2 Атаки на обфусцированные средства обхода цензуры

В предыдущих исследованиях был задокументирован ряд активных и пассивных атак реальных цензоров на обфусцированные средства обхода цензуры. Активные атаки предполагают, что цензоры отправляют специально сформированные зонды на подозрительные конечные точки и анализируют их ответы. GFW удалось идентифицировать серверы Tor, VPN и shadowsocks, отправляя запросы на подключение по целевому протоколу и отслеживая, соответствуют ли ответы ожидаемому поведению протокола. В ответ были разработаны “устойчивые к зондированию” прокси, которые не отвечают на запросы неаутентифицированного клиента. Однако недавние работы показывают, что идентифицировать сервер можно даже без явных ответов сервера, благодаря специфичным для приложения особенностям на сетевом уровне, таким как способ и время закрытия сервером соединения.

Пассивные атаки использовались для обнаружения как мимикрирующих, так и рандомизированных обфускаций. Хумансадр и др. утверждают, что обфускация путем имитации “принципиально порочна”, поскольку идеально сымитировать все специфичные для реализации особенности поведения слишком сложно, и предлагают в качестве альтернативы туннелирование. Однако даже при туннелировании трафика обхода цензуры обнаружение остается возможным путем снятия отпечатков несоответствий в реализации протокола-оболочки. Примеры из прошлого включают блокировку Tor из-за уникальных отпечатков в его пользовательской реализации TLS, таких как необычные наборы шифров. Snowflake, обфускация Tor на основе WebRTC, была аналогичным образом идентифицирована по ее необычному поведению DTLS. Также могут использоваться особенности, не связанные с контентом, такие как чрезмерное количество пакетов подтверждения TCP ACK или ненормальное распределение размеров пакетов. В то время как подходы на основе рандомизации устраняют многие из этих потенциальных отпечатков, сам по себе вид случайного трафика может стать признаком. Ван и др. демонстрируют, что длина пакетов и энтропия могут идентифицировать полностью зашифрованные прокси, такие как obfs4, а совсем недавно было обнаружено, что GFW блокирует полностью зашифрованный трафик, используя энтропию в качестве одного из признаков. В ответ разработчики реализовали ряд контрмер, таких как предоставление пользователям более детального контроля над отпечатками и энтропией протокола-оболочки.

2.2.1 Контекстуализация нашего подхода к снятию отпечатков

Описываемая в данной статье атака с использованием снятия отпечатков ортогональна всем вышеупомянутым атакам, направленным на протоколы обхода цензуры. Как активные, так и пассивные атаки, обнаруженные в предыдущих работах, используют недостатки реализации в протоколах-оболочках/прокси (изображены синим цветом на рисунке 2). В отличие от них, данная работа фокусируется на отпечатках, генерируемых инкапсулированным трафиком приложений (трафик, генерируемый пользователем внутри туннеля, например, из браузеров), что показано красным цветом на рисунке 2. Это означает, что 1) наша атака потенциально может дополнять существующие активные или пассивные стратегии снятия отпечатков, направленные на протоколы-оболочки, для дальнейшего повышения точности; и 2) существующие контрмеры, такие как utls, неэффективны против нашего подхода, поскольку они действуют на протокол-оболочку, а не на инкапсулированные уровни внутри него. Особо следует подчеркнуть различие между нашим подходом и “снятием отпечатков TLS”, как это было охарактеризовано в предыдущих работах. Эти предыдущие работы были направлены на идентификацию реализаций TLS путем изучения полей в сообщениях ClientHello уровня-оболочки/поверхностного уровня (например, различение TLS-потоков, генерируемых браузерами Tor, от потоков, генерируемых Chrome). В отличие от них, наша работа направлена на поиск закономерностей, указывающих на наличие TLS-рукопожатий, инкапсулированных в зашифрованные/обфусцированные протоколы.

Наиболее близкими к нашей работе являются работы, в которых делается вывод о базовом протоколе и семантике протокола по зашифрованным потокам, с использованием признаков, которые остаются видимыми после шифрования, таких как размер пакетов, время и направление.

3. Модель угроз

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

Реакция цензора на ложные срабатывания и ложные пропуски асимметрична. Цензор крайне чувствителен к побочному ущербу - экономическим затратам, связанным с ошибочной блокировкой легитимного трафика во время цензуры. Нежелание цензора наносить побочный ущерб - это, по сути, то, что делает возможным обход цензуры. Более того, из-за низкой доли трафика обхода цензуры даже кажущийся низким уровень ложных срабатываний (1%) может быть экономически нецелесообразным. С другой стороны, умеренный уровень ложных пропусков можно считать приемлемым. Это связано с тем, что пользователи инструментов обхода цензуры, скорее всего, используют их ежедневно, генерируя сотни потоков за сеанс просмотра, и цензору достаточно обнаружить один поток, чтобы заблокировать прокси-сервер.

4. Инкапсулированные TLS-рукопожатия

Начнем с того, что объясним, как мы снимаем отпечатки анонимного прокси-трафика. В основе всех действий по проксированию и туннелированию лежит концепция вложенных протокольных стеков, где один стек протоколов инкапсулируется в полезную нагрузку другого, чтобы пройти через сетевых посредников, не будучи обнаруженным. Это наблюдение лежит в основе атаки с использованием снятия отпечатков, которую мы оцениваем в данной статье, и делает этот подход не зависящим от выбора прокси-протоколов. Вложенные протокольные стеки редко встречаются в обычных прямых соединениях “клиент-сервер”. Однако в проксируемых соединениях протокол-оболочка служит для передачи данных между клиентом и прокси-сервером, в то время как инкапсулированный протокол приложения обеспечивает сквозную связь между клиентом и конечным сервером назначения. Вложенные протокольные стеки могут приводить к нарушениям многоуровневой модели OSI, например, когда один и тот же протокол инкапсулируется сам в себя, как в случае TLS-прокси, инкапсулирующего HTTPS-трафик (т.е. TLS-over-TLS).

Наличие вложенных протокольных стеков указывает на проксирование. Однако идентифицировать такое поведение может быть непросто, поскольку протокол-оболочка шифрует или обфусцирует свою полезную нагрузку. В предыдущих работах эта проблема решалась путем моделирования непроксируемых соединений и обнаружения аномалий путем сравнения их поведения с моделью. Тем не менее, точно охарактеризовать “легитимный” трафик может быть сложно из-за разнообразия трафика и протоколов в Интернете. Например, хотя HTTPS составляет значительную часть TLS-трафика, полезная нагрузка TLS, отклоняющаяся от ожидаемого поведения HTTP, не всегда подразумевает наличие второго протокольного стека, поскольку существуют и другие протоколы, использующие TLS для шифрования.

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

Несколько аспектов инкапсулированных TLS-рукопожатий делают их идеальным отпечатком для прокси-трафика.

• Отличительность: Как и стандартные TLS-рукопожатия, инкапсулированные TLS-рукопожатия также четко определены, и пакеты, передаваемые на этапе рукопожатия, демонстрируют четкие характеристики размера, времени и направления, как показано на рисунке 3. Например, большинство сообщений ClientHello обычно имеют размер от 200 до 550 байт в зависимости от версии TLS, в то время как сообщения ServerHello с сертификатами могут достигать нескольких тысяч байт и демонстрировать более высокую степень вариативности в разных потоках. Более того, поскольку каждое сообщение рукопожатия логически зависит от предыдущего переданного сообщения, злоумышленник, находящийся на пути прохождения трафика, может использовать порядок, в котором пакеты, несущие эти сообщения, наблюдаются в сети. Эти характеристики остаются видимыми даже после шифрования и, таким образом, позволяют нам идентифицировать инкапсулированные TLS-рукопожатия, не нарушая протокол-оболочку.
• Надежность: TLS повсеместно распространен в Интернете, обеспечивая основу для безопасной связи между различными приложениями. Таким образом, инкапсулированные TLS-рукопожатия служат надежным отпечатком, поскольку пользователям прокси было бы непрактично избегать генерации таких отпечатков, отказываясь от использования TLS.
• Точность: Как было сказано ранее, инкапсулированные TLS-рукопожатия указывают на проксируемые соединения. В § 7 мы приводим эмпирические доказательства того, что такое поведение довольно уникально для использования прокси. Следовательно, использование инкапсулированных TLS-рукопожатий в качестве отпечатка приводит к минимальному побочному ущербу для цензоров.

если is_обфусцированный_или_зашифрованный(поток):
  извлечь: размер, время, направление из поток[полезная_нагрузка]

если совпадает_с_TLS-рукопожатием(размер, время, направление):
  записать_как_прокси-трафик(поток)

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

5. Этические соображения

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

Основная этическая проблема связана с обработкой необработанного сетевого трафика. Мы получаем доступ к живому трафику ISP через наш Монитор в Merit для обучения классификаторов и оценки предложенной атаки с использованием снятия отпечатков. Развертывание нашего Монитора контролируется Merit, у которой есть большой опыт сотрудничества и устоявшиеся этические нормы и правила конфиденциальности для подобных проектов. Монитор получает только зеркальную копию трафика, не занимаясь фактической маршрутизацией, что гарантирует, что работа Merit не будет затронута. Необработанный трафик обрабатывается кластером Zeek, который выполняет синтаксический анализ протокола и извлечение признаков (§ 6.2). Вместо того чтобы записывать необработанный трафик, мы регистрируем только извлеченные признаки, состоящие из последовательностей размеров пакетов и времени, без включения каких-либо полезных нагрузок пакетов. Эти логи хранятся и обрабатываются на сервере, поддерживаемом Merit, доступ к которому имеют только отдельные члены команды на основе принципа наименьших привилегий. Мы подчеркиваем, что ни на одном из этапов проекта полезные нагрузки пакетов не записываются на диск и не просматриваются людьми.

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

6. Классификация на основе сходства

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

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

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

6.1 Сбор данных

Чтобы скомпилировать обучающий набор данных с трафиком TLS и не-TLS, мы установили нашу станцию мониторинга внутри Merit, как показано на рисунке 4, которая отслеживает 50 Гбит/с входящего и исходящего трафика, зеркалированного с магистрального маршрутизатора. Сначала пользователь внутри Merit инициирует TLS-соединение с внешним TLS-сервером (1). Когда трафик проходит через отслеживаемый маршрутизатор, его копия отправляется на наш Монитор (2). Монитор управляет кластером из 23 экземпляров Zeek, на которых запущен наш пользовательский скрипт (3). Из-за большого объема трафика мы оптимизировали нашу установку с помощью PF_Ring для повышения скорости обработки пакетов. Мы применяем следующие правила фильтрации при создании наборов данных для обучения и тестирования:

• Для обоих потоков TLS и не-TLS мы фильтруем только TCP и требуем наблюдения как пакета SYN, так и пакета SYN-ACK в обратном направлении. Это обеспечивает симметричную маршрутизацию и то, что мы видим начало соединения, где ожидается рукопожатие протокола.
• Мы записываем первые W_o пакетов TCP с данными, передаваемых в любом направлении, для анализа.
• Мы отбрасываем короткоживущие потоки с меньшим количеством пакетов, чем окно наблюдения W_o.
• Для потоков TLS мы различаем версии 1.2 и 1.3 на основе расширения Supported Version в записях ServerHello.
• Мы отфильтровываем потоки с пустым полем Server Name Indication и потоки, в которых не наблюдается записей TLS с типом Application Data (например, неудачное рукопожатие).

Несмотря на оптимизацию, внедренную для повышения скорости обработки пакетов, обработка трафика со скоростью 50 Гбит/с на одном сервере все еще приводит к не пренебрежимо малой потере пакетов из-за узких мест процессора. Поэтому мы производим выборку только 1/8 всех TCP-потоков, поступающих на Монитор. Эта выборка основана на парах IP-адресов. Подробная разбивка собранных наборов данных представлена в таблице 1.

Таблица 1: Набор данных TLS/не-TLS для обучения и тестирования классификаторов.

6.2 Извлечение признаков

Каждый поток представляется в виде последовательности целых чисел, где абсолютное значение каждого целого числа соответствует размеру полезной нагрузки TCP, а знак указывает направление пакета. Мы используем анализ SEQ/ACK для установления полного порядка, в котором пакеты должны обрабатываться. Пример такой последовательности: (+517, -1400, -1400, +80). Дополнительно мы записываем время между прибытием пакетов.

Мы извлекаем n-граммы из этих последовательностей размеров пакетов. N-граммы использовались в предыдущих работах для анализа зашифрованного DNS и VoIP-трафика. В нашем случае интуиция заключается в том, что по сравнению с 1-граммами, представления n-грамм могут лучше различать массовую передачу и интерактивные коммуникации, такие как рукопожатия протоколов. Более того, для протоколов с четко определенными процессами рукопожатия, таких как TLS, мы ожидаем, что n-граммы смогут фиксировать закономерности в кортежах размеров во время переходов состояний. Например, первая 3-грамма, извлеченная из предыдущей последовательности пакетов, - это (+517, -1400, -1400), что часто сигнализирует об исходящем ClientHello, за которым следует сегментированный ServerHello. Такие шаблоны были бы скрыты в представлении 1-грамм. Мы экспериментировали с 2-граммами, 3-граммами и 4-граммами и обнаружили, что 3-граммы обеспечивают наилучший баланс между производительностью и требованиями к памяти.

Мы дополняем представление n-грамм признаками “всплеска”, которые учитывают направления пакетов и время между их прибытием. Всплески относятся к последовательностям последовательных пакетов, движущихся в одном направлении, что часто происходит, когда TCP разбивает большие записи уровня приложения write () на более мелкие части для транспортировки. Последовательности всплесков более устойчивы к незначительным изменениям на уровне пакетов, поскольку они учитывают только совокупный объем трафика и направление, в котором он движется. В частности, учитывая исходную запись потока TCP и соответствующее время между прибытием, мы сначала оцениваем RTT соединения как время, прошедшее между наблюдением пакета SYN и прибытием первого пакета ACK, отправленного клиентом на Монитор. Чтобы построить последовательности всплесков, мы объединяем размеры последовательных пакетов, которые 1) перемещаются в одном направлении и 2) имеют время между прибытием менее чем в три раза превышающее расчетное время приема-передачи.

6.3 Классификаторы

Чтобы сделать классификацию, мы развертываем два теста: тест хи-квадрат (χ2) над представлением 3-грамм и метрику расстояния Махаланобиса над последовательностью всплесков. Мы классифицируем поток как TLS только тогда, когда оба теста пройдены. Интуиция, лежащая в основе этого подхода, заключается в том, что первый тест фиксирует локальные порядки последовательностей пакетов и шаблоны перехода состояний, тогда как второй предлагает более агрегированный взгляд на динамику потока.

6.3.1 Тест хи-квадрат

Тест хи-квадрат - это статистический метод определения того, значительно ли отличаются друг от друга распределения категориальных переменных, путем сравнения наблюдаемых частот с ожидаемыми для каждой категории. В частности, ожидаемое количество вхождений каждой 3-граммы можно найти, учитывая обучающие наборы T₀ и T₁ для не-TLS и TLS соответственно, а также набор всех 3-грамм G. Затем, учитывая тестовый образец s, выводятся расстояния хи-квадрат для каждого класса, и мы классифицируем образец, сравнивая отношение двух расстояний с порогом принятия решения δ.

Однако использование необработанных размеров пакетов для генерации всех возможных 3-грамм приводит к чрезвычайно многомерному пространству признаков. Для стандартного MTU 1500 байт количество уникальных 3-граммных признаков будет 3000³. Мы внедряем две меры для снижения размерности. Во-первых, необработанные размеры пакетов дискретизируются на группы ∈ L перед генерацией 3-грамм. Мы экспериментировали с различными стратегиями группировки (например, равная ширина, равная частота) и обнаружили, что самые сильные результаты получаются, когда пакеты, несущие одинаковые семантические значения (то есть тип записи TLS), группируются вместе. Используя Zeek, мы помечаем пакеты рукопожатия из обучающего набора в соответствии с их типами рукопожатия TLS. Затем, учитывая размер группы |L|, мы выводим пользовательское сопоставление, которое пытается сопоставить размеры, связанные с одним и тем же типом рукопожатия TLS, одной и той же группе. Функция сопоставления сохраняет направленность; то есть одни и те же типы пакетов в разных направлениях группируются вместе, отличаясь соответствующей полярностью. Для нашего анализа мы устанавливаем |L| = 4, чтобы отличить ClientHello, ServerHello, ChangeCipherSpec, которые демонстрируют наиболее отчетливые шаблоны размера, от других пакетов. Затем мы ищем сопоставление, которое разделяет каждый из трех типов рукопожатия, сводя к минимуму количество пакетов, отклоняющихся от их соответствующих групп. Мы используем отображение M = [L₁: 1-160, L₂: 161-600, L₃: 601-1210, L₄: 1211+]. Например, 99,26% ClientHello в нашем обучающем наборе данных сопоставляются с L₂. Этот шаг уменьшает размерность до (4 * 2)³. Кроме того, вдохновленные, мы используем только 3-граммы, которые обеспечивают наилучшую различимость, выбирая те, которые демонстрируют низкую дисперсию среди выборок из одного класса, но высокую дисперсию среди выборок из разных классов.

Общий процесс обучения и тестирования описан в Алгоритме 1, где N_t и Pr(t, g) соответствуют количеству всех 3-грамм и вероятности конкретной 3-граммы g в потоке t соответственно. Переменные f и δ контролируют количество учитываемых в модели 3-граммных признаков и порог принятия решения. c обозначает противоположный класс c. Для примера в таблице 2 перечислены пять лучших 3-граммных признаков, ранжированных по различимости, которую они обеспечивают. Как и ожидалось, мы наблюдаем, что 3-граммы, скорее всего, представляющие шаблоны перехода состояний, являются одними из лучших функций, которые предлагают наилучшую различимость.

Таблица 2: Пример лучших 3-грамм с метками TLS. C-: Отправлено клиентом, S-: Отправлено сервером, H: Hello, EX: KeyExchange, CCS: ChangeCipherSpec.

6.3.2 Расстояние Махаланобиса

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

В алгоритме 2 описывается процесс измерения расстояния Махаланобиса с учетом обучающего набора TLS T₁, тестового образца s, окна пакета W_b и порога обнаружения γ. Мы устанавливаем W_b равным 2 × RT + 1, где RT - это минимальное количество круговых путей, необходимых для полного рукопожатия TLS. Следовательно, для TLS 1.2 и 1.3 W_b устанавливается равным 5 и 3 соответственно.

6.4 Оценка простого трафика TLS/не-TLS

Мы обучаем и тестируем наши классификаторы, используя набор данных TLS/не-TLS, который полностью помечен синтаксическими анализаторами протокола, как описано в § 6.1. Мы разбиваем потоки класса TLS на основе их соответствующих версий TLS и обучаем отдельный классификатор для каждой версии. Отрицательный класс состоит из не-TLS потоков, общих для обоих классификаторов. Мы устанавливаем окно наблюдения как W_o = 25, длину, которая, как мы обнаружили, достаточна для более чем 99,95% TLS-рукопожатий в нашем наборе данных. Кроме того, мы устанавливаем количество учитываемых 3-граммных признаков как f = 100. После завершения начального раунда обучения мы вычисляем расстояние хи-квадрат и расстояние Махаланобиса для каждого образца в обучающем наборе. Затем мы удаляем выбросы, демонстрирующие аномально большие расстояния от моделей, и повторно получаем модели с оставшимися выборками.

Мы оцениваем классификаторы при различных порогах расстояния хи-квадрат и Махаланобиса. Рисунок 9 показывает производительность обоих классификаторов с использованием наборов параметров, которые дают самые высокие TPR при определенных ограничениях FPR. Как и ожидалось, классификатор TLS 1.2 превосходит классификатор 1.3 в диапазоне конфигураций пороговых значений, особенно с точки зрения минимизации количества ложных срабатываний (FPR). Это можно интуитивно объяснить тем фактом, что полное рукопожатие в TLS 1.2 требует одного дополнительного кругового пути по сравнению с версией 1.3, которой удается обменять всю необходимую информацию в начальном круговом пути, что приводит к более коротким последовательностям рукопожатия. Поскольку наш классификатор Махаланобиса использует скользящее окно для идентификации потенциальных последовательностей рукопожатия, это означает, что в TLS 1.3 меньше элементов должны последовательно совпадать в потоке, что увеличивает вероятность случайных совпадений. Мы подчеркиваем, что низкий FPR классификации трафика TLS 1.2 делает его более привлекательной целью для цензоров, которые склонны уделять приоритетное внимание минимизации побочного ущерба. Что касается источника ложноотрицательных результатов, то, хотя мы не смогли вручную проверить необработанный трафик из-за этических проблем (§ 5), основываясь на метках и размерах пакетов, мы предполагаем, что нерегулярные рукопожатия, возникающие в результате оптимизации, такой как возобновление сеанса TLS и ложный запуск, могут способствовать большинству ложноотрицательных случаев.

7. Обнаружение обфусцированного прокси-трафика

В этом разделе мы оцениваем практичность использования инкапсулированных TLS-рукопожатий для обнаружения трафика, принадлежащего обфусцированным прокси. В соответствии с предыдущими исследованиями цензуры и снятия отпечатков пальцев наша цель - провести нашу оценку в реалистичных условиях, включив в нее точки зрения на то, как цензоры действуют на практике. С этой целью мы принимаем точку зрения потенциального цензора, развертывая нашу платформу обнаружения в рамках Merit. Как показано на рисунке 4, наша платформа обрабатывает два типа трафика: обфусцированный прокси-трафик, генерируемый от управляющей машины (4) к прокси-серверу (5), с нашим Монитором, расположенным на пути, а также легитимный проходящий сетевой трафик, генерируемый реальными пользователями, обслуживаемыми Merit. На протяжении всего этого раздела мы стремимся ответить на три исследовательских вопроса: (1) Насколько эффективна предлагаемая атака с использованием снятия отпечатков пальцев? (2) Могут ли современные контрмеры, такие как случайное заполнение и мультиплексирование потоков, эффективно защитить от атаки? (3) Насколько практично цензорам развертывать ее в больших масштабах, не причиняя значительного побочного ущерба?

7.1 Параметры эксперимента

7.1.1 Выбор конфигураций прокси

Мы составляем список конфигураций обфусцированных прокси на основе предыдущих исследований, онлайн-форумов для обсуждения цензуры и нашего опыта работы с инструментами обхода цензуры, используемыми в регионах со строгим контролем информации. Мы не включаем конфигурации, в которых отсутствует обфускация, такие как простой прокси HTTP/SOCKS или протоколы VPN, поскольку они тривиально обнаруживаются. Мы также исключаем «скрытые VPN», рекламируемые коммерческими VPN-провайдерами, поскольку предыдущая работа показала, что большинство из них не развертывают стандартные механизмы обфускации и их можно легко обнаружить с помощью зондирования. Конфигурации прокси, которые мы рассмотрели, показаны в таблице 3.

• Базовые конфигурации включают необработанные протоколы, такие как vmess, Shadowsocks, Trojan (trojan-go) и vless. Эти протоколы специально разработаны для обхода цензуры, и поэтому обфускация является одним из их главных приоритетов. Shadowsocks и vmess - это прокси-серверы со случайным внешним видом, которые используют шифрование, чтобы сделать свой трафик неотличимым от случайных байтов. Trojan и vless - это протоколы на основе TLS, инкапсулирующие трафик внутри туннелей TLS, чтобы избежать обнаружения.
• Расширенные конфигурации основаны на необработанных протоколах, добавляя дополнительные «оберточные» слои для инкапсуляции прокси-трафика внутри популярных легитимных протоколов. Примеры включают vmess-over-tls, vmess-over-websocket, shadowsocks-over-websocket-over-tls и т. д. Эта категория также включает выделенные подключаемые транспорты, такие как Cloak и shadowTLS, которые улучшают устойчивость Shadowsocks к цензуре, а также httpt и gost, которые представляют собой устойчивые к зондированию прокси-системы, скрывающие прокси-трафик внутри туннелей TLS.
• Конфигурации MUX объединяют несколько потоков приложений в одном TCP-соединении. Без мультиплексирования каждый поток TCP от локальных приложений, поступающих на прокси-клиент, приводил бы к новому исходящему TCP-соединению с прокси-сервером. При включенном мультиплексировании между прокси-клиентом и сервером поддерживается небольшое количество долгоживущих соединений, при этом все потоки приложений мультиплексируются внутри этих соединений. Хотя мультиплексирование часто рассматривается как оптимизация производительности, предыдущая работа показала, что мультиплексирование может уменьшить влияние атак с анализом трафика. В таблице 4 в Приложении перечислены рассмотренные реализации и их поддержка мультиплексирования.
• Конфигурации со случайным заполнением включают добавление фиктивных данных к полезной нагрузке, чтобы скрыть закономерности в размерах пакетов. Для обфусцированных прокси-серверов заполнение реализуется как часть механизма обфускации трафика. Метод выбора длины заполнения варьируется от протокола к протоколу: некоторые выбирают длину заполнения равномерно случайным образом из диапазона и добавляют к каждому пакету, в то время как другие прокси-серверы заполняют все пакеты до целевого диапазона или в соответствии с определенным распределением.

7.1.2 Генерация прокси-трафика

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

На клиентской станции мы запускаем автоматизированный сценарий для генерации прокси-трафика. Для каждой конфигурации обфусцированного прокси мы подключаемся к прокси-серверу и используем Selenium Firefox для посещения 1 тыс. лучших доменов в соответствии с рейтингом Cloudflare, собирая при этом дампы пакетов для справки. Отметим, что цель просмотра 1 тыс. доменов - сгенерировать разнообразный набор TLS-трасс на прокси. Однако эксплойт не зависит от просмотра веб-страниц - любое проксируемое приложение, использующее TLS, будет генерировать инкапсулированные TLS-рукопожатия. Мы настраиваем браузер Selenium на использование только 1.2 при согласовании версий TLS. В § 7.4 мы расширяем эксперимент, включив в него TLS 1.3, и показываем, что в данный момент в интересах цензоров сосредоточиться на TLS 1.2 из-за более высокой точности, которую предлагают отпечатки пальцев рукопожатия TLS 1.2. Для конфигураций с мультиплексированием потоков мы перезапускаем прокси-клиент между последовательными посещениями домена. В среднем этот процесс генерирует более 15 000 потоков, превышающих окно наблюдения W_o = 25 для не мультиплексированных конфигураций. Мы отмечаем, что некоторые из этих прокси-потоков могут не быть TLS и, следовательно, не содержать инкапсулированного TLS-рукопожатия, что приводит к заниженной частоте истинно положительных результатов (TPR) в нашей оценке. Однако, как показано в § 7.4, мы оцениваем, что только 0,39% потоков являются не-TLS-соединениями при проведении экспериментов со списком из 1 тыс. Cloudflare; таким образом, мы игнорируем их при сообщении TPR.

7.2 Платформа обнаружения

Наш Монитор внутри Merit принимает до 50 Гбит/с зеркального трафика, что требует выборки из-за узкого места процессора в нашей односерверной установке. Мы используем частоту дискретизации 1/8, чтобы минимизировать влияние потери пакетов, и мы производим выборку трафика на основе 4-кортежей, чтобы оба направления потока либо выбирались для анализа, либо отбрасывались вместе. Трафик на / с клиентской станции не подлежит выборке. Отметим, что, хотя национальные цензоры потенциально могут масштабировать свое развертывание, чтобы избежать выборки, недавняя работа показывает, что GFW работает с приблизительной частотой дискретизации 1/4, предположительно для экономии ресурсов и ограничения побочного ущерба.

Как показано на рисунке 5, как только зеркальный трафик поступает, он сначала обрабатывается кластером экземпляров Zeek, на которых запущен наш пользовательский сценарий. Затем мы используем синтаксические анализаторы протокола для извлечения протокола уровня приложения для каждого потока. Для потоков, которые синтаксические анализаторы не могут идентифицировать (например, полностью зашифрованные протоколы, такие как shadowsocks), мы помечаем их как Неизвестные. Поскольку все наши прокси-конфигурации имеют в качестве своих (прикладных) протоколов-оболочек либо Неизвестные, TLS, либо HTTP, мы отфильтровываем потоки с любыми другими метками, на долю которых приходится 0,89% всех потоков, превышающих окно наблюдения W_o. Затем мы извлекаем функции, включая размеры полезной нагрузки TCP и время между прибытием (IAT) первых W_o пакетов TCP, несущих данные, и передаем их в наши классификаторы. Важно отметить, что для потоков TLS мы удаляем пакеты, формирующие (оберточные) TLS-рукопожатия, перед извлечением признаков, чтобы классификаторы игнорировали «оберточный» TLS и вместо этого фокусировались только на идентификации потенциальных TLS-рукопожатий, инкапсулированных в полезной нагрузке TLS-оболочки (т. е. TLS-over-TLS).

Мы следуем процессу, описанному в § 6.3, для вывода статистических моделей. Примечательно, что наборы данных для обучения, используемые здесь, такие же, как и в § 6.1. Это подчеркивает преимущество предлагаемого эксплойта по сравнению с предыдущей работой: цензорам не нужно генерировать синтетический обучающий набор данных прокси-трафика. Вместо этого они могут моделировать инкапсулированные TLS-рукопожатия, наблюдая за реальным TLS-трафиком в своей сети. Важно уточнить, что все оценки в этом разделе проводятся на реальном и прокси-трафике, полностью отделенном от обучающих трасс. Чтобы адаптировать классификаторы для обнаружения прокси-трафика, мы изменяем отображение размеров пакетов M, чтобы отразить накладные расходы на кадрирование, вносимые прокси-протоколами. Хотя эти накладные расходы различаются в зависимости от прокси-протоколов, они, как правило, имеют небольшой размер (обычно от 20 до 60 байт) из соображений производительности. Хотя корректировка определенных накладных расходов на кадрирование для каждого прокси-протокола может привести к незначительному улучшению результатов, для целей оценки мы выбираем средний размер накладных расходов для всех прокси-протоколов, которые имеют фиксированные накладные расходы на кадрирование.

Однако для протоколов со сложными схемами случайного заполнения накладные расходы на кадрирование варьируются от пакета к пакету, что затрудняет разделение пакетов с разными семантическими значениями на основе размера. Например, XTLS-vision заполняет все пакеты в начале потока до диапазона 900–1400 байт, эффективно сводя на нет отдельные размеры пакетов как признак. Тем не менее, направления пакетов все еще могут служить признаком, хотя и менее информативным, поскольку прокси, которые мы исследуем, заполняют только полезную нагрузку от восходящих приложений и не отправляют «фиктивные» пакеты, когда отправлять нечего. Таким образом, для XTLS-vision и obfs4 мы используем сопоставление, которое группирует пакеты по их направлениям, независимо от их размеров (|L| = 1). Кроме того, мы адаптируем модель Махаланобиса, поскольку эти схемы заполнения приводят к увеличению размеров пакетов и более высокой дисперсии между потоками, что необходимо учитывать при вычислении расстояний. В частности, мы применяем процедуры заполнения, реализованные XTLS-vision и obfs4, к каждому потоку в обучающем наборе данных, как подробно описано в Приложении A.1. Затем мы выводим новые средние значения и ковариационные матрицы на основе дополненных последовательностей потоков.

7.3 Результаты и выводы

Начиная с 16 марта 2023 года мы развертываем нашу платформу обнаружения на Мониторе в течение 30 дней, чтобы оценить ее как на прокси-трафике, так и на трафике интернет-провайдера. Несмотря на выборку, Монитор по-прежнему обрабатывает более 36 терабайт трафика ежедневно, состоящего из 34 миллиардов пакетов из более чем 3,9 миллиона потоков, превышающих окно наблюдения W_o = 25. Поскольку Merit находится в стране с минимальной цензурой сетевого трафика, мы ожидаем, что подавляющее большинство трафика, наблюдаемого в Merit, не содержит трафика от обфусцированных прокси, предназначенных для обхода цензуры. По этой причине мы считаем все потоки интернет-провайдера, которые наша платформа помечает как прокси-трафик, ложноположительными, чтобы получить консервативную верхнюю границу частоты ложных срабатываний (FPR).

Мы извлекаем расстояния для каждого прокси и потока интернет-провайдера, помечая поток как «прокси», если оба расстояния падают ниже определенных пороговых значений. Мы определяем «оптимальные» пороговые значения и соответствующие им показатели истинных положительных результатов (TPR) в зависимости от устойчивости сетевого оператора к ложным срабатываниям (насколько агрессивен цензор). На рисунке 6 представлены результаты в разбивке по группам конфигураций при различных ограничениях FPR. Чтобы обеспечить контекст практичности платформы, мы выделяем область, где FPR < 0,6%, что соответствует расчетному FPR предполагаемого алгоритма, используемого GFW для блокировки полностью зашифрованных прокси. Мы подчеркиваем, что наш подход не только фиксирует большинство не мультиплексированных прокси-потоков, но также сохраняет точность, сравнимую с атаками, использующими протокол-специфичное активное зондирование, оставаясь при этом применимым к более широкому спектру прокси-серверов обхода цензуры. В таблице 3 подробно представлены результаты оценки с использованием одного набора порогов обнаружения, сгруппированных по конфигурациям. Обратите внимание, что для C3 (obfs4) мы использовали более разрешительное ограничение FPR, поскольку оно применяется только к трафику, протокол уровня приложения которого является Неизвестным, категория, к которой цензоры исторически подходили более агрессивно.

Основные обфусцированные прокси в своих стандартных конфигурациях уязвимы для снятия отпечатков пальцев на основе инкапсулированных TLS-рукопожатий. Нам удается обнаружить более 70% потоков, генерируемых любым из четырех наиболее широко используемых протоколов обфусцированных прокси-серверов, а именно vmess, shadowsocks, vless и trojan. Значимость таких показателей обнаружения усиливается, если учесть, что цензору достаточно идентифицировать один поток, чтобы заблокировать соответствующий прокси-сервер. Хотя vmess имеет встроенную схему заполнения полезной нагрузки, размер заполнения выбирается из ограниченного диапазона 0–63 байта. Хотя такая схема может быть эффективна для скрытия значений в полях заголовка запроса, таких как URL-адрес назначения, наши результаты показали, что ее недостаточно для обфускации характеристик размера и направленного трафика (инкапсулированных) TLS-рукопожатий даже от простых статистических моделей.

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

Случайное заполнение - это не последнее слово, когда дело доходит до обфускации шаблонов в последовательностях размеров пакетов. Внедрение схемы случайного заполнения часто является первым шагом, предпринимаемым разработчиками обфусцированных прокси-серверов, чтобы скрыть шаблоны в размерах пакетов. Тем не менее, мы показываем, что простые схемы случайного заполнения, выбирающие размеры заполнения из ограниченных диапазонов (например, vmess: [0, 63]), хотя и усложняют задачу, не делают обнаружение невозможным (TPR: 0,859 → 0,687 для vmess-ws-tls после заполнения). Для более агрессивных схем заполнения, например, XTLS-vision и obfs4, цензоры могут адаптировать свои статистические модели, дублируя схемы заполнения, обучая на дополненных версиях наборов данных и используя направления пакетов по размеру для классификации. Хотя это существенно увеличивает FPR (0,0544% → 0,6127%), эмпирические данные свидетельствуют о том, что мотивированный цензор может мириться с таким уровнем побочного ущерба в политически чувствительные времена.

Таблица 3: Результаты оценки. Вверху: производительность платформы обнаружения с разбивкой по конфигурациям прокси. Внизу: показатели ложных срабатываний, оцененные по трафику интернет-провайдера. Мы не включаем vmess в группу случайного заполнения, так как его схема заполнения ограничена (0–63 байта).

Таблица 3: Результаты оценки. Вверху: производительность платформы обнаружения с разбивкой по конфигурациям прокси. Внизу: показатели ложных срабатываний, оцененные по трафику интернет-провайдера. Мы не включаем vmess в группу случайного заполнения, так как его схема заполнения ограничена (0–63 байта).

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

Мультиплексирование оказывается более эффективным механизмом маскировки отпечатка инкапсулированных TLS-рукопожатий. С положительной стороны, введение мультиплексирования соединений значительно снижает скорость обнаружения, независимо от используемого базового прокси-протокола. Даже самая базовая форма мультиплексирования - объединение каждых двух потоков приложений в одном прокси-соединении - снижает TPR более чем на 70%. Интуитивно понятно, что когда TLS-рукопожатие происходит одновременно с передачей данных из другого потока, совместно использующего мультиплексированное соединение, отдельные пакеты TLS-рукопожатия, вероятно, будут чередоваться с другими пакетами данных, тем самым нарушая шаблоны размера и времени, обычно ожидаемые от не мультиплексированного TLS-рукопожатия. Мы отмечаем, что фактическое влияние мультиплексирования может быть более существенным, чем предполагают различия в TPR, поскольку через межсетевой экран цензора будет проходить значительно меньше прокси-соединений. Одно предостережение, которое следует учитывать, заключается в том, что эффективность мультиплексирования ограничена, когда существует только один поток приложений. Без пакетов из сосуществующих потоков для чередования шаблоны в последовательностях пакетов остаются уязвимыми для снятия отпечатков пальцев так же, как и не мультиплексированные потоки. Одним из направлений будущей работы может стать изучение методов генерации синтетических сосуществующих потоков, когда они не присутствуют естественным образом.

Ложные срабатывания: возможно, что некоторые из потоков, помеченных как обфусцированные прокси, на самом деле являются истинно положительными. Чтобы исследовать эту возможность, мы ищем косвенные улики, не зависящие от используемого нами отпечатка инкапсулированного TLS, чтобы подтвердить результаты нашего обнаружения. В частности, мы извлекаем 7 100 уникальных конечных точек сервера из 63 887 соединений, помеченных C1, за 30-дневный период оценки. Для каждой конечной точки мы затем проверяем количество уникальных IP-адресов клиентов (и SNI, если применимо). Интуитивно мы ожидаем, что конечные точки, на которых запущены прокси-протоколы, будут иметь меньше уникальных IP-адресов клиентов и значений SNI. Как показано на рисунке 10, хотя помеченные конечные точки действительно подключают меньше уникальных клиентов, они также, как правило, имеют больше уникальных SNI, чем в среднем. Более пристальный взгляд на WHOIS и SNI помеченных конечных точек показывает, что потоковые сервисы, игры и CDN являются одними из самых активных пользователей, что позволяет предположить, что большинство помеченных конечных точек вряд ли являются обфусцированными прокси.

7.4 TLS 1.2 против TLS 1.3

Чтобы исследовать влияние растущего внедрения TLS 1.3 на предлагаемую атаку снятия отпечатков пальцев, мы повторяем эксперимент, описанный в § 7.1.2, используя 1 тыс. доменов Cloudflare. На этот раз вместо того, чтобы принуждать браузер согласовывать TLS 1.2, мы позволяем браузеру и серверу самим выбирать предпочтительную версию протокола. Мы протестировали два классификатора, каждый из которых был специально обучен для определенной версии TLS. Для каждой версии мы проводили эксперимент пять раз, используя базовые конфигурации, и сообщали средние результаты на рисунке 7.

Мы обнаружили, что, хотя большинство ведущих доменов сами по себе поддерживают TLS 1.3, ресурсы, загружаемые на страницу (например, изображения, рекламные трекеры), могут отставать по внедрению TLS 1.3. В результате, в среднем, при посещении 1 тыс. ведущих доменов TLS 1.2, 1.3 и HTTP составляют 38,05%, 61,55% и 0,39% всех потоков TCP соответственно. Эти цифры согласуются с тем, что мы наблюдали в трафике Merit (таблица 1), и недавним отчетом о телеметрии TLS. Что касается производительности классификатора, мы наблюдаем, что, хотя классификатор TLS 1.3 предлагает относительно более высокую скорость обнаружения, это происходит за счет значительно повышенного FPR, что можно объяснить его более короткими (и, следовательно, менее специфичными) рукопожатиями. Напротив, классификатор TLS 1.2 эффективно обнаруживает большинство прокси-потоков TLS 1.2, несмотря на ограничение по доле версии, сохраняя при этом более низкий FPR, что делает его более практичным для развертывания. Как обсуждалось в § 3, умеренный TPR вряд ли станет серьезной проблемой для цензора, поскольку не мультиплексированный прокси будет генерировать сотни потоков во время типичного сеанса просмотра, и цензору нужно обнаружить только один из них. Учитывая, что TLS 1.2 по-прежнему представляет собой значительную долю интернет-трафика, мы считаем, что в данный момент оптимальной стратегией для перспективного цензора, реализующего предлагаемый эксплойт, будет нацеливание исключительно на инкапсулированные рукопожатия TLS 1.2.

8. Обсуждение и смягчение последствий

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

Будут ли цензоры использовать атаку снятия отпечатков пальцев на основе инкапсулированных TLS-рукопожатий? Наша оценка на Merit показывает, что при консервативных порогах обнаружения предлагаемая атака снятия отпечатков пальцев дает исключительно низкий FPR, требуя при этом только пассивного мониторинга и оставаясь в основном независимой от выбора протокола обхода цензуры. Кроме того, этот эксплойт нацелен на слои, инкапсулированные внутри прокси-протокола, тем самым делая его ортогональным и потенциально дополняющим атаки, нацеленные на сами прокси-протоколы, а также сетевой анализ на основе хоста. По этой причине мы считаем, что прокси, имеющие полностью зашифрованные оберточные слои, например, необработанные shadowsocks и vmess, особенно уязвимы: учитывая, что цензоры уже продемонстрировали готовность блокировать их на основе энтропии, дополнительное использование инкапсулированных TLS-рукопожатий в качестве дополнительной функции может еще больше снизить сопутствующий ущерб.

Однако отметим, что даже при частоте ложных срабатываний 1 из 2000 (§ 7.3) из-за огромного объема трафика, проходящего через национальный межсетевой экран, и низкой базовой частоты прокси-трафика обхода цензуры в дикой природе, наша атака снятия отпечатков пальцев, вероятно, все равно пометит больше легитимных соединений как проксированные, чем фактических прокси-соединений. Кроме того, национальный цензор - это не просто классификатор трафика, и развертывание новой технологии цензуры включает в себя соображения, выходящие за рамки частоты ложных срабатываний, такие как общественное мнение и эксплуатационные расходы. Таким образом, мы предостерегаем от преждевременного объявления любого из протестированных прокси-серверов «сломанным» только на основе наших выводов. Скорее, разработчики прокси должны предвидеть потенциальное использование инкапсулированных TLS-рукопожатий в качестве общего отпечатка прокси-трафика и проактивно оснащать свои инструменты механизмами смягчения последствий.

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

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

Рассмотрим обычные HTTPS по сравнению с прокси-серверами на основе TLS. В типичном HTTPS-соединении пакеты, которые сразу следуют за TLS-рукопожатием, обычно состоят только из одного кругового пути: исходящий GET и входящий ответ, сегментированный на несколько пакетов. Напротив, при доступе к HTTPS через прокси-сервер на основе TLS (т. е. TLS-over-TLS) сразу после первоначального TLS-рукопожатия следует второе (инкапсулированное) TLS-рукопожатие, что требует большего количества круговых путей и приводит к увеличению размеров пакетов из-за многократных накладных расходов на кадрирование. На рисунке 8 показано количество круговых путей и размер первого пакета после первоначального рукопожатия для обычного TLS и TLS-over-TLS. Важно отметить, что затененные области представляют собой различия, которые заполнение и мультиплексирование не могут скрыть. Теоретически цензор может объединить два простых правила фильтрации (RT < 2,5, Размер < 300), чтобы эффективно отфильтровать 82,5% легитимных и 1,5% проксированных соединений. К оставшимся соединениям можно применить более сложный анализ. Этот пример показывает, что при обфускации только с помощью заполнения и мультиплексирования трафик прокси-серверов на основе TLS всегда можно отличить от большей части подлинного HTTPS-трафика.

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

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

Обобщение на прокси на основе UDP и VPN Хотя наша работа в первую очередь сосредоточена на прокси на основе TCP, принципы, лежащие в основе нашего подхода, можно перенести на прокси на основе UDP, такие как MASQUE или vmess/shadowsocks over QUIC. Это связано с тем, что шаблоны для снятия отпечатков пальцев генерируются инкапсулированными слоями внутри полезной нагрузки прокси, а не характеристиками самого прокси-слоя. Адаптация классификаторов к этим контекстам должна учитывать такие факторы, как ненадежность UDP и потенциальное заполнение фреймов QUIC.

Наша атака снятия отпечатков пальцев основана на наличии вложенных стеков протоколов - редкость обнаружения уровня TLS внутри другого уровня TLS или уровня приложения в прямых соединениях делает это поведение идеальным отпечатком для прокси-потоков. Хотя в этой статье рассматривается одна конкретная атака, она указывает на более широкие риски для всех инструментов проксирования и туннелирования, которые полагаются на вложенные стеки протоколов. Например, аналогия на уровне 3 заключалась бы в обнаружении обфусцированных VPN-потоков путем учета инкапсулированных TCP-рукопожатий (и редкости обнаружения TCP-рукопожатий внутри другого протокола транспортного уровня).

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

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

A. Приложение

Алгоритм 1. Тест хи-квадрат над 3-граммами

• Входные данные:

  • T0, T1: обучающие наборы данных (не-TLS и TLS соответственно)
  • G: множество всех 3-грамм
  • δ: порог принятия решения
  • s: тестовый образец
  • M: отображение размера
  • f: параметр размерности

• Обучение:

  1. Для каждого класса c ∈ {0, 1}:
     • Применить отображение размера M к каждой 3-грамме в обучающем наборе Tc: Tc = [M(x) для каждого x в Tc]
  2. Вычислить вероятность Pr(c, g) каждой 3-граммы g ∈ G для каждого класса c ∈ {0, 1}:

     Pr(c, g) = (сумма по всем t ∈ Tc (Nt * Pr(t, g))) / (сумма по всем t ∈ Tc Nt)
     

     где Nt - общее количество 3-грамм в потоке t
  3. Вычислить Distinc(g) для каждой 3-граммы g ∈ G:

     Distinc(g) = (сумма по всем c ∈ {0, 1} (1 / |Tc| * сумма по всем t ∈ Tc (Pr(t, g) - Pr(c, g))^2)) / (1 / (сумма по всем c ∈ {0, 1} |Tc|) * сумма по всем c ∈ {0, 1} сумма по всем t ∈ Tc (Pr(t, g) - Pr(c, g))^2 + ε) 
     

     где |Tc| - количество элементов в Tc, ε - небольшое положительное число для предотвращения деления на ноль.
  4. Сформировать набор F из f 3-грамм с наибольшим значением Distinc(g):

     F = отсортировать(G, ключ=Distinc(g), порядок=убывающий)[0 : f]
     

• Тестирование:

  1. Применить отображение размера M к тестовому образцу s: s = M(s)
  2. Вычислить расстояние хи-квадрат D(s, c) между тестовым образцом s и каждым классом c ∈ {0, 1}:

     D(s, c) = сумма по всем g ∈ F (1 / Pr(c, g) * (Pr(s, g) - Pr(c, g))^2)
     

  3. Вернуть True, если D(s, 1) / (D(s, 0) + ε) ≥ δ, иначе вернуть False.

Алгоритм 2. Расстояние Махаланобиса над пакетами

• Входные данные:

  • T1: обучающий набор TLS
  • s: тестовый образец
  • Wb: размер окна пакета (Wb = 5 для TLS 1.2 и Wb = 3 для TLS 1.3)
  • γ: порог обнаружения

• Обучение:

  1. Извлечь первые Wb пакетов из каждого потока в обучающем наборе T1:

     T1 = [x[0 : Wb] для каждого x в T1]
     

  2. Вычислить среднее значение векторов пакетов M⃗ в T1:

     M⃗ = получитьСреднееЗначениеПакета(T1) 
     

  3. Вычислить ковариационную матрицу C векторов пакетов в T1:

     C = получитьКовариационнуюМатрицу(T1)
     

• Тестирование:

  1. Создать пустой набор Dis для хранения расстояний Махаланобиса.
  2. Для каждого i от 0 до |s| - Wb:
     • Добавить в Dis расстояние Махаланобиса между пакетом s[i : i + Wb] и распределением, определенным M⃗ и C:

       Dis.добавить(sqrt((s[i : i + Wb] - M⃗ )^T * C^-1 * (s[i : i + Wb] - M⃗ ))) 
       

  3. Вернуть True, если минимальное расстояние в Dis меньше или равно γ, иначе вернуть False.

Алгоритм 3. Схема заполнения XTLS-vision

• Входные данные: S (последовательность пакетов)
• Инициализация:
  • outgoing = 0 (количество исходящих пакетов)
  • incoming = 0 (количество входящих пакетов)
• Цикл:
  • Для каждого i от 0 до |S|:
    1. Инициализировать P (размер заполнения) равным 0.
    2. Если i < TLSEstablished (номер пакета, на котором завершается рукопожатие TLS):
       • Если размер пакета S[i] < 900:
         • Установить P = случайное число от 0 до 500 + 900 - размер пакета S[i].
       • Иначе:
         • Установить P = случайное число от 0 до 255.
    3. Иначе, если ((S[i] > 0 и outgoing < 7) или (S[i] < 0 и incoming < 7)):
       • Установить P = случайное число от 0 до 255.
    4. Обновить счетчики исходящих и входящих пакетов (outgoing и incoming).
    5. Если P > 0:
       • Добавить P к размеру пакета S[i], сохраняя знак: S[i] = sign(S[i]) * (|S[i]| + P)

Алгоритм 4. Схема заполнения obfs4

• Входные данные: S (последовательность пакетов)

• Процедура PADPACKET(size, toPadTo):

  1. Вычислить tail = остаток от деления size на 1448.
  2. Инициализировать P (размер заполнения) равным 0.
  3. Если toPadTo >= tail:
     • Установить P = toPadTo - tail.
  4. Иначе:
     • Установить P = 1448 - tail + toPadTo.
  5. Если P > 21:
     • Вернуть size + P - 21.
  6. Иначе, если P > 0:
     • Вернуть size + P + 1427.
  7. Иначе:
     • Вернуть size.

• Основная часть алгоритма:

  1. Создать два распределения для заполнения, cliDist и serverDist, с помощью функции NewDist() и случайного числа (seed). Диапазон значений для обоих распределений: (0, 1448).
  2. Разбить последовательность S на пакеты с помощью функции extractBurst().
  3. Цикл:
     • Для каждого i от 0 до |S|:
       1. Если S[i] > 0 (исходящий пакет):
          • S[i] = padPacket(S[i], cliDist.sample())
       2. Иначе (входящий пакет):
          • S[i] = -padPacket(|S[i]|, serverDist.sample())

Я постарался сделать алгоритмы максимально понятными, используя текстовое описание и псевдокод.

A.1 Схемы заполнения XTLS-vision и obfs4

В алгоритмах 3 и 4 описаны схемы заполнения, реализованные XTLS-vision и obfs4 (iat-mode=0/1). Для XTLS-vision пакеты TLS-рукопожатия заполняются до диапазона 900–1400 байт, а первые 7 пакетов, передаваемых в любом направлении, заполняются случайным размером 0–255 байт. Для obfs4 и клиент, и сервер поддерживают распределение заполнения. Для каждого пакета в последовательности потока размер заполнения определяется путем выборки из распределения отправителя.

Таблица 4: Поддержка мультиплексирования для реализаций, рассмотренных в статье.