Tls гост что это
Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Главное меню
Лидер российского рынка по распространению средств криптографической защиты информации, электронной подписи и развитию инфраструктуры открытых ключей на основе российских криптографических алгоритмов
- О компании
- Контакты
- Схема проезда
- Новости
- Лицензии
- Аккредитация
- Реквизиты
- Вакансии
- КриптоПро CSP
- Использование
- КриптоПро CSP Lite
- КриптоПро TLS c ГОСТ
- КриптоПро Java CSP
- КриптоПро Winlogon
- Считыватели
- История версий
- Сравнение версий
- Совместимость реализаций X.509 и CMS
- Загрузка файлов
- КриптоПро JTLS
- КриптоПро Java CSP
- Загрузка файлов
- Описание
- Платёжный HSM
- Использование
- Информационные материалы
- Мобильные приложения
- Тестовый СЭП
- КриптоПро DSS Lite
- КриптоПро CloudCSP
- Загрузка файлов
- VPN-сервер NGate
- TLS-сервер NGate
- Сервер портального доступа
- IPsec VPN-шлюз NGate
- Общая информация
- Информационные материалы
- Аппаратные платформы
- Загрузка файлов
- КриптоПро УЦ 1.5
- КриптоПро УЦ 2.0
- КриптоПро Службы УЦ
- Задачи
- Развёртывание
- Консалтинг
- Обучение
- Техническая поддержка
- КриптоПро Шлюз УЦ-СМЭВ
- Использование
- Совместимость реализаций IPsec
- Загрузка файлов
- Браузер Chromium-Gost
- КриптоПро ЭЦП Browser plug-in
- Приложение cryptcp
- КриптоПро Office Signature
- КриптоПро PDF
- КриптоПро AirKey
- Защищенная мобильность
- КриптоПро Stunnel
- stunnel-msspi
- КриптоПро SPR 4.0
- Secure Pack Rus (SPR 3.0)
- КриптоПро Шлюз УЦ-СМЭВ
- КриптоПро ЭЦП
- КриптоАРМ ГОСТ
- КриптоПро CRM
- КриптоПро SSF
- КриптоПро HLF
- Электронные замки
- Считыватели смарт-карт
- USB-токены
- Услуги УЦ
- Сервис электронной подписи
- Консалтинг
- CRM решения для УЦ
- Защита информации
- Блокчейн (распределённый реестр)
- Обучение
- Список партнёров по регионам
- Дистрибьюторы
- Стать партнёром
- Вход для партнёров
- Решения партнёров
- Портал технической поддержки
- Центр загрузки
- Тестовый УЦ
- База знаний (FAQ)
- Документация
- Поиск
- Проверка лицензии
- Проверка возможности обновления
- Юридические лица
- Форма заказов
- Оплата
- Доставка
- Форма заказов
- Оплата
- Доставка
- Форма заказов
- Доставка
- Оплата
- Условия возврата
- Форма заказов
- Доставка
- Оплата
- Условия возврата
- Order form
- Payment methods
- Delivery
- Как оформить заказ
- Как скачать
- Как установить
- Как ввести лицензию
Что такое TLS в КриптоПро
TLS (transport layer security — протокол защиты транспортного уровня)— это протокол защиты данных при транспортировке их в сети интернет. Протокол шифрует передаваемую информацию криптографическим методом, оставляя данные конфиденциальными.
Для чего нужен протокол
Протокол TLS — шифрует все виды интернет-трафика, в том числе и веб-трафик, используя широкий набор методов шифрования. Используется приложениями электронной почты и системами телеконференций.
Как работает протокол
Протокол использует асимметричное шифрование для аутентификации данных, симметричное шифрование для конфиденциальности и коды аутентичности для сохранения целостности сообщений.
Важнейшим фактором шифрования является условия для отсутствия уязвимостей при передаче данных. Протокол TLS компании КриптоПро отражает такие атаки, как дешифрование куки-файлов и атаки на блочный шифр, благодаря российским наборам шифрования на основе ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012. Реализация протокола используется для обеспечения безопасности защищённых соединений и совместимости продуктов различных производителей. Список совместимости со средствами криптографической защиты информации других компаний расширяется по мере проведения тестовых испытаний.
Модуль сетевой идентификации входит в комплект поставки ПО КриптоПро CSP 5.0 и не требует отдельной установки и настройки. Протокол КриптоПро TLS совместим с программным обеспечением (ПО) средств криптографической информации (СКЗИ) компании КриптоПро.
Версию с бесплатным периодом КриптоПро CSP 5.0 с актуальными наборами шифрования можно скачать на сайте КриптоПро. После использования пробного периода приобрести лицензию КриптоПро можно в «Астрал-М». «Астрал-М» является официальным дилером продукции торговой марки КриптоПро. Этот статус даёт право на распространение, внедрение и сопровождение программ КриптоПро с круглосуточной поддержкой пользователей 24/7. Достаточно заполнить форму обратной связи на сайте, вписав своё имя, телефон и адрес электронной почты.
Поддержка работы с TLS-трафиком, зашифрованного ГОСТ-алгоритмами
UserGate первым из вендоров реализовал возможность расшифровывать TLS-трафик на уровне шлюза в случае использования алгоритмов, поддерживающих национальные стандарты ГОСТ.
По последним данным более 90% соединений в Интернете осуществляются с применением клиент-серверного шифрования, то есть с использованием SSL/TLS сертификатов. Развитие этой сферы не стоит на месте и вопрос доверия к сертификатам и к ресурсам, их использующих, все еще не решен на 100%. На данный момент споры на тему «нужно ли расшифровывать TLS 1.3» утихли, однако появился следующий вопрос — что делать с TLS ГОСТ?
Реализация протокола TLS с использованием алгоритмов ГОСТ была придумана для того, чтобы иностранные удостоверяющие центры не могли отзывать сертификаты каких-либо ресурсов, тем самым нарушая их доступность для посетителей. В настоящее время организация работы порталов с использованием алгоритмов ГОСТ осложняется другой проблемой — известные зарубежные браузеры и операционные системы не хотят принимать сертификаты, совместимые с ГОСТ, не доверяют им и попросту не пускают пользователей к посещению. Для корректной доступности в такие ресурсы пользователю нужно иметь соответствующий браузер (на данный момент насчитывается 2 таких браузера на рынке) или импортозамещенную операционную систему.
В использовании TLS с поддержкой ГОСТ алгоритмов шифрования есть две основные проблемы:
- Проблема инфраструктуры. Далеко не все устройства готовы к использованию совместимых сертификатов, особенно это касается мобильных устройств. В данном случае UserGate позволяет принять сертификат, совместимый с ГОСТ, расшифровать трафик и отдать внутрь сети уже по понятным внутрикорпоративным сертификатам. Таким образом, отпадает необходимость использовать специальные браузеры для доступа к ресурсам. Пользователи могут не мигрировать с привычных продуктов.
- Проблема безопасности. К сожалению, наличие сертификата гарантирует только то, что портал организации относится действительно к той организации, которую он представляет. Если сайт был скомпрометирован, если были украдены сертификаты (такие случаи тоже известны), либо если в рамках защищенного соединения передается зловредный файл, то это все будет спокойно реализовано с помощью TLS ГОСТ. При этом ни одно решение не готово раскрывать трафик с отечественными алгоритмами шифрования для детального анализа содержимого. Решение UserGate умеет работать с таким трафиком, проводить глубокую инспекцию и выявлять опасные, подозрительные и зловредные элементы даже внутри защищенного трафика.
Веб-серверы и ГОСТ-криптография
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 нередко называют Центрами Сертификации (ЦС). С технической точки зрения термины являются синонимами, а отличия возникают из административных и юридических аспектов. В этой статье используется более привычное обозначение – Удостоверяющие Центры (УЦ).