Введение: Конец эпохи самоподписанных сертификатов

XTLS Reality представляет собой смену парадигмы в обходе интернет-цензуры. До его появления стандартом было использование самоподписанных сертификатов или получение бесплатных от Let’s Encrypt. Оба метода имели фатальные недостатки: самоподписанные сертификаты мгновенно детектировались по отсутствию цепочки доверия CA, а публичные сертификаты требовали владения доменом, который легко мог попасть в черный список.

Reality устраняет саму необходимость владения сертификатом. Вместо этого он использует криптографически верифицированный временный сертификат в сочетании со стеганографической аутентификацией shortId. Это позволяет серверу вести себя как легитимный веб-ресурс (например, microsoft.com) для любого внешнего наблюдателя, при этом скрытно обслуживая прокси-клиентов.

Часть 1. Как Reality устраняет необходимость в сертификатах

Уязвимость классических схем

Цензоры детектируют стандартные прокси по трем признакам:

1. Ошибка валидации CA: Сертификат не подписан доверенным центром.
2. Совпадение Issuer/Subject: В самоподписанных сертификатах эти поля идентичны.
3. Active Probing: Цензор подключается к порту и видит «странный» сертификат.

Active Probing (Активное зондирование) — это основной метод верификации подозрительных серверов в 2025 году. Механику работы государственных зондов мы разбирали здесь.

Решение Reality: Временные сертификаты с HMAC-подписью

Вместо генерации статического сертификата на диске, Reality работает исключительно в оперативной памяти, используя сложную криптографическую схему:

На стороне сервера:

1. При запуске генерируется временная пара ключей Ed25519.
2. Создается самоподписанный x509 сертификат (в памяти), который никогда не отправляется клиенту в чистом виде.
3. При подключении клиента происходит обмен ключами (ECDH).
4. Сервер вычисляет preMasterKey через HKDF-SHA256.
5. Подпись в сертификате заменяется на HMAC-SHA512(preMasterKey, ed25519_publickey).

На стороне клиента: Клиент получает этот «поддельный» сертификат, но не проверяет его через цепочку CA (что привело бы к ошибке). Вместо этого он:

1. Извлекает публичный ключ Ed25519.
2. Вычисляет HMAC с имеющимся у него preMasterKey.
3. Сравнивает полученный HMAC с подписью в сертификате. Если они совпадают, клиент знает: «Этот сервер владеет секретным ключом, о котором знаем только мы двое».

Почему это работает:

• Для клиента Reality: Сервер аутентифицирован криптографически (через HMAC), цепочка CA не нужна.
• Для цензора: Он не знает preMasterKey. При попытке проверить подпись стандартными методами (через CA) проверка провалится, но Reality для «чужаков» вообще не отдает этот сертификат (об этом ниже).

Часть 2. Механика shortId и dest: Свой среди чужих

shortId: Стеганография в SessionId

Как сервер отличает «своих» от цензора, если TLS Handshake идет открытым текстом? Ответ кроется в поле SessionId (32 байта) пакета ClientHello. Обычно там случайный мусор. Reality прячет там зашифрованный токен.

Структура SessionId:

[0-7 байт]: Открытые данные (Версия Xray, временная метка)
[8-31 байт]: AEAD-зашифрованный shortId + паддинг

Процесс:

1. Клиент шифрует свой shortId (например, a1b2c3d4) используя ключ, выведенный из ECDH-обмена.
2. Сервер пробует расшифровать вторую часть SessionId своим приватным ключом.
3. Если расшифровка успешна и shortId есть в белом списке → это клиент Reality.
4. Если расшифровка не удалась (мусор) → это обычный посетитель или цензор.

dest: Механизм маскировки (Masquerade)

Параметр dest определяет, чью личность украдет ваш сервер для «посторонних».

Логика работы:

• Сценарий 1 (Клиент Reality): Сервер распознает shortId, подменяет сертификат на временный (с HMAC) и устанавливает туннель.
• Сценарий 2 (Active Probing / Цензор): Сервер не находит валидный shortId. Вместо сброса соединения (что подозрительно), он открывает TCP-соединение к dest (например, microsoft.com:443), получает оттуда настоящий ClientHello/Certificate и просто проксирует байты между цензором и Microsoft.

Результат для цензора: Он видит валидный сертификат Microsoft, подписанный доверенным CA. Трафик выглядит абсолютно легитимно. Детектировать подвох можно только по косвенным признакам (тайминги).

Лучшие кандидаты для dest в 2025 году:

• microsoft.com: Классика. Огромный трафик, TLS 1.3.
• cloudflare.com / cdn.fastly.net: CDN-провайдеры с разнообразным трафиком.
• github.com: Хорошо подходит для VPS в дата-центрах (выглядит как CI/CD трафик).
• aws.amazon.com: Корпоративный сегмент.

Часть 3. JA4/JA4S: Новый стандарт фингерпринтинга

В 2025 году старый стандарт JA3 (MD5-хеш параметров ClientHello) окончательно устарел из-за рандомизации расширений в Chrome. Ему на смену пришел JA4.

Что такое JA4?

JA4 создает человекочитаемый отпечаток вида t13_1301_47c0c.

• t13: Протокол (TCP + TLS 1.3).
• 1301: Количество поддерживаемых шифров (после сортировки).
• 47c0c: Хеш отсортированных расширений TLS.

Ключевое отличие: JA4 сортирует параметры перед хешированием. Это значит, что трюки с «перемешиванием» расширений (Extension Randomization), которые ломали JA3, больше не работают. JA4 видит набор возможностей клиента, а не порядок их объявления.

Как это помогает DPI?

Если вы используете стандартный Go-клиент Xray без маскировки, его JA4-отпечаток будет уникальным и отличным от Chrome/Firefox. Цензор может просто заблокировать все соединения с отпечатком Go-http-client.

Если вас интересует, как согласованность стека влияет на другие протоколы (например, VLESS), смотрите обзор Архитектура протоколов 2025.

Решение: uTLS

Reality использует библиотеку uTLS для полной мимикрии. Она не просто меняет заголовки, а перестраивает весь TLS-стек (кривые, шифры, расширения, паддинг), чтобы байт-в-байт соответствовать реальному браузеру (например, Chrome 120).

Часть 4. Новые векторы атак 2025 года

Несмотря на мощь Reality, гонка вооружений продолжается.

1. Post-Handshake Analysis (Атака Aparecium)

В мае 2025 года был опубликован PoC атаки, использующей особенность TLS 1.3. После завершения рукопожатия (Finished) реальные серверы (OpenSSL/BoringSSL) отправляют сообщения NewSessionTicket для возобновления сессии. Уязвимость: Текущая реализация Reality часто не отправляет эти тикеты или не проксирует их от dest. Цензор видит успешное рукопожатие, но отсутствие тикетов — аномалия, выдающая прокси.

Решение: В новых версиях Xray ожидается внедрение механизма генерации фейковых NewSessionTicket, идентичных по длине и таймингам тикетам dest.

2. Cross-Layer RTT Fingerprinting

Это атака по времени отклика, активная в РФ с апреля 2024 года.

• T1 (TCP Handshake): Время до вашего сервера (например, 50 мс).
• T2 (TLS Application Data): Если сервер проксирует запрос к dest, добавляется задержка до dest (например, +30 мс).
• Аномалия: Если для прямого подключения к Microsoft RTT должен быть 60 мс, а через ваш прокси получается 80 мс, цензор видит разницу.

Митигация: Выбирать dest, который находится географически близко к вашему VPS, чтобы минимизировать добавочную задержку (T2).