Reality против обычного TLS: в чём разница
Reality — не «ещё один протокол шифрования», а другой подход к самой процедуре установления соединения. Разница с обычным TLS кроется не в шифре, а в том, что видит наблюдатель на пути пакета: почти одинаковый TLS-хендшейк снаружи скрывает совершенно разную архитектуру доверия внутри. Разбираемся, что именно отличается технически — и почему это влияет на стабильность личного сервера в реальных условиях.
Как устроен обычный TLS-хендшейк
Классическое TLS-соединение начинается с ClientHello — клиент называет сервер по имени (поле SNI, Server Name Indication), предлагает набор шифров и версию протокола. Сервер отвечает сертификатом, который выпущен удостоверяющим центром (CA) на конкретное доменное имя. Клиент проверяет цепочку доверия: сертификат подписан известным CA, имя в сертификате совпадает с SNI, срок действия не истёк.
Проблема в том, что вся эта цепочка полностью видна снаружи, если не считать сам контент трафика. SNI передаётся в открытом виде (если не используется ECH — Encrypted Client Hello, которая пока поддерживается не везде), сертификат сервера тоже пересылается открытым текстом при хендшейке. Наблюдатель на сети видит: к какому домену идёт обращение, какой у сервера сертификат, какова его цепочка выпуска. Это стандартное поведение — TLS проектировался для защиты содержимого, а не метаданных самого соединения.
Что меняет Reality в этой схеме
Reality убирает из уравнения главный демаскирующий элемент — собственный TLS-сертификат сервера. Вместо того чтобы предъявлять клиенту сертификат, который однозначно принадлежит инфраструктуре личного сервера, Reality на этапе хендшейка «занимает» сертификат и TLS-параметры настоящего стороннего сайта — например, крупного публичного ресурса с хорошей репутацией. Технически это называется TLS-маскировкой через проксирование хендшейка к сайту-донору: сервер QQ NET подключается к целевому домену, получает от него реальный, валидный, честно выпущенный сертификат и транслирует его клиенту.
В результате для любого внешнего наблюдателя, включая DPI-системы, которые анализируют паттерны TLS, соединение выглядит как обращение к обычному публичному сайту с легитимным сертификатом от известного CA. У Reality нет собственного сертификата, который можно было бы занести в список и опознавать в дальнейшем — потому что сервер использует чужой, настоящий сертификат в реальном времени, а не подделывает его. Дополнительно Reality использует короткоживущие ключи и приватную схему аутентификации клиента на основе X25519 — то есть сервер отличает «своего» клиента от случайного постороннего запроса на этот же порт ещё до завершения TLS-хендшейка, без дополнительного заметного трафика.
Технические отличия по пунктам
Если сопоставлять напрямую, разница сводится к нескольким конкретным техническим узлам хендшейка и инфраструктуры сертификатов.
- Сертификат: обычный TLS — сервер предъявляет собственный сертификат на свой домен; Reality — транслирует настоящий сертификат стороннего сайта, собственного сертификата у сервера нет вовсе
- Идентификация сервера: обычный TLS — по SNI и цепочке CA видно, что это за инфраструктура; Reality — со стороны видно только домен-донор, реальный адрес личного сервера не раскрывается на уровне хендшейка
- Аутентификация клиента: обычный TLS — происходит уже поверх установленного шифрованного канала; Reality — встроенная проверка на основе публичных ключей происходит на этапе самого хендшейка
- Устойчивость к активному зондированию: обычный самоподписанный TLS легко выявляется попыткой подключиться напрямую и проверить сертификат; Reality на такой запрос отвечает так же, как ответил бы настоящий сайт-донор — переадресует его туда
- Издержки на инфраструктуру: обычный TLS требует выпуска и продления сертификата через CA (Let's Encrypt и подобные); Reality не нуждается в собственном сертификате на сервере вовсе
Что это даёт на практике
Для пользователя личного сервера эти различия конвертируются не в абстрактную «защищённость», а во вполне измеримые вещи. Во-первых, стабильность: соединение, которое по внешним признакам неотличимо от обращения к обычному популярному сайту, реже становится объектом избирательного throttling на уровне сетевого оборудования оператора — просто потому, что его не за что зацепить как «особый» трафик.
Во-вторых, скорость подключения: Reality не требует дополнительных прослоек вроде WebSocket поверх TLS или CDN-проксирования — хендшейк остаётся близким к нативному TLS 1.3, что снижает задержку установления сессии по сравнению с более «обёрнутыми» схемами.
В QQ NET протокол Reality — один из основных вариантов подключения наряду с VLESS, Shadowsocks и Hysteria2. Клиенты HAPP, v2rayTun и Streisand поддерживают Reality из коробки: конфигурация приходит на email после оформления и оплаты через СБП, CryptoBot или Telegram Stars, а приложение импортирует профиль автоматически — вручную прописывать параметры хендшейка не требуется.
Полезно знать. Если приложение позволяет выбрать протокол вручную, для нестабильных мобильных сетей чаще выигрывает связка VLESS+Reality — за счёт минимальных издержек на хендшейк она быстрее восстанавливает соединение после переключения между Wi-Fi и мобильным интернетом.