Инфраструктура Открытого Ключа (часть 7)

Обсуждение проблем безопасности

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

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

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

Запросы не содержат Responder, к которому они обращаются. Это позволяет атакующему повторить запрос к любому количеству OCSP Responder.

Использование кэширования НТТР в некоторых сценариях развертывания может привести к непредсказуемым результатам, если промежуточные серверы некорректно сконфигурированы или известно, что возможны ошибки при управлении кэшем.

OCSP поверх НТТР

Опишем форматирование, которое должно быть выполнено, если запрос и ответ используют НТТР.

Запрос

НТТР, лежащий в основе OCSP -запросов, может использовать либо GET, либо POST метод для submit-запросов. Для возможности НТТР-кэширования небольшие запросы (меньше 255 байтов) могут пересылаться с использованием GET. Если НТТР-кэширование не требуется или размер запроса превышает 255 байтов, запрос должен пересылаться с использованием POST. Если требуется защита, то OCSP -транзакции, применяющие НТТР, могут быть защищены с помощью TLS/SSL или другого протокола более низкого уровня.

OCSP -запрос, использующий метод GET, конструируется следующим образом:

GET {url}/{url-encoding of base-64 encoding
  of the DER encoding of the OCSPRequest}

где {url} может быть получено из значения AuthorityInfoAccess или локальной конфигурации OCSP -клиента.

OCSP -запрос, использующий метод POST, конструируется следующим образом: заголовок Content-Type имеет значение application/ocsp-request, а тело сообщения является бинарным значением DER-представления OCSPRequest.

Ответ

Ответ OCSP, основанный на НТТР, создается в соответствии с заголовками НТТР, за которыми следует бинарное значение DER-представления OCSPResponse. Заголовок Content-Type имеет значение application/ocsp-response. Заголовок Content-Length должен специфицировать длину ответа. Остальные заголовки НТТР могут присутствовать и могут игнорироваться, если запрашивающим они не распознаются.