Понимание недостатков Wehe при обнаружении HTTPS-трафика

Авторы: (1) Винод С. Кхандкар и Манджеш К. Ханавал, Индийский технологический институт промышленной инженерии и исследований в эксплуатации, Бомбей, Мумбаи, Индия, и {vinod.khandkar, mhanawal}@iitb.ac.in. Таблица ссылок Аннотация и введение Сопутствующая работа и предыстория Проблемы при разработке измерительной установки для обнаружения TD Практический пример: Wehe — инструмент обнаружения TD для мобильной среды Недостаток Wehe в HTTPS-трафике TD-обнаружение HTTPS-трафика Заключение и ссылки V. НЕДОСТАТКИ WEHE ПО HTTPS-ТРАФИКУ Наше исследование сосредоточено на проверке реакции сети на воспроизводимые потоки трафика, обнаружении TD и осуществимости эксплуатации в различных сетевых конфигурациях. В то время как эксплуатационная осуществимость проверяется с помощью общедоступного приложения для Android «Wehe» в Google Playstore, сценарии обнаружения TD проверяются с использованием теоретических аргументов. Проверка ответов сети требует анализа пропускной способности полученного потока трафика. Для этого анализа требуются сетевые журналы для конкретного воспроизведения, выполненного в соответствии со сценарием проверки. Повтор, выполненный на устройстве, и несколько других потоковых трансляций. Рис. 6. Классификация повторного YouTube-трафика параллельно работающие службы являются одним из таких сценариев. Приложение Wehe не предоставляет такие сетевые журналы для повторов сразу после завершения тестов. Итак, мы реализовали пользователь-клиент и сервер, имитирующие поведение инструмента Wehe. Мы используем настройку клиент-сервер, аналогичную настройке, показанной на рис. 3, для проверки Wehe. В текущей настройке мы заменили исходный сервер службы сервером воспроизведения. Пользовательский клиент и сервер повторов соединены через формирователь коммерческого трафика. Более того, в нашей установке предусмотрена возможность параллельного выполнения нескольких повторов. Наша установка проверки не требует административных каналов и накладных расходов, например побочных каналов. Нашему серверу всегда необходимо поддерживать однопользовательского клиента. При проверке сценариев с несколькими клиентами напрямую используется приложение Wehe, поскольку не требуется связанный анализ трафика. Напоминание: в этом разделе описаны результаты проверки. A. Эмуляция трафика оригинальной службы Ответы сети зависят от применения сетевых политик, основанных на правильной классификации зондирующего трафика сетевыми промежуточными блоками, как указано в Разделе III-A. Мы проверили классификацию эмулируемого трафика Wehe с помощью коммерческого формирователя трафика. Классификация эмулируемого трафика осуществляется с помощью пользовательского интерфейса формирователя коммерческого трафика. Для проведения эксперимента данные приложения YouTube воспроизводятся с сервера воспроизведения на клиент-пользователь через формирователь коммерческого трафика. Во время передачи данных в окне пользовательского интерфейса формирователя коммерческого трафика отслеживается наличие трафика YouTube. Мы также получили доступ к трафику YouTube с помощью интернет-браузера и наблюдали за результатами классификации формирователя трафика, чтобы составить основу для наших наблюдений за классификацией трафика. На рис. 6 показан результат классификации трафика, показанный в окне пользовательского интерфейса формирователя коммерческого трафика для трафика, доступ к которому осуществляется напрямую с помощью интернет-браузера с сервера YouTube. Он показывает интернет-активность в левом окне и классификацию соответствующего трафика в правом окне. На рис. 6(a) показано, что трафик, доступ к которому осуществляется с помощью интернет-браузера, правильно классифицируется как YouTube. Это соответствует предполагаемому поведению формирователя коммерческого трафика. На рис. 6(b) показан результат классификации трафика, доступ к которому осуществляется с использованием пользовательского клиента. Это свидетельствует о том, что трафик YouTube не передается по каналу связи. Более того, он классифицирует тот же трафик как трафик HTTPS. Результаты этого эксперимента показывают, что не все сетевые промежуточные устройства могут правильно классифицировать воспроизводимый трафик Wehe. B. Влияние скорости передачи данных в сценарии воспроизведения Генерация зондирующего трафика влияет на ответ сети, как и ожидалось алгоритмом обнаружения TD. Wehe использует трассировку трафика из исходной службы для создания сценариев воспроизведения, которые сохраняют данные приложения и их временные соотношения. Этот сценарий воспроизведения используется в исходной сети, а также в сетях с другим географическим расположением. Поскольку скорость формирования трафика варьируется в разных сетях для одной и той же услуги (как указано в [32]), скорость трафика, сохраняемая в сценарии воспроизведения, может отличаться от скорости формирования трафика рассматриваемой в данный момент сети. Скорость повторного трафика может быть ниже скорости формирования трафика. Методика Wehe не обнаруживает дифференциацию трафика, если скорость трафика сценария воспроизведения ниже скорости формирования сети, поскольку это не влияет на поток трафика. Такие сценарии воспроизведения никогда не смогут обнаружить формирование трафика в таких сетях. Таким образом, возможности обнаружения TD инструмента Wehe ограничены скоростью зондирующего трафика сценария воспроизведения. C. Использование порта № 80. Реакция сети определяется восприятием сетевыми промежуточными блоками зондирующего трафика (см. раздел III-A). Сценарий воспроизведения сохраняет данные в исходной трассировке сети приложения. Исходные серверы приложений используют порт 80 для передачи данных в виде обычного текста и порт 443 для передачи зашифрованных данных. Сценарий воспроизведения Wehe напрямую использует зашифрованные данные из трассировки сети приложения и передает их через порт 80. В таких случаях Wehe ожидает, что исходный поток трафика воспроизведения будет правильно классифицирован сетевыми устройствами, использующими зашифрованные данные приложения. Это невозможно для таких данных на порту 80, поскольку зашифрованные данные трафика не могут раскрыть свою идентификацию сетевому устройству. Таким образом, инструмент Wehe не может генерировать необходимые потоки трафика для служб, работающих на порту номер 443, из-за использования по умолчанию порта 80 для запуска воспроизведения. D. Поведение сети, зависящее от трафиковой нагрузки Обратите внимание, что нехватка ресурсов побуждает сети применять определенные методы управления сетевым трафиком, особенно в сценариях высокой сетевой нагрузки, которые полезны для всех активных услуг в сети, например, управление трафиком на основе QoS (см. раздел III-A). Мы проверили эффект от такого управления трафиком Рис. 7. Влияние нагрузки на сеть на производительность потока трафика Wehe на выступлениях как контрольных, так и оригинальных повторов. При проверке используются следующие три сценария проверки: • Воспроизведение только двух потоков трафика Wehe без какой-либо нагрузки на сеть (рис. 7(а)) • Воспроизведение трех потоков трафика Wehe с параллельной работой одного дополнительного потокового сервиса (рис. 7(b)) • Воспроизведение трех потоков трафика Wehe с двумя дополнительными потоковыми сервисами, работающими параллельно (рис. 7(c)) Характеристики на рис. 7(a) показывают, что производительность потоков трафика, генерируемых инструментом Wehe, одинакова при отсутствии дополнительных условий нагрузки на сеть. По мере увеличения нагрузки на сеть производительность управляющего воспроизведения отклоняется от производительности исходного воспроизведения и находится на более высоком уровне (рис. 7 (б)). Хотя качество контрольного воспроизведения еще больше отклоняется от исходного воспроизведения на нижней стороне, два исходных повтора по-прежнему демонстрируют схожие характеристики, как показано на рис. 7 (c). Это сводит на нет ожидание инструмента Wehe о том, что воспроизведение управления не будет дифференцировано. Это также делает недействительными требования к средству обнаружения TD из-за общей пропускной способности. E. Wehe тестирует с нескольких устройств в одной подсети. Боковые каналы введены в конструкцию Wehe для одновременной поддержки нескольких пользовательских клиентов. Боковые каналы также помогают определить соответствие между пользователем-клиентом и комбинацией IP-адресов и портов. Это полезно в случае сетей, использующих NAT [33]. Мы проверили поддержку Wehe для нескольких клиентов и сетей с поддержкой NAT, используя два разных теста. Сначала мы подключили двух пользователей-клиентов из одной подсети, то есть клиентов, использующих один и тот же общедоступный IP-адрес. В ходе одного теста инструмент Wehe тестирует одну и ту же службу на обоих устройствах, например, приложение Wehe на обоих устройствах тестирует YouTube. Результат показывает, что тест Wehe завершился только на одном устройстве, а приложение Wehe внезапно закрылось на другом устройстве. Мы повторили тот же сценарий, но на этот раз Wehe тестирует разные сервисы, например, Wehe на одном устройстве тестирует YouTube, а на другом тестирует Netflix. Мы обнаружили, что тест Wehe на одном устройстве завершается правильно, в то время как тест Wehe на другом устройстве выдает на экран ошибку, информируя пользователя о том, что другой клиент уже выполняет тест, как показано на рис. 9. Эти тесты показывают, что Wehe выполняет тест. не поддерживать несколько устройств, если они имеют один и тот же IP-адрес. Хотя побочный канал полезен для идентификации каждого повтора от пользователя-клиента, подключенного непосредственно к серверу воспроизведения Wehe, он бесполезен в сети, использующей устройства NAT. Несколько пользователей используют один и тот же IP-адрес в случае NAT. В таких случаях побочный канал не может однозначно сопоставить каждый запуск повтора клиенту. Это ограничивает использование Wehe только одним активным клиентом на каждый сервер воспроизведения, интернет-провайдера и приложение. Это ограничение также задокументировано разработчиками Wehe. F. Влияние сетевой нагрузки устройства на обнаружение ТД Сервер воспроизведения Wehe использует те же временные интервалы между передачей данных приложения, что и исходный трафик приложения. Ожидается, что такая стратегия передачи не будет исчерпать доступную полосу пропускания. Следовательно, эффект модуляции скорости источника из-за превышения скорости трафика над доступной полосой пропускания маловероятен. Благодаря этому исходные и контрольные повторы демонстрируют схожие характеристики трафика, если только они не были намеренно изменены сетевой политикой, например TD. Тем не менее, это ожидание не всегда оправдывается, поскольку скорость передачи данных модулируется сетевой нагрузкой на пользовательском устройстве во время выполнения тестов Wehe. Такие возмущения создают несоответствие, поскольку влияние изменяющейся во времени текущей сетевой нагрузки на зондирующий трафик также меняется во времени и не всегда может быть одинаковым. Стратегия последовательного воспроизведения Wehe гарантирует, что текущая нагрузка сети по-разному влияет на оба потока трафика (исходное и контрольное воспроизведение). При такой сетевой нагрузке на стороне устройства понятие услуг, не исчерпывающих доступную полосу пропускания, перестает существовать вместе с ее преимуществами для обнаружения TD. Перед обнаружением TD необходимо нормализовать такие мешающие факторы (см. раздел III-B). Этот документ под лицензией CC 4.0. доступен на arxiv