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 гост что это
КЛЮЧЕВОЕ СЛОВО
в защите информации
- О компании
- Контакты
- Схема проезда
- Новости
- Лицензии
- Аккредитация
- Реквизиты
- Вакансии
- КриптоПро 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-сертификат, как и сертификат с 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 нередко называют Центрами Сертификации (ЦС). С технической точки зрения термины являются синонимами, а отличия возникают из административных и юридических аспектов. В этой статье используется более привычное обозначение – Удостоверяющие Центры (УЦ).
Tls гост что это
Протоколы защиты соединений
Существуют различные протоколы защиты соединений, реализующие шифрование на различных уровнях: на сетевом, на транспортном или на прикладном.
Сетевые протоколы — это защита не одного конкретного соединения, а целой сети. Подключение к защищенной сети автоматически предоставляет пользователю доступ ко всей информации, циркулирующей по этой сети. Такой подход удобен, например, для корпоративного взаимодействия (локальная сеть или ее распределенный аналог), но совершенно не подходит для взаимодействия, например, с клиентами. Примеры сетевого протокола — различные протоколы, на основании которых строятся сети VPN: IPSec, PPTP, OpenVPN.
Прикладные протоколы предназначены для решения конкретных специализированных задач и требуют использования соответствующего программного обеспечения, зачастую нестандартного и непривычного для пользователя. Пример прикладного протокола — протокол ssh.
Транспортные протоколы идеально подходят для защиты соединений, предоставляющих доступ к отдельным видам сервисов, предоставляемым сервером. Именно такие клиент-серверные соединения используются в огромном большинстве в интернет-приложениях, если для доступа на сервер требуется аутентификация пользователя, а также если передача информации между сервером и клиентом должна быть закрытой. В настоящее время наиболее распространенным протоколом транспортного уровня в интернет-приложениях является протокол TLS, который является развитием более ранней версии — протокола SSL.
Протокол TLS и протоколы интернет-соединений
TLS-серверы и TLS-клиенты
В качестве TLS-серверов и TLS-клиентов используются различные приложения. Например: сервер Apache и клиент Internet Explorer реализуют протокол https, сервер Dovecot и клиент Outlook реализуют протоколы POP3S и IMAPS, почтовый сервер Postfix является одновременно и клиентом и сервером протокола SMTPS, Outlook также может выступать в качестве клиента SMTPS при отправке сообщений на почтовый сервер.
Криптобиблиотеки, реализующие протокол TLS
Протокол TLS реализуют криптографические динамические библиотеки. В современных ОС Windows этот протокол может быть реализован с помощью Microsoft CryptoAPI. Кроме того, существует ряд Open Source-библиотек, реализующих протокол TLS, среди них библиотеки OpenSSL и GNU TLS. Наиболее распространенной является криптобиблиотека OpenSSL, работающая в большинстве существующих операционных систем.
Продукты, реализующие различные криптографические алгоритмы в TLS
В ООО «Криптоком» разработаны программные продукты, предоставляющие возможность использовать в TLS-соединениях российские криптографические алгоритмы ГОСТ.
Алгоритмы ГОСТ для библиотеки OpenSSL реализованы в подключаемом модуле engine, входящем в состав продукта МагПро КриптоПакет. Криптобиблиотека OpenSSL версии 0.9.8 не предназначена для подключения модуля, содержащего алгоритмы ГОСТ, поэтому МагПро КриптоПакет также включает в себя модифицированную версию библиотеки OpenSSL. Эта версия предоставляет всю функциональность, которую предоставляет библиотека OpenSSL версии 0.9.8, и имеет возможность работать с алгоритмами ГОСТ.
Библиотека OpenSSL версии 0.9.9 может подключать подгружаемый модуль engine, реализующий алгоритмы ГОСТ, поэтому для реализации протокола TLS на алгоритмах ГОСТ с помощью OpenSSL 0.9.9 достаточно только такого модуля.
МагПро КриптоПакет в TLS-соединении может использоваться как на стороне клиента, так и на стороне сервера.
Для реализации алгоритмов ГОСТ в ОС Windows с помощью Microsoft CryptoAPI в ООО > разработан криптопровайдер МагПро CSP. Он также может быть использован при реализации протокола TLS.
Аутентификация сервера
При установлении соединения, защищенного по протоколу TLS, непременно производится аутентификация сервера. Это делается для того, чтобы клиент мог быть уверен, что соединение установлено именно с тем сервером, с которым планируется обмен информацией, а не с каким-либо другим компьютером, выдающим себя за сервер.
Аутентификация сервера всегда является криптографической, т.е. выполняется с помощью сертификата сервера. У сервера обязательно должна быть ключевая пара, и клиент должен иметь возможность проверки подлинности сертификата, который сервер предоставляет ему для аутентификации. (Подробно об аутентификации сервера.)
Аутентификация клиента
Аутентификация клиента в протоколе TLS не является обязательной. Необходимость и способ аутентификации клиента определяется регламентом работы сервера.
Существует достаточно много случаев использования протокола TLS, когда достаточно уверенности клиента в том, что сервер, с которым он соединился, подлинный, и сессия будет защищена.
Аутентификация клиента может быть парольной и криптографической. При этом криптографическая аутентификация клиента является частью протокола TLS, а парольная аутентификация реализуется на прикладном уровне, т.е. средствами приложения.
При принятии решения о том, требовать ли с клиента криптографической аутентификации, следует учитывать, что эта аутентификация достаточно трудоемка и сложна для пользователя. Соответственно, требуется поддержка выдачи и отзыва клиентских сертификатов, пользователь должен соблюдать регламенты работы с долговременной ключевой информацией, поэтому криптографическая аутентификация клиентов применяется достаточно редко — только в таких критических приложениях, как, например, система WebMoney. И даже в таких приложениях, как правило, предусматривается альтернативный способ аутентификации, поскольку некоторые абонентские устройства, например мобильные телефоны, могут не поддерживать клиентские сертификаты.
Поэтому чаще всего используется аутентификация клиента по имени и паролю. В сочетании с криптографической аутентификацией сервера и последующей защитой канала это обеспечивает безопасность, достаточную для работы большинства приложений.
Защита данных
Цель защиты данных при TLS-соединении — сделать так, чтобы никто из тех, кто имеет возможность просматривать поток данных между клиентом и сервером, не мог извлечь из этого потока осмысленную информацию.
Защита данных при TLS-соединении реализуется с помощью шифрования всех передаваемых данных (в обе стороны). Для этого при каждом TLS-соединении вырабатываются специальные ключи для шифрования данных. Эти ключи называются сессионными (сессия — это однократное соединение от установления до разрыва соединения) и после завершения сессии уничтожаются без возможности восстановления.
Сразу после аутентификации сторон (или только сервера) происходит выработка и согласование ключей, которые будут использоваться для шифрования сессионных ключей. Для этого используются ключи сервера и клиента. Если у клиента нет долгосрочной ключевой пары (для соединения с сервером не требуется криптографической аутентификации), программа-клиент вырабатывает эфемерную ключевую пару, которая используется так же, как использовалась бы долгосрочная ключевая пара в этом случае.
Согласование ключей происходит без их передачи по каналу связи, т.к. защита канала еще не установлена.
Следует иметь в виду, что возможно TLS-соединение без защиты данных, только с взаимной аутентификацией или даже только с аутентификацией сервера. Такое соединение имеет смысл при передаче несекретных данных, особенно в больших объемах. При TLS-соединении без защиты данных крайне нежелательно использовать парольную аутентификацию клиента, т.к. в этом случае пароль передается в незашифрованном виде и может быть подсмотрен. Поэтому аутентификация клиента, если она применяется, в таком соединении должна быть криптографической.
При использовании протокола TLS есть возможность пользоваться различными криптографическими алгоритмами и использовать их различными способами. Эта возможность реализуется в виде различных наборов алгоритмов и особенностей протокола, которые можно использовать в TLS-соединениях. При каждом TLS-соединении используется один такой набор, причем он должен быть одинаковым у обеих сторон.
Такие наборы называются шифрсьютами (cipher suites).
У каждого программного продукта, реализующего протокол TLS, имеется некоторый определенный набор шифрсьютов, зависящий как от доступных алгоритмов, так и от собственно реализации протокола.
Такой набор шифрсьютов может быть расширяемым. То есть существует некоторый набор шифрсьютов, подключаемый при запуске приложения, использующего библиотеку OpenSSL, без дополнительных указаний. Этот набор включает не все доступные шифрсьюты. Если необходимы дополнительные шифрсьюты, они должны быть явно указаны в конфигурационном файле OpenSSL, и приложение должно вызывать их через обращение к этому файлу с помощью соответствующей функции (см. документ «Средство криптографической защиты информации МагПро КриптоПакет. Библиотека libssl. Руководство программиста (СЕИУ 00009-01 33 02)»).
В продукте МагПро КриптоПакет могут быть дополнительно подключены шифрсьюты без шифрования и без авторизации (анонимные шифрсьюты — используются в редчайших случаях).
Список доступных шифрсьютов можно получить командой openssl ciphers.
Шифрсьюты, включаемые по умолчанию:
GOST2001-GOST89-GOST89 и GOST94-GOST89-GOST89;
Дополнительные шифрсьюты без шифрования:
В данном случае в названиях шифрсьютов указываются соответственно по порядку: алгоритм выработки подписи и согласования ключей, алгоритм симметричного шифрования данных и алгоритм контроля целостности.
Ниже приводится расшифровка данных обозначений.
Расшифровка обозначений в шифрсьютах МагПро КриптоПакет
с использованием алгоритмов ГОСТ(Подробно о том, какие шифрсьюты включены в OpenSSL и какие алгоритмы включены в какой шифрсьют, можно узнать из man-руководства к команде ciphers.)
Понятие о хендшейке
«Хендшейк» (рукопожатие) — это фаза (часть) сессии TLS-соединения, во время которой обе стороны «представляются друг другу».
Хендшейк обязательно включает в себя аутентификацию сервера, при необходимости — аутентификацию клиента, согласование и выработку сессионных ключей.
Хендшейк обязательно выполняется в начале сессии TLS-соединения.
При установлении TLS-соединения программа-клиент и программа-сервер в первую очередь обмениваются информацией о доступных шифрсьютах и > о том, какой шифрсьют они будут использовать в данном соединении. Обычно выбор шифрсьюта производится по критерию наибольшей защищенности.
С того момента, как шифрсьют выбран, дальнейший хендшейк зависит от выбранного шифрсьюта. В частности, шифрсьютом определяется способ аутентификации сервера (и клиента).
Можно повторить хендшейк, заново провести аутентификацию и согласовать новые ключи, не прерывая сессии. Эта возможность используется, например, в тех случаях, если в момент начального хендшейка не проводится аутентификация клиента, а потом в ходе сессии становится понятным, что аутентификация клиента требуется, и какая именно аутентификация клиента требуется — парольная или криптографическая.
Поскольку фаза хендшейка достаточно трудоемка, для протокола TLS существует техническая возможность сохранения сессии и последующего ее возобновления. Это особенно актуально для протоколов, которые часто создают и закрывают TCP/IP соединения, например http.
В продукте МагПро КриптоПакет это не реализовано, потому что в нем используется дополнительная защита keymeshing (см. RFC 4357) — сессионные ключи меняются через каждый килобайт переданных данных. Поэтому сохранение сессии (т.е. взаимосогласованных ключей) технически крайне затруднено.
Строение сессии TLS-соединения
Хендшейк. Обмен шифрсьютами. Аутентификация сервера. Если необходимо — аутентификация клиента, выработка и согласование сессионных ключей для защиты данных.
Обмен данными в обе стороны. Данные зашифровываются программой-отправителем на сессионных ключах, передаются, принимаются программой-получателем и расшифровываются. Выполняются проверки целостности данных.
В ходе сессии могут выполняться также повтоные хендшейки.
Аутентификация сервера > цепочек доверия.
Чтобы корневой сертификат удостоверяющего центра был доверенным, необходимо либо получить его по надежному каналу (по какому-либо закрытому каналу связи либо непосредственно в удостоверяющем центре), либо получить по аналогичному надежному каналу его контрольную сумму (т.наз. fingerprint) и при установке сертификата удостоверяющего центра сравнить продемонстрированную контрольную сумму с имеющейся.
Статус сертификата
У каждого сертификата имеется ограниченный срок действия, в сертификате указываются даты начала и конца срока действия. Если текущее время на машине, проверяющей сертификат, не попадает в период между этими датами, сертификат считается некорректным.
Списки отзыва сертификатов
Удостоверяющий центр может отозвать сертификат. Отзыв сертификата производится, например, если скомпрометированы ключи. Возможны и другие причины отзыва, например прекращение деятельности организации, которой выдан сертификат.
Для отзыва сертификатов удостоверяющий центр выпускает и распространяет по всем своим пользователям список отзыва сертификатов (certificate revocation list — CRL).
Процедура проверки корректности сертификата может включать или не включать проверку списка отзыва сертификатов. Как правило, решение об использовании списка отзыва сертификатов определяется регламентом удостоверяющего центра.
Библиотека OpenSSL предоставляет возможность проверки списка отзыва сертификатов, но по умолчанию такая проверка не проводится. Для того, чтобы такая проверка производилась, необходимо явным образом это указать.
Срок действия списка отзыва, как правило, заметно меньше, чем срок действия сертификата. Поэтому если списки отзыва используются, они должны регулярно обновляться.
Если в конфигурации указан устаревший список отзыва, то все сертификаты, выданные удостоверяющим центром, которому принадлежит данный список отзыва, будут считаться некорректными.
Онлайн-протокол проверки статуса сертификатов
Существует альтернативный способ проверки отзыва сертификатов — так называемый online-протокол проверки статуса сертификата (OCSP).
Для использования этого протокола необходимо наличие сервера, обычно принадлежащего удостоверяющему центру, который располагает актуальной информацией о статусе сертификатов, выпущенных этим удостоверяющим центром, и имеет специальный ключ, область применения которого — подпись OCSP-ответов.
В случае использования OCSP-сервера нет необходимости копировать списки отзыва на все машины, где может понадобиться проверка сертификатов. Статус сертификата запрашивается с сервера непосредственно в момент проверки.
Проверка принадлежности серверных сертификатов
Поскольку сертификаты серверов передаются открыто, то существует возможность, что злоумышленник, притворяющийся сервером, просто возьмет сертификат соответствующего сервера и отдаст его для аутентификации. Поэтому при аутентификации необходимо убедиться, что сертификат действительно принадлежит именно этому серверу.
Для этого следует убедиться, что у сервера есть не только сертификат, но и соответствующий ему закрытый ключ.
- Клиент высылает серверу некоторый набор данных, заранее неизвестный серверу.
- Сервер подписывает этот набор данных на своем закрытом ключе и пересылает результат обратно клиенту.
- Клиент, которому исходные данные известны, проверяет подпись под ними, пользуясь сертификатом сервера.
Таким образом, клиент убеждается, что сервер располагает не только данным сертификатом, но и соответствующим сертификату закрытым ключом.
Сертификат сервера и DNS
Любой сертификат на открытый ключ включает информацию о том, кто является его владельцем. В случае сертификатов серверов TLS это выполняется с помощью указания сетевого имени (DNS) сервера в поле CommonName.
Если сервер имеет несколько сетевых имен, то аутентификация считается успешной только в том случае, если предъявленный сервером сертификат соответствует именно тому сетевому имени, которое клиент использовал для установления соединения.
Необходимо иметь в виду, что если при аутентификации происходит ошибка (сетевое имя не совпадает с указанным в сертификате), большинство приложений дает возможность все-таки установить TLS-соединение. При этом выводится диалоговое окно, содержащее предупреждение следующего содержания:
Вы попытались установить соединение с [сетевое имя сервера]. Однако представленный сертификат безопасности принадлежит [сетевое имя, указанное в сертификате]. Имеется вероятность, хотя и небольшая, что кто-то может попытаться перехватить ваше соединение с этим вебсайтом.
Если вы подозреваете, что показанный сертификат не принадлежит [сетевое имя сервера], пожалуйста, откажитесь от соединения и уведомите администратора сайта.
- Просмотреть сертификат
- Ок (установить TLS-соединение)
- Отмена (отказаться от TLS-соединения)
- Помощь (справка)
В этом случае ответственность за безопасность устанавливаемого TLS-соединения полностью берет на себя пользователь.
Такая ситуация может возникнуть, например, если в сертификате указано сетевое имя вида http://www.name.com, а пользователь пытается установить соединение, используя сетевое имя вида http://name.com.
Следует также обратить внимание, что аутентификация сервера производится до того, как клиент передал какие-то данные прикладного протокола (например протокола http — скажем, на какую страницу он хочет попасть). Поэтому в момент аутентификации серверу ничего не известно о клиенте и о том, что клиент будет запрашивать у сервера. Известен только IP-адрес, на который пришел клиент (даже в том случае, если у сервера их несколько, к началу аутентификации уже известно, к какому IP-адресу обратился клиент).
либо эти сервера должны использовать сертификат, соответствующий всем этим именам сразу (т.е. в CommonName указать *.domain);
либо указать все сетевые имена этих серверов в поле сертификата SubjectAltName, которое позволяет указать несколько имен;
Типичные ошибки при работе с сертификатами
Самоподписанный сертификат сервера
Многие программы-сервера при установке предлагают установить самоподписанный сертификат сервера. Следует обязательно иметь в виду, что такой сертификат не предоставляет никакой гарантии безопасности соединения. При проверке отличить такой сертификат от любого другого сертификата с тем же доменным именем невозможно, поэтому его очень легко подменить. Самоподписанный сертификат сервера можно использовать только для проверки работоспособности установленного сервера.
Установка корневого сертификата удостоверяющего центра — отдельное, явное и контролируемое пользователем действие, которое предпринимается в начале работы с сервисом. Пользователь точно знает, что за сертификат он установил, выполняет проверку цифрового отпечатка (fingerprint), который также необходимо получить. После того, как корневой сертификат удостоверяющего центра установлен в системе и помещен в соответствующее хранилище доверенных сертификатов, пользователь получает возможность надежной аутентификации сервера по сертификату сервера, подписанному на корневом сертификате удостоверяющего центра.
В состав дистрибутивов операционных систем и криптографических программ включаются корневые сертификаты некоторых удостоверяющих центров. Это делается для того, чтобы криптографические программы с момента установки считали эти удостоверяющие центры доверенными и могли работать с сертификатами, выданными этими удостоверяющими центрами. Так, в состав ОС Windows входят корневые сертификаты известного удостоверяющего центра VeriSign. Среди таких предустановленных сертификатов в настоящее время нет ни одного сертификата с алгоритмами ГОСТ.
Пользователям обязательно следует учитывать, что данные корневые сертификаты часто являются доверенными исключительно с технической точки зрения (т.к. они установлены в соответствующем хранилище). На самом деле считать их доверенными нельзя, потому что пользователь при установке этих сертификатов не имел возможность проверить их корректность путем сверки цифрового отпечатка.
Способы хранения сертификатов удостоверяющих центров
Текстовый файл, в котором содержатся все необходимые сертификаты и списки отзывов в PEM-формате.
В утилите openssl такой файл указывается с помощью опции -CAfile.
Недостаток этого способа — содержимое файла полностью загружается в память. Поэтому при использовании большого количества УЦ или при использовании УЦ с объемными CRL лучше использовать второй способ.
Каталог, в котором содержатся сертификаты и CRL в виде отдельных файлов.
Для удобства и быстроты работы с сертификатами в этом каталоге следует использовать утилиту c_rehash, которая создает ссылки на файлы сертификатов, содержащихся в каталоге-хранилище, с именами в виде шестнадцатеричных тридцатидвухбитных хэш-сумм наименований удостоверяющих центров. Благодаря наличию таких хэшированных имен библиотека OpenSSL может мгновенно найти нужный сертификат или CRL.
В этом случае размеры и количество файлов неограничены, так как в процессе работы читается и загружается только нужная информация.
Поскольку утилита c_rehash работает только с файлами с расширением .pem, следует помещать файлы сертификатов и CRL в каталог-хранилище именно с таким расширением.
В принципе, библиотека OpenSSL позволяет реализовать любые другие способы хранения сертификатов, например в базе данных или LDAP-каталоге. Но с подобными реализациями должно работать непосредственно приложение (см. соответствующий раздел руководства программиста по libcrypto).
Хранение собственного сертификата сервера и его закрытого ключа
Как правило, собственный сертификат сервера и его закрытый ключ хранятся непосредственно на сервере либо в отдельных файлах, либо в одном текстовом файле в PEM-формате.
Защита собственного сертификата сертификата сервера и его закрытого ключа должна осуществляться с помощью прав доступа файловой системы.
Закрытый ключ также может быть дополнительно защищен паролем (пассфразой). Но в таком случае при каждой перезагрузке сервера кто-то должен вводить этот пароль, что не всегда возможно (в частности, если перезагрузка выполняется дистанционно).
Поэтому для серверных приложений обычно используют закрытые ключи, защищенные только правами доступа файловой системы. Для интерактивных приложений лучше использовать ключи, защищенные на пароле.
Некоторые приложения, например OpenVPN, позволяют хранить собственные сертификаты и ключ в формате PKCS#12.
Хранение сертификатов промежуточных удостоверяющих центров
Форматы кодирования криптографических документов DER и PEM
OpenSSL поддерживает два основных формата, определяющих кодирование криптографических документов: DER и PEM.
DER — бинарные файлы.
PEM — текстовые файлы.
Криптографический документ в формате PEM имеет вид
-----BEGIN ----- -----END -----
Т.е. содержание документа окружается заголовками специального вида, состоящими из пяти знаков «-», слов begin и end и указания типа документа (CERTIFICATE, CRL и т.д.)
Благодаря наличию таких заголовков в одном файле может содержаться несколько документов в формате PEM: например, цепочка сертификатов или сертификат и его закрытый ключ.
По умолчанию в OpenSSL используется именно формат PEM.
Форматы, определяющие структуру файлов, содержащих криптографическую информацию
Файлы, содержащие цепочки сертификатов, сертификаты и ассоциированные с ними ключи, могут представляться в нескольких форматах, определяющих состав и строение файлов, содержащих ключевую информацию; сама эта информация кодируется в вышеописанных форматах PEM и DER.
PKCS#7 — формат защищенных сообщений, который, кроме самого сообщения, может содержать необходимые для работы с ним сертификаты и CRL.
Многие удостоверяющие центры распространяют свои сертификаты и CRL в виде PKCS#7-документов, в которых нет сообщения, есть только служебная информация.
PKCS#7-документ может быть закодирован и формате DER, и в формате PEM.
Расширения файлов сертификатов могут быть .cer или .crt . Расширение служебных PKCS#7-сообщений обычно бывает .p7b или .p7f. Эти расширения никак не коррелируют с форматами DER и PEM, т.е. файл с любым из этих расширений может быть закодирован как в формате DER, так и в формате PEM.
PKCS#12 — формат для переноса сертификата и связанного с ним закрытого ключа с машины на машину или для резервного копирования. В этом формате могут также содержаться сертификаты удостоверяющего центра.
Файлы формата PKCS#12 всегда кодируются в формате DER. Эти файлы требуют особенно пристального внимания, поскольку содержат закрытый ключ; при неосторожном обращении с таким файлом закрытый ключ легко скомпрометировать. Как правило, эти файлы защищены на пароле.
Расширение файлов формата PKCS#12 либо .p12, либо .pfx .
OpenSSL предоставляет возможность преобразования файлов в формате DER в формат PEM. Для этого используются команды:
openssl x509 -in filename.der -inform der -out filename.pem
Для списков отзывов:
openssl crl -in filename.der -inform der -out filename.pem
openssl pkcs7 -in filename.der -inform der -out filename.pem
Для извлечения сертификатов из сообщений формата PKCS#7:
openssl pkcs7 -in filename.pem -print\_certs