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

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

В 2018 году исследователь безопасности Ахамед Нафиз опроверг это предположение, представив исследование атаки VORACLE (зарегистрированной как CVE-2018-3972 на конференциях Black Hat USA и DEF CON 26). VORACLE продемонстрировала, что сжатие сетевого трафика перед шифрованием создает критический побочный канал (side-channel). Измеряя колебания длины зашифрованных пакетов, находящийся на пути трафика злоумышленник способен побайтово восстанавливать конфиденциальные данные — включая сессионные cookie и токены авторизации HTTP — без взлома самих криптографических алгоритмов.

+-------------------------------------------------------------------------+
|                    УТЕЧКА ЧЕРЕЗ СЖАТИЕ В АТАКЕ VORACLE                  |
+-------------------------------------------------------------------------+
|                                                                         |
|  Атакующий внедряет кандидатов ("Cookie: auth=a...")                    |
|  в один поток с секретным токеном жертвы ("Cookie: auth=s3cr3t...")     |
|                                                                         |
|            Поток открытого текста (Секрет жертвы + Данные атакующего)   |
|                                    │                                    |
|                                    ▼                                    |
|                       [ Сжатие LZO / DEFLATE ]                          |
|                                    │                                    |
|    - Неверный символ -> Нет совпадения -> Размер пакета БОЛЬШОЙ         |
|    - Верный символ   -> Срабатывает LZ77 -> Размер пакета УМЕНЬШАЕТСЯ!  |
|                                    │                                    |
|                                    ▼                                    |
|                       [ Шифрование AES / ChaCha ]                       |
|                                    │                                    |
|                                    ▼                                    |
|    Пакет в сети (Размер шифротекста выдает степень сжатия)              |
|                                    │                                    |
|    Анализ дельты длины пакета -> Восстановление байта секрета!          |
+-------------------------------------------------------------------------+

Теория информации и физическая природа утечки

Чтобы понять механизм успешной реализации VORACLE, необходимо обратиться к математическим основам алгоритмов сжатия без потерь. Стандартные методы, такие как DEFLATE (RFC 1951) и LZO, опираются на два фундаментальных принципа: замену повторяющихся последовательностей по скользящему словарю LZ77 и префиксное кодирование Хаффмана.

В алгоритме LZ77 кодировщик последовательно сканирует входной поток байтов в поисках дубликатов. Если фрагмент данных уже встречался ранее в пределах скользящего окна истории (обычно размером 32 или 64 КБ), повторный фрагмент заменяется компактным указателем:

  1. Смещение (Distance): На сколько байтов назад расположено начало оригинальной подстроки.
  2. Длина (Length): Сколько последовательных байтов совпадают.

Если сетевой пакет содержит две одинаковые шестнадцатибайтовые строки, второе вхождение заменяется ссылкой размером всего 2–3 байта. Общий объем сжатого потока уменьшается пропорционально избыточности входного текста.

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

Потоковые шифры (ChaCha20 или AES в режиме CTR) генерируют гамму и складывают ее с открытым текстом операцией XOR в соотношении 1:1. Входной блок размером 412 байтов порождает ровно 412 байтов шифротекста (плюс тег аутентификации). Блочные шифры (AES-CBC) дополняют данные до границы 16 байтов, но уменьшение сжатого объема регулярно переходит границы блоков, раскрывая информацию о длине с шагом в 16 байтов.

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

Практический сценарий реализации атаки VORACLE

Уязвимость VORACLE затронула соединения OpenVPN с активными параметрами сжатия (comp-lzo yes или директивой compress). Атака реализуется по модели адаптивного выбранного открытого текста (adaptive chosen-plaintext attack):

1. Перехват канала передачи данных

Атакующий занимает позицию человека посередине (on-path) относительно трафика жертвы. Типичные сценарии: скомпрометированная точка доступа Wi-Fi в общественном месте, уязвимый локальный маршрутизатор или мониторинг на уровне интернет-провайдера. Поскольку трафик направляется в туннель VPN, атакующий изначально не может прочитать полезную нагрузку.

2. Внедрение контролируемого открытого текста

Жертву побуждают открыть веб-страницу, контролируемую злоумышленником, либо в незащищенный HTTP-трафик внедряется скрипт. Этот JavaScript-код начинает циклично отправлять междоменные запросы к целевому ресурсу (например, к корпоративному порталу или почтовой системе).

Поскольку запросы исходят из браузера пользователя, браузер автоматически добавляет в заголовки секретные сессионные cookie жертвы. В то же время внедренный скрипт контролирует параметры запроса (URL или тело запроса), подставляя туда тестовые строки-кандидаты в тот же поток данных.

3. Сжатие как криптографический оракул

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

Комбинированный открытый текст:
[GET /api/user?test=CANDIDATE HTTP/1.1\r\n]  <-- Контролируется атакующим
[Cookie: auth_token=7a8b9c0d1e2f3a4b\r\n]     <-- Секретный токен жертвы

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

Если символ угадан неверно, совпадения не происходит, и сжатый пакет сохраняет свой стандартный больший размер.

4. Побайтовое извлечение секрета

Атакующий отслеживает размер зашифрованных UDP- или TCP-пакетов, исходящих от устройства жертвы к шлюзу VPN. Зафиксировав уменьшение размера пакета при определенном тестовом символе, злоумышленник однозначно подтверждает правильность байта.

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

Эволюция атак: CRIME, BREACH и VORACLE

VORACLE стала логическим продолжением цепочки атак на каналы сжатия на различных уровнях сетевой модели:

Атака Год Уровень стека Целевой протокол Основной способ защиты
CRIME (RFC 7540 §10.6) 2012 Транспортный / Сеансовый Сжатие на уровне TLS Полное отключение сжатия TLS в браузерах и веб-серверах
TIME 2013 Прикладной Сжатие HTTP-ответов Случайный паддинг ответов, ограничение частоты запросов
BREACH 2013 Прикладной Тело HTTP (gzip/deflate) Маскирование динамических секретов, разделение контекстов
VORACLE (CVE-2018-3972) 2018 Сетевой / Туннельный Туннель VPN (OpenVPN LZO) Полный отказ от сжатия полезной нагрузки в конфигурациях VPN

После публикации атаки CRIME Юлиусом Риццо и Тхай Зыонгом рабочая группа IETF отреагировала кардинально: спецификация RFC 7540 (HTTP/2) официально запретила сжатие на уровне TLS.

Однако в индустрии VPN долгое время сохранялось заблуждение, что работа на сетевом уровне (Layer 3) защищает от проблем уровня приложений. VORACLE доказала обратное: совместная передача данных разного уровня доверия внутри одного туннеля со сжатием неизбежно ведет к утечке данных.

Почему WireGuard принципиально не использует сжатие

Создатель протокола WireGuard Джейсон Доненфельд сознательно исключил возможность сжатия данных из спецификации протокола.

Классические протоколы корпоративных сетей накапливали избыточный функционал: поддержку десятков устаревших шифров, динамическое согласование параметров и встроенное сжатие. Архитектура WireGuard построена на противоположных принципах: криптографическая определенность и минимизация поверхности атаки.

Отказ от сжатия в WireGuard обусловлен тремя техническими факторами:

  1. Исключение утечек по длине пакета: Без сжатия размер открытого текста строго соответствует размеру сетевого кадра. Противник лишается обратной связи для проведения атак по побочным каналам.
  2. Безопасность памяти и детерминизм: Библиотеки сжатия (zlib, LZO) содержат сложные конечные автоматы с динамическим выделением памяти. В них регулярно обнаруживались уязвимости переполнения буфера. WireGuard обрабатывает криптографические пакеты в пространстве ядра с фиксированным объемом памяти без динамических аллокаций.
  3. Стабильность вычислительной нагрузки: Сложность сжатия зависит от энтропии данных. Зашифрованный трафик (HTTPS-потоки, видео) не сжимается, заставляя процессор совершать бесполезные вычисления. Это вызывает скачки задержек и неравномерную загрузку ядер CPU.

Архитектура RiceGuard: изоляция заполнения и нулевое сжатие

Современные безопасные системы рассматривают сжатие пакетов как недопустимый фактор риска. В сервисе VPNRice фирменный сетевой стек RiceGuard исключает сжатие полезной нагрузки на стороне клиентов и серверов.

+-----------------------------------------------------------------------+
|                    БЕЗОПАСНАЯ ИНКАПСУЛЯЦИЯ В RICEGUARD                |
+-----------------------------------------------------------------------+
|  [ Исходный IP-пакет пользователя ]                                   |
|         │                                                             |
|         ▼                                                             |
|  [ ОТСУТСТВИЕ СЖАТИЯ ]       -> Защита от побочных каналов LZ77       |
|         │                                                             |
|         ▼                                                             |
|  [ Стандартизированный паддинг ] -> Округление до фиксированных сеток|
|         │                                                             |
|         ▼                                                             |
|  [ Шифрование ChaCha20-Poly1305 ] -> Аутентифицированное шифрование   |
|         │                                                             |
|         ▼                                                             |
|  [ Внешний UDP-датаграмм ]   -> Предсказуемый профиль в сети          |
+-----------------------------------------------------------------------+

Инженерные решения RiceGuard обеспечивают надежную изоляцию:

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

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

Аудит и устранение рисков в сетевой инфраструктуре

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

Проверка конфигурационных файлов OpenVPN

В файлах конфигурации сервера (server.conf) и клиента (client.ovpn) следует найти и деактивировать устаревшие параметры:

# НЕБЕЗОПАСНЫЕ ДИРЕКТИВЫ - ТРЕБУЮТ УДАЛЕНИЯ:
comp-lzo yes
comp-lzo adaptive
compress lzo
compress deflate

Для надежного устранения уязвимости VORACLE примените безопасную конфигурацию:

# БЕЗОПАСНАЯ НАСТРОЙКА:
# Для OpenVPN версии 2.4+:
compress migrate
comp-lzo no

# Для OpenVPN версии 2.5 и новее:
# Полное отключение поддержки сжатия:
compress stub-v2

Параметр comp-lzo no гарантирует, что данные не подвергаются модификации размера перед входом в криптографический модуль.

Контрольный список для системных администраторов

  1. Переход на современные протоколы: По возможности переводите инфраструктуру туннелей на WireGuard и RiceGuard, где сжатие отсутствует на уровне архитектуры.
  2. Внедрение TLS 1.3 и HSTS: Обеспечьте сквозное использование защищенных протоколов для внутренних веб-приложений, чтобы предотвратить внедрение незашифрованного выбранного текста.
  3. Контроль промежуточного оборудования: Убедитесь, что промежуточные сетевые устройства (WAN-оптимизаторы и контроллеры SD-WAN) не выполняют неконтролируемое сжатие трафика внутри туннелей.

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