Tls гост что это

TLS 1.2 и новый ГОСТ

Вниманию читателей предлагается краткий обзор разрабатываемого проекта рекомендаций по стандартизации, определяющего использование российских криптографических алгоритмов в протоколе TLS 1.2 (далее просто проект рекомендаций).

Протокол TLS

Протокол TLS (Transport Layer Security) является одним из наиболее популярных протоколов, предназначенных для установления защищенного канала связи в сети Интернет. Он основан на спецификации протокола SSL (Secure Sockets Layer) версии 3.0, но за время своего существования претерпел довольно много изменений. Актуальной версией протокола на текущий момент является версия TLS 1.2, однако в ближайшем будущем ожидается выход версии TLS 1.3.

Протокол TLS состоит из двух уровней. На нижнем уровне находится протокол Записей TLS, работающий поверх некоторого транспортного протокола с гарантированной доставкой пакетов (см. TCP). Протокол Записей обеспечивает конфиденциальность и целостность передаваемых по каналу связи данных. Поверх протокола Записей, в свою очередь, работают протокол Оповещения, протокол Изменения Состояния, протокол Прикладных Данных и протокол Рукопожатия. Первые три по сути не решают никаких криптографических задач, а основной интерес здесь представляет протокол Рукопожатия, который отвечает за аутентификацию сторон и выработку параметров безопасности, необходимых для защиты данных на уровне протокола Записей.

Новые криптонаборы: кто они такие и зачем нужны?

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

Разрабатываемый проект рекомендаций определяет два новых криптонабора:

TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC;
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC.

Первый базируется на использовании блочного шифра Кузнечик, второй — на использовании
блочного шифра Магма.

Разберемся подробнее, что же нового, помимо новых алгоритмов шифрования, было добавлено в версию протокола TLS 1.2 с российскими криптонаборами.

Основные принципы и важные особенности

Основные принципы работы протокола Рукопожатия в новых криптонаборах почти не изменились по сравнению с предыдущей версией отечественных криптонаборов. Коротко, основной секретный параметр — premaster secret (PMS) — вырабатывается клиентом и передается серверу зашифрованным с помощью его открытого ключа. Аутентификация сервера осуществляется за счет факта корректного извлечения сервером секретного значения PMS с помощью своего закрытого ключа. Клиент, если это требуется, аутентифицируется с помощью подписи.

Основные криптографические нововведения в протокол Рукопожатия состоят в следующем:

используется новый алгоритм шифрования PMS, так называемый алгоритм экспорта ключа, основанный на новых шифрах и режимах их работы (определяется в рамках другого нового документа);
сессионный секрет — master secret (MS) — теперь привязывается не только к случайным значениям сторон, передаваемым в сообщениях приветствия, но и ко всем сообщениям, переданным до момента его генерации. Главное здесь то, что значение MS теперь зависит от сертификата сервера, что позволяет противостоять атаке Triple Handshake. Данное нововведение соответствует рекомендациям RFC 7627.

В противовес протоколу Рукопожатия протокол Записей не похож ни на свой аналог из предыдущей версии отечественных рекомендаций, ни на зарубежные версии. В нем реализованы все передовые достижения, касающиеся задач обеспечения защищенного канала связи и минимизации нагрузки на ключ (то есть количества данных, обрабатываемых на одном ключе). Ключи, участвующие в защите данных, образуют иерархию (корневой ключ, ключи промежуточных уровней, ключи обработки сообщений и секционные ключи), которая позволяет увеличивать количество обрабатываемых сообщений, оставаясь в рамках безопасной нагрузки на ключ. Создание такой иерархии достигается за счет использования механизмов внешнего и внутреннего преобразования ключей (external и internal re-keying), положительные свойства которых доказаны в ряде работ как зарубежных (см. работу Абдалы и Беллара), так и отечественных криптографов (см. здесь и здесь). Эти механизмы реализуются посредством применения режима шифрования CTR-ACPKM и функции диверсификации ключей TLSTREE. Упомянутые подходы к уменьшению нагрузки на ключ описаны в драфте RFC, также разрабатываемого сейчас под руководством отечественных специалистов.

Заключение

Получившийся документ является в полной мере самодостаточным описанием и, несмотря на свой внушительный объем, стал понятным и структурированным. Помимо описания алгоритмической части в приложении к документу можно найти подробный журнал работы протокола, разобранный по полям используемых структур. Такое описание контрольных значений существенно облегчает понимание деталей работы протокола.

На настоящий момент номерам разрабатываемых криптонаборов присвоены временные значения из приватной области номеров IANA. Как только проект рекомендаций будет принят, планируется сразу же приступить к разработке его RFC.

Стоит также отметить, что ближайшими планами экспертов рабочей группы технического комитета 26 (ТК26) является начало разработки следующего проекта рекомендаций, посвящённого криптонаборам, соответствующим версии TLS 1.3. Работа над данным документом начнется сразу после утверждения в TK26 текущего проекта для TLS 1.2, а также после выхода нового RFC для TLS 1.3.

ГОСТ TLS (часть 2): как подключиться

В предыдущей заметке рассматривался проект требований по использованию ГОСТ TLS для взаимодействия с государственными органами (здесь и далее в заметке речь идет про односторонний TLS). Требования — это основа пилотного проекта для следующих систем:

Единый портал госуслуг,
ГИС ЖКХ,
ЕГИССО,
ФГИС «Реестры программ для ЭВМ и баз данных».

Пока ни одна из систем не доступна с помощью ГОСТ, судя по всему, российские криптоалгоритмы добавятся в ближайшее время, так как пилот заканчивается уже 1 марта 2021 года. Тем не менее есть ряд других сайтов, на которых можно потестировать ГОСТ TLS уже сейчас.

С чего начать?

Чтобы начать пользоваться ГОСТ TLS нужно выполнить три основных шага:

Зарегистрироваться на сайте производителя криптопровайдера и скачать CSP для реализации ГОСТ.
Установить доверенный сертификат или сертификаты.
Включить поддержку ГОСТ в браузере.

Пункты 2 и 3 опциональны, например, доверенные сертификаты могут устанавливаться вместе с CSP, а некоторые браузеры подхватывают ГОСТ «на лету».

Варианты

Пользователю нужно быть морально готовым к ряду ограничений — доступны далеко не все операционные системы и не все браузеры. Я подготовил табличку (актуальна на сентябрь 2020 года):

ОС	Яндекс.Браузер	Internet Explorer	Спутник (корпоративная версия)	Сhromium-gost
Windows	+	+	+	+
Linux	—	—	—	+
MacOS	—	—	—	+
Android	—	—	—	—
iOS	—	—	—	—

Поддержка ГОСТ в браузерах

Фактически вариативность есть только под ОС Windows. Для Linux и MacOS доступен единственный вариант — Сhromium-gost. А вот на мобильных устройствах по-прежнему придется пользоваться RSA.

Пример

Я не стал дожидаться релиза ГОСТа на гос.услугах и решил проверить доступ на других сайтах. Порядок действий:

Скачал Крипто-Про CSP c официального сайта и установил (доверенные сертификаты УЦ Крипто-Про и Минкомсвязи уже на борту),
Установил сертификат Минкомсвязи, так как на тот момент не знал, что он зашит в дистрибутив Крипто-Про CSP,
В Яндекс.Браузере включил поддержку ГОСТ (Настройки – Системные).

При переходе на сайты с ГОСТ запрашивается подтверждение:

ГОСТ в Яндекс.Браузер

Далее сайт доступен по ГОСТ TLS:

ГОСТ TLS на портале ЕАТ

Проверил на сайтах:

— прозрачно переключился на ГОСТ, — прозрачно переключился на ГОСТ, — под ГОСТ создан отдельный домен gost.infotecs.ru, — прозрачно переключился на ГОСТ.

Если знаете другие сайты с ГОСТ TLS, доступные без регистрации и смс, напишите — добавлю в список.

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

Об использовании ГОСТ SSL(TLS)-сертификатов

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

В этой связи остро встает вопрос диверсификации защищенного доступа к веб-сайтам организаций. Достичь этого можно разными способами. Например, получив несколько сертификатов в разных международных УЦ. Но здесь опять же есть риск того, что и эти УЦ в какой-то момент отзовут выданные ими сертификаты.

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

Что для этого необходимо:

Получить сертификат в отечественном УЦ, например, в этом: https://tlsca.cryptopro.ru/tls.htm .

На стороне пользователя (при доступе к веб-сайту с ПК) установить одну из актуальных версий КриптоПро CSP и один из браузеров, поддерживающих ГОСТ TLS (Яндекс.Браузер, Internet Explorer, Chromium Gost). При этом важно отметить, что лицензия на КриптоПро CSP при одностороннем TLS (односторонняя аутентификация сервера по сертификату сервера), не требуется. Кроме этого, что не менее важно, при использовании сертификата, полученного в указанном выше УЦ, доверие к корневому сертификату данного УЦ и выданным им сертификатам, на стороне пользователя обеспечивается автоматически, т.к. корневой сертификат данного УЦ зашит в дистрибутив актуальных версий КриптоПро CSP и устанавливается в ОС автоматически при установке на ПК пользователя ПО КриптоПро CSP.

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

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 нередко называют Центрами Сертификации (ЦС). С технической точки зрения термины являются синонимами, а отличия возникают из административных и юридических аспектов. В этой статье используется более привычное обозначение – Удостоверяющие Центры (УЦ).