NodeNanny

---
title: "Углублённая теория сетей и криптографии: TLS, AEAD и снятие отпечатков трафика"
summary: Продолжение protocols-overview.md, объясняющее «почему» — что стоит за TLS-рукопожатием, шифрованием AEAD и снятием отпечатков трафика при DPI; материал теоретический и сравнительно медленно устаревает
order: 2
updated: 2026-07-28
tags: [tls, шифрование, dpi, теория]
---


> Эта статья — продолжение protocols-overview.md, посвящённое вопросу «почему»: конкретно тому, как DPI на самом деле распознаёт трафик и откуда берётся устойчивость к обнаружению у разных протоколов. Содержание носит скорее теоретический характер и представляет собой сравнительно стабильные базовые знания — его достоверность устаревает не так быстро, как конкретный список протоколов или цифры детектируемости.

## Что примерно делает TLS-рукопожатие

Заходите ли вы на обычный сайт или используете прокси-протокол «под TLS», такой как Reality/AnyTLS, TLS-рукопожатие решает одну и ту же задачу: **как незнакомые друг с другом клиент и сервер могут по небезопасной сети договориться о ключе шифрования, известном только им двоим, одновременно проверив личность друг друга**. Упрощённый порядок действий:

1. Клиент отправляет ClientHello, включающий список поддерживаемых наборов шифров, случайное число и домен, к которому он хочет подключиться (поле SNI — этот шаг передаётся открытым текстом и был одной из ключевых точек, по которым ранняя GFW блокировала по домену)
2. Сервер отвечает ServerHello, выбирает набор шифров, предъявляет сертификат для подтверждения своей личности и также добавляет случайное число
3. На основе этих двух случайных чисел и алгоритма обмена ключами (сейчас в основном используется ECDHE) обе стороны независимо друг от друга вычисляют один и тот же сеансовый ключ, при этом сам ключ ни разу не передаётся по сети
4. Все последующие данные приложения передаются в зашифрованном виде с использованием этого сеансового ключа

Суть протокола Reality заключается в том, чтобы «позаимствовать» TLS-сертификат и характеристики рукопожатия реального сайта, чтобы при активном зондировании со стороны GFW наблюдаемая картина была неотличима от обращения к этому реальному сайту. AnyTLS вместо этого упаковывает произвольный прокси-трафик в стандартный слой записей TLS — концептуально та же категория «маскировки», только с иными деталями реализации.

## Что конкретно защищает шифрование AEAD

Современные основные прокси-протоколы (VMess, Shadowsocks-2022, слой данных Trojan и др.) используют шифрование класса AEAD (Authenticated Encryption with Associated Data), обычно AES-GCM или ChaCha20-Poly1305. AEAD одновременно решает две задачи:

- **Конфиденциальность**: после шифрования содержимое невозможно прочитать без ключа
- **Целостность/подлинность**: каждый сегмент шифротекста несёт тег аутентификации, позволяющий получателю проверить, что эти данные «действительно были созданы стороной, владеющей правильным ключом, и не были изменены по пути» — если при активном зондировании GFW отправляет поддельные/изменённые данные, проверка AEAD не проходит, и соединение немедленно разрывается. Это же служит естественным препятствием для самого метода атаки «активное зондирование».

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

## Как именно DPI «видит», что это прокси-трафик

При условии, что сам трафик уже зашифрован и его содержимое нельзя прочитать напрямую, DPI в основном опирается на статистические характеристики, а не на само содержимое. Распространённые измерения анализа включают:

- **Распределение длины пакетов**: у пакетов рукопожатия и управляющих пакетов разных протоколов зачастую есть закономерности размера; шифрование не может полностью скрыть эту закономерность, если протокол сам не применяет активное дополнение (padding) длины
- **Характеристики временных интервалов**: ритм отправки heartbeat/keep-alive-пакетов у прокси-ПО отличается от поведения обычного браузера
- **Анализ энтропии**: энтропия по-настоящему случайных зашифрованных данных близка к теоретическому максимуму, а если шифротекст какого-то протокола демонстрирует неслучайный, фиксированный паттерн в определённых позициях байтов (недостаток раннего дизайна протокола), это можно выявить статистически
- **Сопоставление характеристик первого/первых нескольких пакетов**: у многих протоколов в первых нескольких пакетах установления соединения есть фиксированная структура (даже если содержимое зашифровано, паттерн длины и порядка может оставаться неизменным)
- **Активное зондирование**: при подозрении, что определённый IP запускает прокси-сервис, к нему напрямую подключаются и смотрят, как сервер отвечает — если способ ответа отличается от обычного HTTPS-сайта (например, иначе происходит сбой рукопожатия, иначе реагирует на некорректные запросы), это может быть помечено как подозрительное

Понимание этого уровня объясняет механизм, стоящий за выводом из protocols-overview.md о том, «почему протоколы, маскирующиеся под TLS, более устойчивы к обнаружению»: цель протоколов вроде Reality/AnyTLS — сделать все перечисленные выше измерения (длина пакетов, структура рукопожатия, реакция на активное зондирование) максимально похожими на реальный сайт, а не просто выполнить шифрование. **Шифрование решает вопрос «читаемо ли содержимое», а устойчивость к снятию отпечатков решает вопрос «выглядит ли поведенческий паттерн подозрительным» — это два разных уровня проблемы, и то, что протокол хорошо справляется с шифрованием, ещё не значит, что он устойчив к распознаванию по отпечаткам.**

## Почему этот материал сравнительно медленно устаревает

Порядок TLS-рукопожатия, цели дизайна AEAD и тот факт, что DPI опирается на статистические характеристики, а не на содержимое — это сравнительно стабильные базовые факты на уровне криптографии и сетевых протоколов, которые вряд ли устареют целиком из-за какого-то одного технического обновления в краткосрочной перспективе. То, что действительно меняется и нуждается в периодическом пересмотре, — это выводы прикладного уровня, такие как «какой конкретно протокол сейчас лучше или хуже устойчив к обнаружению» или «конкретные цифры детектируемости у GFW» — за этим стоит обращаться к protocols-overview.md, а не к этой статье.