Перейти к содержанию

ГОСТ в TLS 1.2 и TLS 1.3: от шифра до рукопожатия

Современная спецификация

RFC 9367, опубликованный в феврале 2023 года, описывает ГОСТ-профиль TLS 1.3: наборы шифров, алгоритмы подписи, согласование ключей и требования к обмену сообщениями. Документ Informational / Independent Submission, а не стандарт IETF с обязательной реализацией ГОСТ в каждом TLS-продукте.

Профиль RFC 9189 относится к TLS 1.2 (март 2022 года): его наборы шифров и режимы не надо переносить в TLS 1.3 без адаптации. Основной документ TLS 1.3 обновлён в июле 2026 года: RFC 9846 заменил RFC 8446. Поэтому актуальная документация НАЙС.ОС должна ссылаться одновременно на профиль ГОСТ и на современную общую спецификацию TLS 1.3.

Четыре профиля в RFC 9367

Имя шифронабора Особенность
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L «Кузнечик», MGM, вариант L
TLS_GOSTR341112_256_WITH_MAGMA_MGM_L «Магма», MGM, вариант L
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S «Кузнечик», MGM, вариант S
TLS_GOSTR341112_256_WITH_MAGMA_MGM_S «Магма», MGM, вариант S

Указанные имена и идентификаторы перечислены в разделе 1 RFC 9367. Различие L/S связано с параметрами обработки записей и ограничениями. В TLS 1.3 криптонабор, группа согласования ключей и схема подписи согласуются отдельно. Нельзя свести проверку к одной строке с названием «Кузнечик».

Где используется ГОСТ

  1. Защита записей: AEAD на базе MGM и механизм смены ключей TLSTREE; необходимо соблюдать nonce и ограничения на объём данных.
  2. Подпись: алгоритм ГОСТ Р 34.10-2012 и его идентификатор схемы; клиент должен понимать форму публичного ключа в сертификате.
  3. Согласование ключей: поддерживаемые группы и способ вычисления общего секрета должны совпадать.
  4. Сертификаты: корректная цепочка X.509, имя сервера, EKU/KeyUsage и статус отзыва.

Главное ограничение при работе с НАЙС.ОС

OpenSSL Provider может предоставлять операции MGM, «Стрибог» и подпись ГОСТ на уровне EVP. Но это не доказывает, что TLS-стек OpenSSL выставляет шифронаборы RFC 9367 или принимает ГОСТ-группы. Nginx, собранный с таким OpenSSL, тоже не получает их автоматически.

Читаем перечни возможностей раздельно:

openssl version -a
openssl list -providers
openssl list -cipher-algorithms | grep -Ei 'kuznyechik|magma|gost'
openssl ciphers -v 'ALL' | grep -Ei 'GOST|KUZ|MAGMA' || true

Последние две команды проверяют разные уровни: криптографические алгоритмы EVP и согласуемые TLS-наборы. Отсутствие ГОСТ в openssl ciphers — основание не заявлять работоспособный ГОСТ-TLS.

Как проводится подтверждение

Поднимаются два контролируемых TLS-узла с согласованным ГОСТ-профилем и тестовыми сертификатами. В протоколе испытаний фиксируются версия TLS, код шифронабора, выбранная группа, сертификат, схема подписи, проверка имени, запись приложения, смена ключей и отрицательные тесты несовпадения параметров. Требуется независимая проверка, что действительно согласован ГОСТ-профиль, а не стандартный AES/TLS с ГОСТ-операцией где-то в приложении.

Из чего действительно состоит согласованный ГОСТ-TLS

TLS защищает поток приложения. Его безопасность зависит не от одной включённой строки cipher suite, а от полного рукопожатия и корректной обработки записей. Профиль ГОСТ TLS 1.3 из RFC 9367 следует читать вместе с актуальной базовой спецификацией RFC 9846 и RFC 9215 для ГОСТ X.509.

ClientHello (versions, supported_groups, signature_algorithms, key_share)
      |
      v
ServerHello + согласованная группа/ключевой обмен
      |
      v
HKDF/механизмы ключевого расписания выбранного ГОСТ-профиля
      |
      v
Certificate / CertificateVerify / Finished
      |
      v
Защищённые TLS records (MGM; ограничения nonce, ключей и записей)

Почему профили TLS 1.2 и TLS 1.3 нельзя смешивать

Область TLS 1.2 TLS 1.3
Базовая архитектура Обмен и выбор набора шифров старой модели Единое криптографическое расписание и новое рукопожатие
ГОСТ-профиль RFC 9189 RFC 9367
Сертификат Собственные правила совместимости со схемами подписи signature_algorithms, подтверждение владения ключом и форматы X.509
Реализация Согласуется отдельно Согласуется отдельно; поддержка 1.2 не переносится автоматически

И для TLS 1.2, и для TLS 1.3 нужен подтверждённый тест согласования, а не только возможность вычислить ГОСТ-подпись вручную.

Что фиксируется при приёмке

  • ClientHello/ServerHello: версия, выбранный cipher suite, key share / группа, расширения; для тестовых стендов допустим анализ TLS-трассы без раскрытия секретов.
  • Цепочка сертификата: доверенный CA, корректное имя сервера, KeyUsage/EKU, алгоритм подписи, период действия, CRL/OCSP по политике.
  • Передача данных: два направления, нормальное закрытие, несколько размеров сообщений, KeyUpdate, отрицательный сценарий неподдерживаемого профиля.
  • Ошибки: отказ при неизвестном УЦ, неверном имени, неподходящем алгоритме, несовместимой группе или повреждённой записи.
  • Архитектура: какая программа отвечает за реализацию ГОСТ в самом TLS-стеке, а не только за операции EVP.

Для НАЙС.ОС: OpenSSL и gost-engine могут предоставлять примитивы и сертификаты, но не автоматически RFC 9367 для сервера на Nginx. Проверку реализуемого профиля ведите отдельно в разделе GnuTLS/TLS и матрице.

Безопасность и эксплуатация

Повтор nonce в AEAD и нарушение лимитов ключевого материала могут разрушить гарантии целостности. В серверной инфраструктуре важны управление сертификатами, запрет незапланированного downgrade, контроль расширений, аудит обновлений, доверенные часы, согласованные параметры фронтенд-прокси и клиентских библиотек. ГОСТ-TLS не подтверждает сертификацию СКЗИ и не подменяет внутреннюю оценку требований к данным. Требования к профилю и режим MGM рассматриваются отдельно.

Источники