HTTP/3 QPACK Dynamic Table State as a Session Linker: Как состояние сжатия заголовков связывает сессии даже при смене Connection ID

[BadB]

Как состояние сжатия заголовков в QPACK может связывать сессии даже при смене Connection ID.

Введение: Невидимая нить в QUIC​

Ты думаешь, что сменил IP, обновил TLS-фингерпринт, сбросил куки и даже изменил QUIC Connection ID — и теперь ты «чист»?
Подумай ещё раз.

В HTTP/3 скрыта невидимая нить, которая связывает твои сессии на уровне протокола, глубже, чем JavaScript или даже TLS. Это — состояние динамической таблицы QPACK.

Большинство кардеров не знают о её существовании. Те, кто знает, считают её «внутренней оптимизацией». Но на самом деле QPACK — это механизм скрытой идентификации, который делает бесполезной смену Connection ID, если ты не управляешь состоянием сжатия правильно.

В этой статье мы разберём, как QPACK работает, почему он связывает сессии, и какие ошибки убивают вбивы на старте.

Часть 1: Что такое QPACK и зачем он нужен​

HTTP/3 работает поверх QUIC — транспортного протокола, построенного на UDP. Чтобы ускорить передачу заголовков, HTTP/3 использует QPACK — механизм сжатия, основанный на HPACK (из HTTP/2), но адаптированный под особенности QUIC.

QPACK использует две таблицы:

1. Статическая таблица — предопределённые пары (например, :method: GET).
2. Динамическая таблица — заполняется в реальном времени новыми заголовками (например, user-agent, x-client-id).

Ключевой момент: динамическая таблица сохраняется между запросами в рамках одной HTTP/3-сессии. И здесь начинается проблема.

Часть 2: Как QPACK связывает сессии даже при смене Connection ID​

Connection ID ≠ Сессия​

QUIC позволяет менять Connection ID без разрыва соединения — это нужно для roaming (перехода между Wi-Fi и мобильной сетью). Многие кардеры думают: «Сменил CID — начал новую сессию».
Это иллюзия.

Потому что QPACK-таблица привязана не к CID, а к внутреннему состоянию HTTP/3-потока. Пока TCP-подобное соединение (в QUIC это «connection context») не закрыто, динамическая таблица сохраняется.

Сценарий провала​

1. Ты заходишь на target.com с IP A → отправляешь User-Agent: Chrome/125.
2. QPACK добавляет этот заголовок в динамическую таблицу под индексом 64.
3. Ты меняешь прокси, обновляешь CID, но не закрываешь QUIC-соединение.
4. При следующем запросе ты отправляешь заголовок как Literal Header Field with Index 64.
5. Сервер видит: «Этот клиент уже знает, что индекс 64 = User-Agent».
   → Сессия связана, несмотря на новый IP и CID.

Реальный кейс:
Кардер использовал residential proxy с ротацией IP каждые 5 минут.
Все операции на Razer Gold были связаны через QPACK — и заблокированы как «повторяющийся фрод».

Часть 3: Различия в реализации между браузерами​

Не все браузеры ведут себя одинаково — и это можно использовать.

Браузер	Поведение QPACK
Chrome	Сохраняет динамическую таблицу до полного закрытия вкладки. Даже при смене прокси — таблица жива.
Firefox	Очищает таблицу при изменении origin (например, переход с google.com на razer.com).
Safari	Использует ограниченный размер таблицы (64 записи) и агрессивно очищает старые записи.

Практическое следствие:
Если ты имитируешь Chrome, но твоя QPACK-таблица «очищается» при смене домена — тебя помечают как Firefox или поддельный профиль.

Часть 4: Три фатальные ошибки кардеров (и как их исправить)​

Ошибка №1: «Я сменил CID — я чист»​

Проблема:
Кардеры полагаются на смену QUIC Connection ID как на «hard reset», но HTTP/3-сессия остаётся той же.

Исправление:

• Полностью закрывай HTTP/3-соединение между операциями:
  • В антидетект-браузере: перезапускай профиль (не просто вкладку!),
  • Или используй разные профили для каждой сессии.
• Убедись, что TLS-сессия также не переиспользуется (session resumption = off).

Ошибка №2: Игнорирование порядка заголовков​

Проблема:
QPACK не только хранит заголовки, но и порядок их добавления. Если в первой сессии ты отправил User-Agent → Accept-Language, а во второй — наоборот, сервер заметит расхождение.

Исправление:

• Используй фиксированный порядок заголовков во всех сессиях,
• В Dolphin Anty / Multilogin: включи опцию «Preserve header order»,
• Не позволяй расширениям или скриптам модифицировать заголовки.

Ошибка №3: Отсутствие валидации QPACK-состояния​

Проблема:
Кардеры не проверяют, что их профиль действительно начинает с «чистой» QPACK-таблицы.

Исправление:

• Используй Wireshark + qlog для анализа HTTP/3-трафика:
  1. Запусти захват с фильтром quic,
  2. Найди фреймы HEADERS,
  3. Проверь, используются ли Indexed Header Fields (индексы > 61 = динамическая таблица).
• Если в первой сессии после старта есть индексы >61 — твой профиль не чист.

Часть 5: Практический чек-лист для кардера​

Шаг	Действие
1. Изоляция сессий	Каждый вбив — новый профиль (не вкладка!)
2. Отключение session resumption	В настройках прокси/TLS — отключи reuse
3. Фиксированный порядок заголовков	Настрой вручную, не полагайся на браузер
4. Валидация через Wireshark	Убедись, что первые заголовки — Literal, не Indexed
5. Имитация целевого браузера	Chrome = долгоживущая таблица; Firefox = очистка по origin

Заключение: Скрытая память протокола​

QPACK — это не просто оптимизация. Это скрытая память HTTP/3, которая помнит тебя даже тогда, когда ты думаешь, что стёр все следы.

Те, кто игнорирует состояние динамической таблицы, обречены на связывание сессий.
Те же, кто управляет ею — получают преимущество: их профили выглядят как абсолютно новые, даже при повторных заходах.

Помни: в 2026 году безопасность — это не смена IP. Это контроль над каждым байтом протокола.

Удачи в кардинге.