ГОСТ Р ИСО/МЭК 17826-2015
описано ниже. Хотя клиент должен упорядочить список по увеличению «силы» криптосистемы, сервер может вы
брать ЛЮБУЮ из предложенных клиентом криптосистем. Таким образом, НЕ гарантируется, что при таком обмене
будет выбрана самая надежная криптосистема. Если взаимно поддерживаемых криптосистем нет. соединение раз
рывается. Когда обмен согласований, использующих опциональные сертификаты открытых ключей и случайные
данный для генерации ключа, используемого в криптографическом алгоритме, завершен, производится обмен спе
циальными сообщениями для переключения соединения в защищенный режим.
Для обеспечения хотя бы минимального уровня безопасности и совместимости реализаций все клиенты и
серверы CDMI должны поддерживать:
- криптосистему TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (индекс {0x0013}). обязательную криптосит-
сему для TLS 1.0 (см. RFC 2246 раздел 9);
- криптосистему TLS_RSA_W1TH_AES_128_CBC_SHA (индекс {0x002F}). обязательную для TLS 1.2:
- криптосистема TLS_RSA_WITH_NULL_SHA (индекс {0x0002}) должна поддерживаться CDMI клиентами
и серверами для обеспечения аутентифицированного незашифрованного соединения. При использовании этой
криптосистемы не следует использовать базовую аутентификацию HTTP:
- криптосистема TLS_RSA_WITH_AES_128_CBC_SHA256 (индекс {ОхООЗС})должна поддерживаться всеми
реализациями с рекомендованным стандартом TLS 1.2 в рамках перехода к 112-битному шифрованию.
Разработчики вправе использовать дополнительные криптосистемы.
А.5.2 Цифровые сертификаты
Клиенты и серверы CDMI могут быть атакованы с использованием фальшивого CDMI сервера для полу
чения идентификатора и пароля пользователя или с использованием ненаблюдаемого прокси между клиентом и
сервером CDMI. Наиболее эффективная контрмера против такой атаки - проверка клиентом сертификата сервера
посредством TLS. в предположении, что фальшивый сервер не сможет получить правильный сертификат. В част
ности. это гложет быть реализовано настройкой клиента всегда использовать TLS при аутентификации HTTP и
доверять лишь сертификатам от особого локального удостоверяющего центра.
При использовании с CDMI. TLS должен использовать сертификаты форомага Х.509 версии 3. которые удов
летворяют прфилю. определенному в гл. 4 RFC 3280 (X.509v3 Certificate and CRL). Этот профиль сертификатов и
списка отозванных сертификатов (CRL) определяет обязательные поля для включения в сертификат, а также
опциональные поля и расширения, которые могут включаться в сертификат.
Серверные сертификаты должны поддерживаться всеми серверами CDMI. а клиентские сертификаты могут
поддерживаться CDMI клиентами. Сервер предоставляет клиенту серверный сертификат, в свою очередь, клиент
предоставляет серверу клиентский сертификат для аутентификации. Использование серверных сертификатов до
вольно обычно для публичных веб-серверов, предлагающих безопасное соединение через TLS, однако клиентские
сертификаты используются достаточно редко, так как клиент обычно аутентифицируется другими способами.
П р и м е р
-
Сайт электронной коммерции аутентифицирует клиента по номеру кредитной кар
ты, пользоват ельскому имени/паролю. и т.д., когда происходит покупка. С этой точки зрения гораздо
более критично, что сервер доказывает свою идентичность, и поэт ому со стороны сервера исполь
зуется серверный сертификат.
Такие сертификаты Х.509 используют цифровую подпись для установления связи открытого ключа и иден
тичности. Такие подписи часто выпускаются удостоверяющими центрами (УЦ), связанными с внутренними или
внешними инфраструктурами открытых ключей (PKI); однако, альтернативой может быть самоподписанный серти
фикат (сертификат, подписанный той же парой ключей, открытая часть которых находится в данных сертификата).
Модели, связанные с этими двумя подходами, различны. В случае сертификатов PKI следует принимать во вни
мание иерархию доверия и доверенную третью сторону при валидации сертификата, что повышает безопасность
ценой усложнения. Самоподписанныв сертификаты могут использоваться в форме доверенной сети (решение о
доверии находится в руках пользователей или администраторов), однако это считается менее безопасным, так как
отсутствует центральный орган, который может проверить подлинность сертификата и отозвать его при необходи
мости. Тем не менее, даже такая пониженная безопасность в раде случаев может быть адекватной мерой, а ее
реализация гораздо проще.
В случае сертификатов PKI часто необходимо пройти по цепочке доверителей до корневого удостоверяю
щего центра. Такой корневой УЦ может быть внутренним УЦ. сертификат которого подписан УЦ более высокого
уровня, или находиться на конце цепочки как УЦ наивысшего уровня. Последний является главной аттестационной
организацией в данной схеме PKI, и его сертификат (корневой сертификат) может быть только
самоподписанным. Установление якоря доверия на уровне корневого сертификата, особенно в случае
коммерческих СА. может иметь нежелательные побочные эффекты, связанные с неявным доверием ко всем
сертификатом, выпускаемым данным коммерческим СА. В идеале якорь должен располагаться на низшем
практически доступном уровне.
А.5.2.1 Проверка сертификата
Клиенты и серверы CDMI должны провести простейшую проверку пути, расширенную проверку пути и про
верку CRL как описано в гл. 6 RFC 3280. для всех представленных сертификатов. Эти проверки включают (но не
ограничены) следующими:
153