TLS-сертификаты «по ГОСТ» отличаются от «обычных» лишь используемой криптосистемой. Это означает, что поля сертификата, соответствующие значению подписи, будут обозначены специальным идентификатором. Кроме того, будет отличаться интерпретация байтов самого значения подписи, а в содержательную часть сертификата могут быть добавлены некоторые значения, которые актуальны для программной инфраструктуры ГОСТ-подписи. Однако эти отличия не являются принципиальными, и в целом – это такой же TLS-сертификат, как и сертификат с ECDSA-подписью. Применительно к TLS ГОСТ-криптография описана в целом ряде RFC. Например: RFC 9367 – для TLS 1.3, RFC 9189 – для TLS 1.2 и др. Именно TLS-сертификаты и криптосистемы, используемые для их подписи, являются причиной использования различных конфигураций на стороне TLS-сервера, особенно в случае веб-узлов (HTTPS).
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 нередко называют Центрами Сертификации (ЦС). С технической точки зрения термины являются синонимами, а отличия возникают из административных и юридических аспектов. В этой статье используется более привычное обозначение – Удостоверяющие Центры (УЦ).
г. Москва, улица 8 марта, дом 1, строение 12 (БЦ Трио, первая башня)
+7 495 730-2969 info@tcinet.ru
+7 495 730-2970
