TLS: как устроено защищённое соединение

Проект ЦИТадель

TLS защищает HTTPS, многие API, почтовые и другие прикладные протоколы. Обычно его настройка сводится к сертификату и нескольким параметрам сервера, но за этой настройкой стоят разные задачи: согласовать ключи, проверить имя узла и затем защитить поток данных. В статье разберём эти задачи по отдельности, пройдём рукопожатие TLS 1.3 и границы его гарантий, а в практикуме проверим живое соединение с помощью openssl.

1. Что именно обещает TLS

При правильной проверке сертификата и имени TLS создаёт поверх транспорта канал со следующими свойствами:

• конфиденциальность — наблюдатель не видит содержимое записей, хотя видит IP-адреса, время и объём передачи, а без ECH обычно и имя сервера;
• целостность и порядок — изменение, повтор или перестановка защищённых записей обнаруживаются;
• аутентичность сервера — клиент проверяет, что открытый ключ связан с нужным именем; аутентификация клиента необязательна и может быть добавлена с помощью mTLS.

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

2. Криптографические компоненты

TLS 1.3 комбинирует несколько примитивов; их устройство и постквантовая стойкость подробнее разобраны в главах 12–14 курса о квантовых вычислениях.

• Аутентифицированное симметричное шифрование (AEAD: AES-GCM или ChaCha20-Poly1305) защищает содержимое и целостность записей с помощью сеансовых ключей.
• Установление общего секрета в обычном полном рукопожатии выполняет эфемерный обмен (EC)DHE, часто X25519. Постквантовый гибрид добавляет к нему ML-KEM; это рассматривается в разделе 7.
• Цифровая подпись (например, RSA-PSS, ECDSA или Ed25519) связывает диалог рукопожатия с закрытым ключом сервера.
• HKDF выводит из общего секрета отдельные ключи для разных стадий и направлений передачи.

Асимметрические операции нужны в рукопожатии, а основной объём данных защищает более быстрое симметричное шифрование. В TLS 1.3 шифронабор определяет AEAD и хеш, но не алгоритмы подписи и обмена ключами: они согласуются отдельно.

3. Рукопожатие TLS 1.3 по шагам

TLS 1.3 был опубликован в 2018 году, а в 2026 году его спецификацию обновил RFC 9846. По сравнению с TLS 1.2 из полного рукопожатия удалены статический RSA-обмен и многие устаревшие варианты, а данные приложения можно начать передавать после одного сетевого круга.

1. ClientHello. Клиент сообщает поддерживаемые версии, шифронаборы, группы, алгоритмы подписи и протокол приложения через ALPN. Обычно он сразу посылает key_share для одной или нескольких ожидаемых групп. Если подходящей доли нет, сервер отвечает HelloRetryRequest, и рукопожатие требует дополнительного круга.
2. ServerHello. Сервер выбирает параметры и возвращает свою долю ключа. После этого обе стороны вычисляют общий секрет и выводят ключи рукопожатия; последующие сообщения, включая сертификат, уже зашифрованы.
3. EncryptedExtensions, Certificate, CertificateVerify. Сервер сообщает согласованные расширения и цепочку сертификатов, затем подписывает хеш предшествующего диалога с заданным контекстом. Клиент проверяет подпись, цепочку, срок действия и соответствие имени.
4. Finished. Сервер, а затем клиент посылают имитозащищённое подтверждение всего диалога. Несовпадение транскрипта или ключей завершает соединение. После проверки Finished стороны переходят к данным приложения.

TLS 1.2 обычно требовал для полного рукопожатия два сетевых круга и допускал статический RSA-обмен: клиент шифровал предварительный секрет долговременным открытым ключом сервера. В TLS 1.3 такого режима нет. Защита от отката версии использует специальную метку в случайном значении ServerHello: клиент TLS 1.3 обнаружит, что соединение подозрительно сведено к старой версии.

Возобновление и 0-RTT. Сервер может выдать билет сессии, а клиент — использовать связанный с ним предварительно согласованный ключ (PSK) в следующем соединении. Режим 0-RTT позволяет отправить ранние данные уже с первым ClientHello, но TLS не гарантирует их защиту от повторного воспроизведения и не даёт им полной прямой секретности. «Идемпотентный» не всегда значит «безопасный для повтора»: даже GET может менять состояние или расходовать ограниченный ресурс. Прикладной профиль должен явно определить допустимые ранние сообщения, а сервер — ограничивать повторы; для HTTP это описывает RFC 8470.

4. Прямая секретность

В полном рукопожатии с сертификатом TLS 1.3 использует эфемерный обмен: временные закрытые значения создаются для соединения и после него удаляются. Поэтому последующая компрометация ключа сертификата сама по себе не раскрывает ранее записанный трафик. У статического RSA-обмена в TLS 1.2 такого свойства не было: получив долговременный закрытый ключ, противник мог расшифровать сохранённые рукопожатия.

У возобновления есть важная оговорка. Режим psk_dhe_ke добавляет новый эфемерный обмен и сохраняет прямую секретность для обычных данных соединения даже при последующей компрометации PSK. Режим psk_ke полагается только на PSK и такой защиты не даёт. Ранние данные 0-RTT в любом случае выводятся до нового обмена и полной прямой секретности не имеют. Поэтому билеты и серверные ключи их защиты ограничивают по сроку, ротируют, а 0-RTT включают только после анализа повторов; компрометация ключа билетов не является универсальным способом расшифровать корректно установленную сессию psk_dhe_ke.

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

5. Сертификаты и доверие

Подпись в CertificateVerify доказывает владение закрытым ключом. Связь этого ключа с именем сервера в публичном вебе обычно проверяет инфраструктура открытых ключей (Web PKI):

• Цепочка сертификатов. Сертификат сервера подписан промежуточным удостоверяющим центром (УЦ), тот ведёт к корню из хранилища доверия клиента. Клиент проверяет подписи, ограничения сертификатов, сроки и имя из Subject Alternative Name. Предъявленная сервером цепочка сама по себе ещё не является доказательством доверия.
• Выдача. Распространённые сертификаты с проверкой домена подтверждают контроль над именем, например с помощью ACME-запроса через HTTP или DNS. Это не удостоверение личности владельца сайта. Автоматизация выпуска и замены обязательна на практике: с 15 марта 2026 года максимальный срок публично доверенного конечного TLS-сертификата составляет 200 дней, а принятая дорожная карта сокращает его до 47 дней в 2029 году.
• Certificate Transparency. Политики основных браузерных программ требуют регистрировать публично доверенные сертификаты в доступных для аудита журналах и предъявлять подтверждения SCT. Журналы не предотвращают ошибочную выдачу, но делают её наблюдаемой; владелец домена должен настроить мониторинг.
• Отзыв. CRL, OCSP, степлинг и браузерные механизмы отзыва имеют разные ограничения по свежести, доступности, приватности и масштабу. Многие клиенты при недоступности OCSP продолжают соединение, поэтому полагаться только на оперативный отзыв нельзя. Короткий срок сертификата уменьшает окно риска, но не заменяет отзыв при компрометации ключа.

6. Развёртывание: SNI, ALPN, mTLS и HSTS

• SNI передаёт имя сервера в ClientHello и позволяет обслуживать несколько имён на одном IP-адресе. Без согласованного Encrypted Client Hello (ECH) это имя доступно наблюдателю; ECH закрывает его, но требует поддержки клиента, DNS и сервера.
• ALPN согласует прикладной протокол внутри защищаемого рукопожатия: например, h2 для HTTP/2. Этот механизм понадобится в следующей статье.
• Терминация TLS часто выполняется на обратном прокси или балансировщике. Участок от него до приложения — новое соединение с собственной моделью угроз; внешнее HTTPS не делает внутренний незашифрованный трафик защищённым.
• mTLS добавляет сертификат и проверку клиента. Его применяют для машинных соединений и в некоторых сервисных сетях, но сертификат лишь устанавливает идентичность: решение о полномочиях остаётся приложению или инфраструктуре авторизации.

HSTS закрывает другой разрыв: после получения заголовка браузер обращается к сайту только по HTTPS. Однако при первом посещении открытого HTTP соединение ещё можно подменить; для включённых в него доменов это окно устраняет предварительно загруженный список HSTS. Не менее опасна отключённая проверка сертификата в клиентском коде (verify=False, InsecureSkipVerify): такая настройка сохраняет шифрование, но лишает клиента надёжной аутентификации сервера.

Российские алгоритмы. RFC 9189 и RFC 9367 описывают профили TLS 1.2 и TLS 1.3 с алгоритмами ГОСТ. Оба документа имеют информационный статус, и их публикация не означает одобрения IETF приведённых алгоритмов. Для работы нужны совместимые криптопровайдер, клиент, сервер и цепочка доверия; такие корни не обязаны входить в обычные браузерные хранилища. Общая схема TLS — согласование параметров, установление ключей, аутентификация и защита записей — сохраняется, но сообщения и криптографические правила надо проверять по профилю соответствующей версии.

7. Постквантовое установление ключей

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

X25519MLKEM768 объединяет эфемерный X25519 с постквантовым механизмом ML-KEM-768. Данные обоих механизмов передаются в key_share, а их результаты объединяются при выводе общего секрета. Гибрид рассчитан на сохранение защиты, пока остаётся стойкой хотя бы одна компонента. ML-KEM стандартизован NIST, общий способ гибридного обмена описан в RFC 9954, а конкретные группы ECDHE–ML-KEM стандартизованы в опубликованном в августе 2026 года RFC 10024; группа X25519MLKEM768 имеет статус Recommended.

Гибрид уже включён по умолчанию в Chrome и Firefox, поддерживается OpenSSL 3.5 и рядом серверных платформ. Это не означает, что каждое соединение постквантовое: алгоритм должен поддерживать и выбрать сервер, а крупный ClientHello иногда выявляет несовместимые промежуточные устройства. Сертификаты и подписи переходят отдельно, потому что они решают задачу аутентификации, тогда как гибридный обмен прежде всего защищает конфиденциальность записываемого сегодня трафика. Подробнее это различие разобрано в главе 12, а механизм ML-KEM и лабораторная работа — в главах 13–14.

8. Практикум: разбираем рукопожатие

Для заданий 1–3 достаточно распространённой версии OpenSSL 3.x; для X25519MLKEM768 нужна версия 3.5 или новее. Сначала проверьте openssl version.

Задание 1. Версия, ключи и проверка имени.

$ openssl s_client -connect example.com:443 -servername example.com \
    -verify_hostname example.com -verify_return_error -brief </dev/null

Запишите версию, шифронабор, согласованную группу и результат проверки. Повторите команду с -msg без -brief и найдите ClientHello, ServerHello, CertificateVerify и Finished. OpenSSL показывает расшифрованные им сообщения; в сетевом дампе сертификат TLS 1.3 открытым текстом не виден.

Задание 2. Цепочка.

$ openssl s_client -connect example.com:443 -servername example.com \
    -showcerts </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Команда после конвейера разбирает первый сертификат из присланного сервером набора. Найдите издателя, срок и имя в SAN. Затем изучите полный вывод -showcerts: сервер обычно присылает промежуточные сертификаты, но не обязан присылать доверенный корень. Не путайте показанную сервером последовательность с уже проверенной цепочкой.

Задание 3. Версии и группы. Повторите первое соединение с -tls1_2 и сравните порядок сообщений и видимость сертификата. Попробуйте -tls1: старая версия может быть запрещена самим OpenSSL, политикой ОС или сервером — по сообщению об ошибке определите, на каком уровне произошёл отказ. Параметром -groups ограничьте список групп и вызовите успешное согласование, HelloRetryRequest либо отсутствие общей группы.

Задание 4. Постквантовый гибрид.

$ openssl s_client -connect www.google.com:443 -servername www.google.com \
    -verify_hostname www.google.com -verify_return_error \
    -groups X25519MLKEM768 -brief </dev/null

При успешном согласовании OpenSSL укажет группу X25519MLKEM768. С приведённой командой возможны два исхода: гибрид согласован либо общей группы нет. Затем добавьте к списку классический резервный вариант, например :X25519, и проверьте, какой из двух вариантов выберут несколько разных серверов.

Задание 5*. Собственный сервер. Если nginx собран с OpenSSL 3.5 или совместимой библиотекой и завершает TLS сам, задайте поддерживаемые группы, оставив классический резервный вариант:

ssl_ecdh_curve X25519MLKEM768:X25519;

После проверки конфигурации и перезагрузки подтвердите обе ветви: клиент OpenSSL 3.5 согласует гибрид, а клиент без ML-KEM — X25519. Если TLS завершается на CDN или внешнем балансировщике, настройка должна выполняться там, а не на исходном nginx.

Задание 6*. Граница доверия. В отдельном тестовом профиле браузера поднимите mitmproxy. До установки его корня браузер должен отвергнуть подменённую цепочку; после установки корня соединение станет доверенным для этого профиля. Удалите корень по завершении и объясните, почему TLS не может отличить установленный администратором корень от установленного злоумышленником.

Задание 7*. Расшифровка собственного трафика. Запустите браузер с переменной SSLKEYLOGFILE или используйте параметр -keylogfile поддерживающего его клиента, затем передайте журнал Wireshark. Поддержка переменной зависит от приложения и TLS-библиотеки. Убедитесь, что в дампе появились HTTP-данные, и сформулируйте границу прямой секретности: она защищает от последующей компрометации долговременного ключа, но конечная точка во время сеанса знает трафиковые секреты.

Итоги

• TLS защищает содержимое, целостность и порядок записей и аутентифицирует сервер при условии, что клиент проверяет цепочку и нужное имя.
• Полное рукопожатие TLS 1.3 устанавливает эфемерный секрет за один сетевой круг, шифрует сообщения после ServerHello и связывает диалог с сертификатом через CertificateVerify и Finished.
• 0-RTT не имеет встроенной межсоединительной защиты от повторов и полной прямой секретности; допустимые ранние операции должен определять прикладной протокол.
• Web PKI сочетает корневые хранилища, проверку домена, Certificate Transparency и механизмы отзыва; короткие сроки сертификатов уменьшают, но не устраняют риск компрометации.
• Гибрид X25519MLKEM768 уже развёрнут, однако согласовывается только при поддержке обеих сторон; миграция обмена ключами не заменяет будущую миграцию подписей и PKI.

Литература

1. RFC 9846, «The Transport Layer Security (TLS) Protocol Version 1.3», 2026; документ заменил исходный RFC 8446.
2. RFC 8470, «Using Early Data in HTTP» — применение 0-RTT и код ответа 425.
3. CA/Browser Forum, Ballot SC-081v3 — график сокращения срока публичных TLS-сертификатов.
4. RFC 9954, «Hybrid Key Exchange in TLS 1.3»; RFC 10024, «Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3».
5. Документация OpenSSL: s_client; RFC 9189 и RFC 9367 — информационные профили ГОСТ для TLS 1.2 и 1.3.
6. Certificate Transparency; I. Ristić, «Bulletproof TLS and PKI», 2nd ed., Feisty Duck, 2022.
7. Материалы ЦИТадели: глава 12 (HNDL и приоритеты миграции), глава 13 (ML-KEM) и глава 14 (практическая миграция).