menu
menu
logo
Веб-серверы и ГОСТ-криптография
5 июня 2023 Статьи

Веб-серверы и ГОСТ-криптография

TLS-сертификаты «по ГОСТ» отличаются от «обычных» лишь используемой криптосистемой. Это означает, что поля сертификата, соответствующие значению подписи, будут обозначены специальным идентификатором. Кроме того, будет отличаться интерпретация байтов самого значения подписи, а в содержательную часть сертификата могут быть добавлены некоторые значения, которые актуальны для программной инфраструктуры ГОСТ-подписи. Однако эти отличия не являются принципиальными, и в целом – это такой же TLS-сертификат, как и сертификат с ECDSA-подписью. Применительно к TLS ГОСТ-криптография описана в целом ряде RFC. Например: RFC 9367 – для TLS 1.3, RFC 9189 – для TLS 1.2 и др. Именно TLS-сертификаты и криптосистемы, используемые для их подписи, являются причиной использования различных конфигураций на стороне TLS-сервера, особенно в случае веб-узлов (HTTPS).

Особенности TLS

TLS – это один из самых распространённых в глобальной Сети инструментов защиты информации, который применяется и в HTTPS, и в различных реализациях VPN, и для работы с DNS. При этом, благодаря популярности веба, HTTPS является едва ли не лучшим источником примеров внедрения TLS-технологий.

Посмотрим на принципы TLS-соединения в самом первом приближении. Соединение инициирует клиент. В случае веба – это браузер. Клиент передаёт начальное сообщение, указывая в нём перечень сочетаний различных криптосистем, которые клиент готов использовать. Сервер должен подтвердить выбор в ответном сообщении. Если выбор, сделанный сервером, окажется соответствующим ожиданиям клиента, то обе стороны смогут установить TLS-соединение. Именно такая схема позволяет реализовать приоритеты для криптосистем на стороне сервера и осуществить выбор в соответствии с набором, который предоставил клиент.

Так, если среди переданных клиентом идентификаторов есть соответствующие ГОСТ-криптографии, то сервер продолжает соединение уже в ГОСТ-варианте. Здесь нужно отметить, что начальное клиентское сообщение TLS – универсальное: используется и для ГОСТ, и для «не-ГОСТ». Отличия возникают на следующих шагах алгоритма, однако концептуально ГОСТ-TLS – это тот же «обычный» TLS, но «построенный из других кубиков».

TLS построен из нескольких основных криптографических элементов. Это, во-первых, хеш-функция, которая необходима на всех этапах работы TLS-соединения, в частности, для операций электронной подписи и вычисления кодов аутентификации TLS-сообщений. Во-вторых – криптосистема электронной подписи, требующаяся для аутентификации узлов. В-третьих – алгоритм получения симметричного секрета, который позволяет безопасно использовать симметричные шифры для защиты передаваемых данных. И, наконец, четвёртый элемент – сам симметричный шифр.

Элементы стандартов

Когда применительно к TLS говорят о «криптографии по ГОСТ», то подразумевают использование российских криптографических алгоритмов в фундаменте протокола, то есть для реализации только что перечисленных элементов (или, если хотите, «кубиков»). ГОСТ-TLS содержит некоторые другие отличия, которые, однако, не так существенны. Если рассматривать ситуацию уровнем выше криптографических примитивов, то оказывается, что «TLS по ГОСТ» совпадает с «обычным» TLS и с точки зрения общей архитектуры, и с точки зрения решаемых задач. ГОСТ-TLS это «обычный» TLS, но с подключением российских криптосистем.

Рассмотрим ситуацию на примерах. TLS типа «не-ГОСТ» повсеместно использует хеш-функцию SHA-256 (относится к серии SHA-2). Аналогом в современном ГОСТ-TLS является отечественная хеш-функция «Стрибог» (ГОСТ серии 34.11), которая может работать в той же разрядности, что и SHA-256, а именно – 256 бит. Более того, эти хеш-функции хоть и устроены внутри различным образом, но с точки зрения использования в TLS радикальных отличий между SHA-256 и «Стрибог» нет: одна может без проблем непосредственно заменить другую в том или ином высокоуровневом алгоритме.

В качестве примера криптосистемы электронной подписи возьмём ECDSA, которая широко применяется в TLS. Аналогом в ГОСТ-TLS является криптосистема подписи из ГОСТ серии 34.10. Обе этих криптосистемы используют один и тот же математический аппарат (эллиптические кривые), а отличаются они в алгебраических деталях, которые снаружи обычно не видны, поскольку совпадает не только способ применения обеих криптосистем, но даже математическое представление ключей и значения подписи.

В TLS для защиты потока передаваемых данных используется симметричный шифр, в котором совпадают ключи зашифрования и расшифрования. Чтобы стороны могли получить общие секретные ключи, требуется тот или иной специализированный алгоритм. Обычно используются варианты протокола Диффи-Хеллмана. Так, «обычный» сеанс TLS в 2023 году скорее всего использует ECDH, протокол Диффи-Хеллмана, работающий на эллиптической кривой. Здесь, в случае ГОСТ-TLS, возможны варианты: версии до 1.3 используют несколько другой набор алгоритмов согласования секретов, отличающийся от вариантов «обычного» протокола TLS. Однако более современный ГОСТ-TLS 1.3 в этой части эквивалентен «обычной» версии TLS.

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

Выбор сертификата

Всё это может показаться сложным, однако для того, чтобы понять, как именно криптосистемы ГОСТ и «не-ГОСТ» могут работать совместно на веб-сервере, достаточно представления о криптосистемах электронной подписи. Электронная подпись используется в TLS-сертификатах, которые служат для аутентификации узлов. Веб-сервер должен предъявить подключающемуся клиенту «правильный» сертификат. В нашем случае «правильный» означает, что совпадающий по криптосистеме. Прислать клиенту сразу все возможные сертификаты нельзя – это может привести к сбою. Однако у криптосистемы ГОСТ на стороне сервера может быть максимальный приоритет, и если сервер получает от клиента сигнал о том, что клиент поддерживает ГОСТ, то сертификаты ECDSA сервер не передаёт – предлагается сразу ГОСТ.

Важный момент: обычно передаётся сразу цепочка сертификатов ГОСТ, а браузер (или другой клиент) должен на своей стороне проверить валидность этой цепочки, выстроив соответствующий путь до доверенного корневого ключа. Это, впрочем, верно и для ECDSA, и для других криптосистем в сертификатах, поскольку логика построения цепочек лежит в основе инфраструктуры доверия TLS для веба. Однако есть особенности, которые касаются набора корневых ключей в браузерах. В теории, ничто не мешает подписывать сертификаты с ключами ГОСТ подписями ECDSA или RSA. Тогда можно было бы использовать корневой ключ, предположим, RSA, но ниже по цепочке – уже ГОСТ-подпись. Это, впрочем, не самая логичная практика, и вряд ли кто-то использует или станет использовать такой подход, хотя в случае сочетания ECDSA с RSA он и встречается повсеместно. То есть для ГОСТ нужна отдельная иерархия доверия: в браузере (или в операционной системе, это здесь не так важно) должен быть доверенный корневой ключ для ГОСТ-сертификатов, которые он может встретить на сайтах. При этом в браузер «из коробки» встроен некоторый набор доверенных корневых ключей, который в случае распространённых браузеров не включает ГОСТ-ключи – их придётся добавить вручную. Конечно, можно сказать, что это всего лишь современная ситуация глобального Веба, в котором поддержка ГОСТ-TLS является экзотикой, однако мы как раз хотим сохранить высокую степень совместимости, поэтому и ориентируемся на распространённые решения.

Назначение повышенного приоритета ГОСТ-TLS на стороне сервера означает, что клиент, подключающийся с поддержкой ГОСТ, будет получать ответ с ГОСТ. К сожалению, в подавляющем большинстве случаев сервер не сможет узнать, есть ли на клиенте нужные корневые ключи ГОСТ. Опять же, эта проблема переносится и на ситуацию с криптосистемами ECDSA/RSA: сервер точно так же может использовать сертификаты удостоверяющего центра* (УЦ), которого нет на стороне браузера. Для ECDSA/RSA и общедоступного Веба такая ситуация, конечно, встречается гораздо реже, но вполне возможна: хорошим примером является корень TLS российского НУЦ (Национального Удостоверяющего Центра), который использует криптосистему RSA, но в дистрибутивы распространённых «международных» браузеров не входит.

Браузер мог бы сигнализировать о том, что он поддерживает какие-то конкретные корневые сертификаты УЦ. В спецификации TLS даже есть подходящее сообщение, но когда типичный браузер содержит сотни корневых сертификатов в составе дистрибутива, данное сообщение получилось бы слишком объёмным. Да и внедрение его потребовало бы доработки браузеров. Поэтому в случае с ГОСТ серверы вынуждены ориентироваться на список криптосистем, а не на список корневых ключей клиента, который им не известен.

Производительность

ГОСТ и «не-ГОСТ» версии TLS используют разные низкоуровневые алгоритмы, а реализации этих алгоритмов отличаются по производительности. Так, если говорить о шифрах, то у AES есть аппаратная поддержка во многих процессорах, что даёт большой прирост производительности, если сравнивать с чисто программной реализацией. Поэтому, на совместимой аппаратуре, AES («не-ГОСТ») может работать существенно быстрее «Кузнечика» (ГОСТ), даже с учётом того, что с точки зрения вычислительной сложности эти шифры очень близки.

Тем не менее, оптимизированные реализации «Кузнечика» показывают более чем достаточную производительность, которая сравнима с пропускной способностью типичной конфигурации TCP-стека на основе быстрого современного сетевого интерфейса под управлением ядра Linux. Поэтому ГОСТ-шифры для веба вполне подходят. То же самое можно сказать о хеш-функциях.

Что касается электронной подписи и алгоритмов выработки симметричных секретов, то здесь отличия не существенны по следующим причинам: во-первых, используется та же арифметика, что и для «не-ГОСТ»; во-вторых, операции подписи и вычисления секретов в TLS применяются на этапе согласования соединения, то есть достаточно редко. Естественно, необходимость вызова дополнительных функций, по сравнению с поддержкой единственной «универсальной» криптосистемы, может приводить к повышению расхода вычислительных ресурсов при установлении соединения, однако современное оборудование вполне способно незаметно компенсировать эти изменения.

Итоговые настройки

Итак, ГОСТ-TLS и «обычный» TLS можно настроить на веб-сервере параллельно. В качестве примера – вариант ГОСТ+ECDSA. Необходимо, чтобы сборка веб-сервера включала в себя криптографические библиотеки, реализующие ГОСТ-TLS. Так, в случае OpenSSL, это дополнительный модуль gost-engine.

Основная часть настройки – управление двумя комплектами сертификатов: ГОСТ-сертификатами и ECDSA-сертификатами. Веб-сервер, используя данные, передаваемые клиентом (браузером) в самом начале TLS-соединения, будет автоматически выбирать подходящий комплект.

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

Пример для Apache 2.4:
SSLCertificateFile /etc/pki/gost-tls/certs/server-a.pem
SSLCertificateKeyFile /etc/pki/gost-tls/keys/key-a.pem
SSLCertificateChainFile /etc/pki/gost-tls/certs/interm-new.pem

В перечень поддерживаемых сервером криптосистем, задаваемый в конфигурации, включаются идентификаторы криптосистем ГОСТ (точное наименование зависит от операционной системы, типа веб-сервера и криптографических библиотек, но обычно эти идентификаторы содержат подстроку GOST, например, GOST2012-GOST8912).

Выпустить сертификаты для разных криптосистем, чтобы протестировать настройки, можно, например, в Центре Сертификации TLS ТЦИ, который позволяет получить и ГОСТ-, и ECDSA-сертификат на одно и то же имя (но в разных заказах).


* Сейчас удостоверяющие центры (УЦ) TLS нередко называют Центрами Сертификации (ЦС). С технической точки зрения термины являются синонимами, а отличия возникают из административных и юридических аспектов. В этой статье используется более привычное обозначение – Удостоверяющие Центры (УЦ).



RIGF 2025: Обсуждение ключевых вопросов управления интернетом в России
RIGF 2025: Обсуждение ключевых вопросов управления интернетом в России
В Москве завершил свою работу 15-й Российский форум по управлению Интернетом
Продажа домена Zip.ai возглавила новый выпуск рейтинга крупнейших доменных сделок
Продажа домена Zip.ai возглавила новый выпуск рейтинга крупнейших доменных сделок
Ресурс DN Journal обновил свой рейтинг
ТЦИ поздравляет с Днем рождения российского Интернета!
ТЦИ поздравляет с Днем рождения российского Интернета!
Сегодня мы отмечаем знаменательную дату — 31 год с момента регистрации первого домена в зоне .RU
ТЦИ рассказал о новых технологиях и стандартах своего Центра сертификации, приняв участие в конференции АДЭ
ТЦИ рассказал о новых технологиях и стандартах своего Центра сертификации, приняв участие в конференции АДЭ
C 2 по 3 апреля в Москве состоялась XXIII ежегодная конференция Ассоциации документальной электросвязи (АДЭ) на тему «Обеспечение доверия и безопасности при использовании ИКТ». В мероприятии приняли участие представители ТЦИ.

Контакты

г. Москва, улица 8 марта,
дом 1, строение 12 (БЦ Трио, первая башня)

+7 495 730-2969
info@tcinet.ru

Клиентская служба

+7 495 730-2970

vk-img ВКонтакте