RFC 2560

RFC 2560 — это спецификация протокола онлайн-запроса статуса сертификата (Online Certificate Status Protocol, OCSP), опубликованная в июне 1999 года Инженерным советом Интернета (IETF). RFC 2560 определяет механизм, позволяющий клиентским приложениям (например, веб-браузерам) оперативно проверять, не был ли отозван цифровой сертификат X.509, без необходимости загрузки и обработки полных списков отозванных сертификатов (CRL). Протокол OCSP, описанный в данном документе, является основным альтернативным методом проверки статуса сертификата в инфраструктуре открытых ключей (PKI).

История

До появления OCSP основным способом проверки статуса сертификата были списки отозванных сертификатов (CRL), которые издавались удостоверяющими центрами (УЦ). CRL представляли собой подписанные списки серийных номеров отозванных сертификатов, которые клиенты должны были периодически загружать. Этот подход имел существенные недостатки: размер CRL мог быть очень большим (до нескольких мегабайт), что создавало нагрузку на сеть и требовало значительного времени на загрузку, особенно на медленных каналах связи. Кроме того, частота обновления CRL (например, раз в сутки) приводила к задержке в распространении информации об отзыве.

В середине 1990-х годов возникла потребность в более эффективном и оперативном механизме. Группа разработчиков IETF, в том числе Майкл Майерс (VeriSign), Рич Анкни (CertCo) и Амит Малпани (ValiCert), предложила протокол, который позволял бы получать ответ о статусе конкретного сертификата в реальном времени. Результатом этой работы стал RFC 2560, который был опубликован в июне 1999 года и утверждён в статусе Proposed Standard. Позднее, в 2013 году, протокол был обновлён стандартом RFC 6960, который ввёл дополнительные расширения и улучшил безопасность, однако RFC 2560 остаётся базовым документом, определяющим фундаментальную архитектуру OCSP.

Принцип работы

Протокол OCSP, описанный в RFC 2560, работает по модели «запрос-ответ». Клиент (например, веб-браузер или почтовый клиент), желающий проверить статус сертификата, отправляет запрос OCSP-ответчику — специальному серверу, который обычно управляется тем же удостоверяющим центром, что выпустил проверяемый сертификат.

Запрос OCSP

Запрос (OCSPRequest) содержит следующие основные элементы:

Версия протокола (по умолчанию 1.0).
Идентификатор запроса (RequestorName) — необязательное поле, может содержать имя клиента.
Список запросов (RequestList) — один или несколько запросов, каждый из которых включает:
Хеш алгоритма (например, SHA-1) для идентификации сертификата.
Хеш от имени издателя (IssuerNameHash) — хеш от имени УЦ, выпустившего сертификат.
Хеш от открытого ключа издателя (IssuerKeyHash) — хеш от открытого ключа УЦ.
Серийный номер сертификата (SerialNumber) — уникальный номер проверяемого сертификата.
Расширения (Extensions) — необязательный блок, позволяющий запрашивать дополнительную информацию (например, нонс для защиты от повторных атак).

Запрос может быть подписан закрытым ключом клиента, но это не является обязательным требованием RFC 2560.

Ответ OCSP

Ответ (OCSPResponse) содержит:

Статус ответа (ResponseStatus) — указывает на успешность обработки запроса (успех, ошибка, попробовать позже, внутренняя ошибка сервера, подпись недействительна).
Подписанный блок (ResponseBytes) — если статус «успех», то этот блок содержит:
Идентификатор типа ответа (например, id-pkix-ocsp-basic).
Данные ответа (BasicOCSPResponse), которые включают:
Дата и время (thisUpdate) — момент, когда ответ был сформирован.
Дата и время следующего обновления (nextUpdate) — рекомендуемое время, до которого ответ считается актуальным.
Список ответов для каждого запрошенного сертификата (SingleResponse): каждый ответ содержит:
Идентификатор сертификата (CertID) — те же хеши и серийный номер, что и в запросе.
Статус сертификата (CertStatus) — одно из трёх значений:
good — сертификат не отозван (но может быть ещё не действителен).
revoked — сертификат отозван (с указанием даты и причины отзыва).
unknown — статус сертификата неизвестен (например, ответчик не имеет информации о данном сертификате).
Расширения (Extensions) — могут включать дополнительную информацию (например, нонс из запроса, если он был).
Подпись (Signature) — цифровая подпись ответчика, заверяющая целостность и подлинность данных. Подпись может быть выполнена с помощью закрытого ключа УЦ или специального ключа OCSP-ответчика.

Классификация

RFC 2560 определяет два основных типа OCSP-ответчиков:

Авторизованный ответчик (Authorized Responder) — сервер, которому УЦ делегировал право подписывать OCSP-ответы. Для этого УЦ выдаёт специальный сертификат (OCSP-сертификат), который содержит расширение id-pkix-ocsp-nocheck, указывающее, что клиенту не нужно дополнительно проверять статус самого этого сертификата.
Ответчик, совпадающий с УЦ (CA Responder) — сам удостоверяющий центр может выступать в роли OCSP-ответчика, подписывая ответы своим основным закрытым ключом.

Применение

Протокол OCSP, описанный в RFC 2560, широко используется в различных областях, где требуется проверка цифровых сертификатов:

Веб-браузеры — при установке HTTPS-соединения браузер может отправить OCSP-запрос для проверки статуса сертификата сервера. Однако из-за задержек и проблем с доступностью OCSP-ответчиков многие браузеры (например, Google Chrome) внедрили механизм «мягкого отказа» (soft-fail), при котором недоступность OCSP не блокирует соединение.
Почтовые клиенты — при проверке подписей электронных писем (S/MIME) или шифровании.
Электронная подпись — в системах электронного документооборота для проверки действительности сертификатов подписантов.
VPN и TLS-соединения — в корпоративных сетях для контроля доступа.

Критика и ограничения

Несмотря на широкое распространение, RFC 2560 имеет ряд недостатков, которые были отмечены сообществом:

Проблема конфиденциальности — OCSP-запрос содержит информацию о том, какой именно сертификат проверяется, что позволяет ответчику отслеживать, какие сайты посещает пользователь. Для решения этой проблемы был разработан протокол OCSP Stapling (RFC 6066), при котором сервер сам предоставляет клиенту подписанный OCSP-ответ.
Зависимость от доступности ответчика — если OCSP-ответчик недоступен, клиент не может проверить статус сертификата. В RFC 2560 не предусмотрено чёткого поведения в такой ситуации, что привело к неоднородной реализации (мягкий отказ vs. жёсткий отказ).
Отсутствие обязательной подписи запросов — RFC 2560 не требует подписи запросов, что делает возможным атаки типа «человек посередине» (MITM) на этапе запроса.
Устаревшие хеш-алгоритмы — RFC 2560 использует SHA-1 для хеширования имён и ключей, что в настоящее время считается недостаточно безопасным. Обновление RFC 6960 решило эту проблему, но многие старые реализации всё ещё используют SHA-1.

Интересные факты

RFC 2560 был опубликован почти одновременно с RFC 2459 (стандарт для сертификатов X.509), что сделало OCSP неотъемлемой частью PKI.
Протокол OCSP иногда называют «онлайн-CRL» из-за его функциональной схожести, хотя технически он принципиально отличается.
В 2013 году стандарт OCSP был обновлён до версии 2.0 (RFC 6960), который ввёл поддержку расширений, улучшенную безопасность и возможность агрегирования ответов.

Источники

RFC 2560 — Online Certificate Status Protocol (OCSP), June 1999.
RFC 6960 — X.509 Internet Public Key Infrastructure Online Certificate Status Protocol (OCSP), June 2013.
Housley, R. et al. (2002). Internet X.509 Public Key Infrastructure Certificate and CRL Profile. RFC 3280.
Myers, M. et al. (1999). Online Certificate Status Protocol (OCSP). IETF.
Сетевая архитектура PKI: учебное пособие / Под ред. А. В. Лебедева. — М.: ИНФРА-М, 2015.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →