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 1.2 с российскими криптонаборами.

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

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

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

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

Заключение

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

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

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

Источник

Шифрование TLS-трафика по алгоритмам ГОСТ-2012 c Stunnel

В этой статье я хочу показать, как настроить Stunnel на использование российских криптографических алгоритмов в протоколе TLS. В качестве бонуса покажу, как шифровать TLS-канал, используя алгоритмы ГОСТ, реализованные в криптоядре Рутокен ЭЦП 2.0.

Но для начала давайте вообще разберёмся для чего нужен Stunnel. В двух словах — это программа, на которую можно переложить всю логику шифрования трафика между сервером и клиентом. Делается это следующем образом: допустим у вас есть клиент и сервер, которые общаются между собой без использования шифрования, аутентификации и проверки целостности. Вы могли бы переписать клиент и сервер так, чтобы все исходящие и входящие сообщения передавались между собой с учётом всех этих моментов, но для чего такие сложности, если можно это просто переложить на плечи другому приложения? Для решения такой задачи как раз подойдёт Stunnel.

Вам нужно просто настроить клиент таким образом, чтобы весь свой трафик он передавал на клиентский Stunnel, в свою очередь, он устанавливает безопасное соединение с сервером, отправляя данные на серверный Stunnel. Stunnel на сервере расшифровывает пришедший трафик и перенаправляет данные на вход серверу. Вышесказанное проще осознать глядя на эту диаграмму

Стоит заметить, что на сервере не обязательно должен стоять именно Stunnel, для работы с криптографическими алгоритмами. Здорово, что есть готовые демонстрационные стенды, которые поддерживают российскую криптографию, список которых есть в презентации с РусКрипто’2019.

Нам нужны стабильно работающие серверы, осуществляющие двухстороннюю аутентификацию.
Мы выбрали серверы КриптоПро как наиболее надёжные с полной реализацией стандарта ГОСТ TLS. Спасибо им за это 🙂

Звучит достаточно просто, давайте попробуем организовать этот процесс.

Подготовительный шаг

OpenSSL для Windows можно взять отсюда, а для пользователей линукса — из репозиториев или собрать самому, скачав свежую версию отсюда. Также его можно взять из Rutoken SDK, из директории openssl\openssl-tool-1.1, этот архив нам будет полезен и дальше, т.к. в нём находится интересующий нас rtengine. Stunnel можно найти здесь. Для работы необходима версия >= 5.56.

Скачать rtengine можно из Rutoken SDK, он лежит в директории openssl\rtengine\bin. Закинуть его нужно туда, где хранятся все движки openssl. Узнать путь до них можно с помощью

Но просто переместить движок в нужную папку — мало, нужно ещё сконфигурировать сам openssl для работы с ним. Узнаём где лежит файл с конфигурацией openssl.cnf с помощью той же команды, что указана выше (под виндой stunnel идёт с собственной версией openssl, поэтому файл с конфигурацией лежит в path\to\stunnel\config\openssl.cnf

Давайте проверим, что rtengine подключился, для этого подключим токен и выведем список всех алгоритмов шифрования:

Напомню, что в Windows нужно проверять на openssl, который лежит рядом с stunnel
Если среди них будут присутствовать наши ГОСТы, значит всё настроено верно.

Настало время самого интересного: проверка установки соединения по ГОСТу с тестовыми серверами КриптоПро. Список данных серверов описан здесь (https://www.cryptopro.ru/products/csp/tc26tls). Каждый из этих серверов работает со своими алгоритмами для аутентификации и шифрования. Более того на портах 443, 1443, 2443,… запущены сервисы, которые воспринимают только определённые парамсеты. Так, например, по адресу http://tlsgost-256auth.cryptopro.ru происходит шифрование с аутентификацией с использованием алгоритмов GOST2012-GOST8912-GOST8912 и 256-битным ключом. Так же на порту 443 используется XchA-ParamSet, на порту 1443 — XchB-ParamSet, на порту 2443 — A-ParamSet и т.д.

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

Простой способ (работает под Windows и Linux)

Через командную строку

Для того, чтобы получить корневой сертификат, зайдём на сайт тестового УЦ ООО «КРИПТО-ПРО». И нажмём на кнопку для получения сертификата. Отобразится новая вкладка, в которой нужно будет выбрать метод шифрования Base64 и нажать на кнопку «Загрузка сертификата ЦС». Полученный файл certnew.cer сохраняем.

Теперь генерируем ключи.

Стоит заметить, что сгенерированные на токене ключи не могут быть скопированы с токена. В этом состоит одно из основных преимуществ их использования.

Создадим запрос на сертификат:

Опять открываем сайт тестового УЦ, но на этот раз нажимаем на кнопку «Отправить готовый запрос PKCS#10 или PKCS#7 в кодировке Base64». Вставляем в поле содержимое нашего запроса, нажимаем на кнопку Выдать и загружаем сертификат user.crt в формате Base64. Полученный файл сохраняем

Остался последний вопрос: Для чего всё это. Зачем мы получали все эти сертификаты, ключи и запросы?

Дело в том, что они нужны протоколу TLS для двусторонней аутентификации. Работает это очень просто.

У нас есть сертификат сервера, и мы считаем его доверенным.

Наш клиент проверяет, что сервер, с которым мы работаем имеет аналогичный сертификат.
Сервер же хочет убедиться, что работает с пользователем, который ему известен. Для этого мы и создавали запрос на сертификат для работы через наши ключи.

Мы отправили этот запрос и сервер подписал её своей ЭЦП. Теперь мы можем каждый раз предъявлять этот сертификат, подписанный корневым УЦ, тем самым подтверждая, что мы — это мы.

Конфигурирование Stunnel

Осталось только правильно настроить наш туннель. Для этого создадим файл stunnel.conf с настройками Stunnel по умолчанию и напишем туда следующее:

Теперь, если всё сделано правильно, можно запустить Stunnel с нашей конфигурацией и подключиться к серверу:

Откроем браузер и зайдём по адресу localhost:8080. Если всё верно, то отобразится следующее:

Если же нет, то смотрим логи и используем отладчик, чтобы понять в чём же всё-таки проблема.

Если у вас остались какие-то вопросы, то милости просим в комментарии 🙂

Источник

Tls гост что это

Протокол TLS с поддержкой алгоритмов ГОСТ.

Понятие о протоколе TLS

Протоколы защиты соединений

Существуют различные протоколы защиты соединений, реализующие шифрование на различных уровнях: на сетевом, на транспортном или на прикладном.

Сетевые протоколы — это защита не одного конкретного соединения, а целой сети. Подключение к защищенной сети автоматически предоставляет пользователю доступ ко всей информации, циркулирующей по этой сети. Такой подход удобен, например, для корпоративного взаимодействия (локальная сеть или ее распределенный аналог), но совершенно не подходит для взаимодействия, например, с клиентами. Примеры сетевого протокола — различные протоколы, на основании которых строятся сети VPN: IPSec, PPTP, OpenVPN.

Прикладные протоколы предназначены для решения конкретных специализированных задач и требуют использования соответствующего программного обеспечения, зачастую нестандартного и непривычного для пользователя. Пример прикладного протокола — протокол ssh.

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

Протокол TLS и протоколы интернет-соединений

Протокол TLS может использоваться для защиты соединений практически по всем распространенным интернет-протоколам. Например, всем известный протокол https — это интернет-соединение по протоколу http, защищенное по протоколу TLS. Кроме того, по протоколу TLS могут быть защищены соединения по протоколу FTP, по протоколам IMAP, POP3 и SMTP (передача электронной почты) и т.д.

Программное обеспечение, реализующее протокол 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.

МагПро CSP в TLS-соединении может использоваться только на стороне клиента.

Описание протокола 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.

Продукт МагПро КриптоПакет содержит все шифрсьюты, включенные в библиотеку OpenSSL, а также шифрсьюты, включающие алгоритмы ГОСТ:

Шифрсьюты, включаемые по умолчанию:

GOST2001-GOST89-GOST89 и GOST94-GOST89-GOST89;

Дополнительные шифрсьюты без шифрования:

GOST94-NULL-GOST94 и GOST2001-NULL-GOST94

В данном случае в названиях шифрсьютов указываются соответственно по порядку: алгоритм выработки подписи и согласования ключей, алгоритм симметричного шифрования данных и алгоритм контроля целостности.

Ниже приводится расшифровка данных обозначений.

Расшифровка обозначений в шифрсьютах МагПро КриптоПакет
с использованием алгоритмов ГОСТ

(Подробно о том, какие шифрсьюты включены в OpenSSL и какие алгоритмы включены в какой шифрсьют, можно узнать из man-руководства к команде ciphers.)

Понятие о хендшейке

«Хендшейк» (рукопожатие) — это фаза (часть) сессии TLS-соединения, во время которой обе стороны «представляются друг другу».

Хендшейк обязательно включает в себя аутентификацию сервера, при необходимости — аутентификацию клиента, согласование и выработку сессионных ключей.

Хендшейк обязательно выполняется в начале сессии TLS-соединения.

При установлении TLS-соединения программа-клиент и программа-сервер в первую очередь обмениваются информацией о доступных шифрсьютах и > о том, какой шифрсьют они будут использовать в данном соединении. Обычно выбор шифрсьюта производится по критерию наибольшей защищенности.

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

Можно повторить хендшейк, заново провести аутентификацию и согласовать новые ключи, не прерывая сессии. Эта возможность используется, например, в тех случаях, если в момент начального хендшейка не проводится аутентификация клиента, а потом в ходе сессии становится понятным, что аутентификация клиента требуется, и какая именно аутентификация клиента требуется — парольная или криптографическая.

Поскольку фаза хендшейка достаточно трудоемка, для протокола TLS существует техническая возможность сохранения сессии и последующего ее возобновления. Это особенно актуально для протоколов, которые часто создают и закрывают TCP/IP соединения, например http.

В продукте МагПро КриптоПакет это не реализовано, потому что в нем используется дополнительная защита keymeshing (см. RFC 4357) — сессионные ключи меняются через каждый килобайт переданных данных. Поэтому сохранение сессии (т.е. взаимосогласованных ключей) технически крайне затруднено.

Строение сессии TLS-соединения

Таким образом, типичная сессия TLS-соединения устроена так:

Хендшейк. Обмен шифрсьютами. Аутентификация сервера. Если необходимо — аутентификация клиента, выработка и согласование сессионных ключей для защиты данных.

Обмен данными в обе стороны. Данные зашифровываются программой-отправителем на сессионных ключах, передаются, принимаются программой-получателем и расшифровываются. Выполняются проверки целостности данных.

В ходе сессии могут выполняться также повтоные хендшейки.

При разрыве соединения автоматически происходит закрытие сессии (возможно, с ее сохранением).

Аутентификация сервера > цепочек доверия.

Чтобы корневой сертификат удостоверяющего центра был доверенным, необходимо либо получить его по надежному каналу (по какому-либо закрытому каналу связи либо непосредственно в удостоверяющем центре), либо получить по аналогичному надежному каналу его контрольную сумму (т.наз. fingerprint) и при установке сертификата удостоверяющего центра сравнить продемонстрированную контрольную сумму с имеющейся.

Статус сертификата определяется двумя параметрами: сроками действия сертификата и фактом его отзыва/неотзыва.

У каждого сертификата имеется ограниченный срок действия, в сертификате указываются даты начала и конца срока действия. Если текущее время на машине, проверяющей сертификат, не попадает в период между этими датами, сертификат считается некорректным.

Списки отзыва сертификатов

Удостоверяющий центр может отозвать сертификат. Отзыв сертификата производится, например, если скомпрометированы ключи. Возможны и другие причины отзыва, например прекращение деятельности организации, которой выдан сертификат.

Для отзыва сертификатов удостоверяющий центр выпускает и распространяет по всем своим пользователям список отзыва сертификатов (certificate revocation list — CRL).

Процедура проверки корректности сертификата может включать или не включать проверку списка отзыва сертификатов. Как правило, решение об использовании списка отзыва сертификатов определяется регламентом удостоверяющего центра.

Библиотека OpenSSL предоставляет возможность проверки списка отзыва сертификатов, но по умолчанию такая проверка не проводится. Для того, чтобы такая проверка производилась, необходимо явным образом это указать.

Срок действия списка отзыва, как правило, заметно меньше, чем срок действия сертификата. Поэтому если списки отзыва используются, они должны регулярно обновляться.

Если в конфигурации указан устаревший список отзыва, то все сертификаты, выданные удостоверяющим центром, которому принадлежит данный список отзыва, будут считаться некорректными.

Онлайн-протокол проверки статуса сертификатов

Существует альтернативный способ проверки отзыва сертификатов — так называемый online-протокол проверки статуса сертификата (OCSP).

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

В случае использования OCSP-сервера нет необходимости копировать списки отзыва на все машины, где может понадобиться проверка сертификатов. Статус сертификата запрашивается с сервера непосредственно в момент проверки.

К сожалению, не все программное обеспечение, использующее OpenSSL, поддерживает работу с OCSP.

Проверка принадлежности серверных сертификатов

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

Для этого следует убедиться, что у сервера есть не только сертификат, но и соответствующий ему закрытый ключ.

Таким образом, клиент убеждается, что сервер располагает не только данным сертификатом, но и соответствующим сертификату закрытым ключом.

Сертификат сервера и DNS

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

Если сервер имеет несколько сетевых имен, то аутентификация считается успешной только в том случае, если предъявленный сервером сертификат соответствует именно тому сетевому имени, которое клиент использовал для установления соединения.

Необходимо иметь в виду, что если при аутентификации происходит ошибка (сетевое имя не совпадает с указанным в сертификате), большинство приложений дает возможность все-таки установить TLS-соединение. При этом выводится диалоговое окно, содержащее предупреждение следующего содержания:

Вы попытались установить соединение с [сетевое имя сервера]. Однако представленный сертификат безопасности принадлежит [сетевое имя, указанное в сертификате]. Имеется вероятность, хотя и небольшая, что кто-то может попытаться перехватить ваше соединение с этим вебсайтом.

Если вы подозреваете, что показанный сертификат не принадлежит [сетевое имя сервера], пожалуйста, откажитесь от соединения и уведомите администратора сайта.

В этом случае ответственность за безопасность устанавливаемого TLS-соединения полностью берет на себя пользователь.

Такая ситуация может возникнуть, например, если в сертификате указано сетевое имя вида http://www.name.com, а пользователь пытается установить соединение, используя сетевое имя вида http://name.com.

Следует также обратить внимание, что аутентификация сервера производится до того, как клиент передал какие-то данные прикладного протокола (например протокола http — скажем, на какую страницу он хочет попасть). Поэтому в момент аутентификации серверу ничего не известно о клиенте и о том, что клиент будет запрашивать у сервера. Известен только IP-адрес, на который пришел клиент (даже в том случае, если у сервера их несколько, к началу аутентификации уже известно, к какому IP-адресу обратился клиент).

Соответственно, если на одном и том же IP-адресе находятся несколько серверов с разными сетевыми именами (DNS), то необходимо использовать один из трех следующих вариантов:

либо эти сервера должны использовать сертификат, соответствующий всем этим именам сразу (т.е. в CommonName указать *.domain);

либо указать все сетевые имена этих серверов в поле сертификата SubjectAltName, которое позволяет указать несколько имен;

либо использовать TLS только на одном из сетевых имен.

Типичные ошибки при работе с сертификатами

Многие операционные системы и криптографические программы уже включают в себя готовые сертификаты и либо предлагают их к установке, либо устанавливают по умолчанию. В данном разделе объясняется, к каким проблемам может привести использование таких сертификатов.

Самоподписанный сертификат сервера

Многие программы-сервера при установке предлагают установить самоподписанный сертификат сервера. Следует обязательно иметь в виду, что такой сертификат не предоставляет никакой гарантии безопасности соединения. При проверке отличить такой сертификат от любого другого сертификата с тем же доменным именем невозможно, поэтому его очень легко подменить. Самоподписанный сертификат сервера можно использовать только для проверки работоспособности установленного сервера.

Любой удостоверяющий центр, даже простейший (например на базе утилиты openssl), предоставляет гораздо более надежную гарантию защиты. Потому что:

Установка корневого сертификата удостоверяющего центра — отдельное, явное и контролируемое пользователем действие, которое предпринимается в начале работы с сервисом. Пользователь точно знает, что за сертификат он установил, выполняет проверку цифрового отпечатка (fingerprint), который также необходимо получить. После того, как корневой сертификат удостоверяющего центра установлен в системе и помещен в соответствующее хранилище доверенных сертификатов, пользователь получает возможность надежной аутентификации сервера по сертификату сервера, подписанному на корневом сертификате удостоверяющего центра.

Для того чтобы при правильных действиях пользователя получить возможность успешной атаки на TLS-соединение, злоумышленнику необходимо перехватить не только собственно TLS-сессию, но и канал, по которому пользователь получает сертификат удостоверяющего центра и его цифровой отпечаток (fingerprint). Даже если пользователь получает все эти данные по незащищенному http-соединению, задача атакующего многократно усложняется.

В состав дистрибутивов операционных систем и криптографических программ включаются корневые сертификаты некоторых удостоверяющих центров. Это делается для того, чтобы криптографические программы с момента установки считали эти удостоверяющие центры доверенными и могли работать с сертификатами, выданными этими удостоверяющими центрами. Так, в состав ОС Windows входят корневые сертификаты известного удостоверяющего центра VeriSign. Среди таких предустановленных сертификатов в настоящее время нет ни одного сертификата с алгоритмами ГОСТ.

Пользователям обязательно следует учитывать, что данные корневые сертификаты часто являются доверенными исключительно с технической точки зрения (т.к. они установлены в соответствующем хранилище). На самом деле считать их доверенными нельзя, потому что пользователь при установке этих сертификатов не имел возможность проверить их корректность путем сверки цифрового отпечатка.

Часто неопытные пользователи считают, что клиентские и серверные сертификаты необходимо получать именно в тех удостоверяющих центрах, чьи корневые сертификаты установлены в системе по умолчанию. Это на самом деле не так. Можно использовать любой удостоверяющий центр, если все участники криптопротокола (сервер и клиенты) установят его корневой сертификат как доверенный.

Способы хранения сертификатов удостоверяющих центров

OpenSSL поддерживает два основных способа хранения сертификатов удостоверяющих центров:

Текстовый файл, в котором содержатся все необходимые сертификаты и списки отзывов в PEM-формате.

Недостаток этого способа — содержимое файла полностью загружается в память. Поэтому при использовании большого количества УЦ или при использовании УЦ с объемными CRL лучше использовать второй способ.

Каталог, в котором содержатся сертификаты и CRL в виде отдельных файлов.

Для удобства и быстроты работы с сертификатами в этом каталоге следует использовать утилиту c_rehash, которая создает ссылки на файлы сертификатов, содержащихся в каталоге-хранилище, с именами в виде шестнадцатеричных тридцатидвухбитных хэш-сумм наименований удостоверяющих центров. Благодаря наличию таких хэшированных имен библиотека OpenSSL может мгновенно найти нужный сертификат или CRL.

В этом случае размеры и количество файлов неограничены, так как в процессе работы читается и загружается только нужная информация.

В принципе, библиотека OpenSSL позволяет реализовать любые другие способы хранения сертификатов, например в базе данных или LDAP-каталоге. Но с подобными реализациями должно работать непосредственно приложение (см. соответствующий раздел руководства программиста по libcrypto).

Хранение собственного сертификата сервера и его закрытого ключа

Как правило, собственный сертификат сервера и его закрытый ключ хранятся непосредственно на сервере либо в отдельных файлах, либо в одном текстовом файле в PEM-формате.

Защита собственного сертификата сертификата сервера и его закрытого ключа должна осуществляться с помощью прав доступа файловой системы.

Закрытый ключ также может быть дополнительно защищен паролем (пассфразой). Но в таком случае при каждой перезагрузке сервера кто-то должен вводить этот пароль, что не всегда возможно (в частности, если перезагрузка выполняется дистанционно).

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

Некоторые приложения, например OpenVPN, позволяют хранить собственные сертификаты и ключ в формате PKCS#12.

Хранение сертификатов промежуточных удостоверяющих центров

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

Приложение. Форматы хранения криптографической информации

Форматы кодирования криптографических документов DER и PEM

OpenSSL поддерживает два основных формата, определяющих кодирование криптографических документов: DER и PEM.

DER — бинарные файлы.

PEM — текстовые файлы.

Криптографический документ в формате PEM имеет вид

Т.е. содержание документа окружается заголовками специального вида, состоящими из пяти знаков «-», слов begin и end и указания типа документа (CERTIFICATE, CRL и т.д.)

Благодаря наличию таких заголовков в одном файле может содержаться несколько документов в формате PEM: например, цепочка сертификатов или сертификат и его закрытый ключ.

По умолчанию в OpenSSL используется именно формат PEM.

Форматы, определяющие структуру файлов, содержащих криптографическую информацию

Файлы, содержащие цепочки сертификатов, сертификаты и ассоциированные с ними ключи, могут представляться в нескольких форматах, определяющих состав и строение файлов, содержащих ключевую информацию; сама эта информация кодируется в вышеописанных форматах PEM и DER.

Наиболее распространенные из форматов, определяющих структуру файлов, содержащих криптографическую информацию — PKCS#7 и PKCS#12.

PKCS#7 — формат защищенных сообщений, который, кроме самого сообщения, может содержать необходимые для работы с ним сертификаты и CRL.

Многие удостоверяющие центры распространяют свои сертификаты и CRL в виде PKCS#7-документов, в которых нет сообщения, есть только служебная информация.

PKCS#7-документ может быть закодирован и формате DER, и в формате PEM.

PKCS#12 — формат для переноса сертификата и связанного с ним закрытого ключа с машины на машину или для резервного копирования. В этом формате могут также содержаться сертификаты удостоверяющего центра.

Файлы формата PKCS#12 всегда кодируются в формате DER. Эти файлы требуют особенно пристального внимания, поскольку содержат закрытый ключ; при неосторожном обращении с таким файлом закрытый ключ легко скомпрометировать. Как правило, эти файлы защищены на пароле.

OpenSSL предоставляет возможность преобразования файлов в формате DER в формат PEM. Для этого используются команды:

Для списков отзывов:

Для извлечения сертификатов из сообщений формата PKCS#7:

Источник