Online Certificate Status Protocol

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

История и развитие

Необходимость в OCSP возникла из-за ограничений, присущих традиционному механизму отзыва сертификатов — спискам отзыва (CRL). CRL представляют собой большие, периодически обновляемые файлы, которые клиент должен загружать и обрабатывать, что приводит к задержкам, увеличению трафика и сложностям с синхронизацией. В середине 1990-х годов, с ростом популярности SSL/TLS и электронной коммерции, потребовался более оперативный и лёгкий способ проверки статуса сертификата.

Протокол OCSP был впервые стандартизирован в 1999 году в RFC 2560, который стал основой для его внедрения. В 2013 году вышла обновлённая версия стандарта — RFC 6960, которая уточнила форматы запросов и ответов, а также добавила поддержку расширений, таких как подпись ответа и указание на необходимость повторной проверки. Дальнейшее развитие протокола связано с появлением OCSP Stapling (RFC 6066, 2011 год), который решает проблему конфиденциальности и производительности, позволяя веб-серверу самостоятельно получать подписанный OCSP-ответ и передавать его клиенту во время рукопожатия TLS.

Архитектура и принцип работы

OCSP основан на модели «запрос-ответ» и использует протокол HTTP (или HTTPS) для передачи данных. Взаимодействие происходит между тремя сторонами:

• Клиент (OCSP-запросчик) — обычно веб-браузер, почтовый клиент или другое приложение, которое проверяет сертификат.
• OCSP-ответчик (OCSP Responder) — сервер, управляемый центром сертификации (CA) или уполномоченной стороной, который хранит актуальную информацию об отозванных сертификатах.
• Центр сертификации (CA) — организация, выпустившая проверяемый сертификат.

Процесс проверки

1. Клиент получает сертификат сервера (например, при установке HTTPS-соединения). В сертификате содержится расширение Authority Information Access (AIA), которое указывает URL-адрес OCSP-ответчика.
2. Клиент формирует OCSP-запрос. Запрос содержит идентификатор проверяемого сертификата (обычно его серийный номер и хеш от имени эмитента), а также может включать необязательные расширения, например, для запроса подписи ответа.
3. Запрос отправляется на указанный URL-адрес OCSP-ответчика по протоколу HTTP (чаще всего через POST или GET).
4. OCSP-ответчик получает запрос, обращается к своей внутренней базе данных отозванных сертификатов (обычно синхронизированной с CRL) и формирует ответ.
5. Ответ может содержать один из трёх статусов:

• good — сертификат действителен и не отозван.
• revoked — сертификат отозван (с указанием даты и причины отзыва).
• unknown — статус сертификата не может быть определён (например, если CA не выпускал такой сертификат или данные недоступны).

1. Ответ подписывается цифровой подписью OCSP-ответчика (или CA) для обеспечения целостности и аутентичности. Клиент проверяет эту подпись.
2. Клиент принимает решение: если статус «good», соединение устанавливается; если «revoked» или «unknown», соединение прерывается, и пользователю отображается предупреждение.

Виды и реализации

OCSP Stapling

Основной недостаток классического OCSP — это потенциальная утечка конфиденциальной информации (какие сертификаты проверяет пользователь) и дополнительная задержка на запрос к серверу. OCSP Stapling (RFC 6066) решает обе проблемы. В этой схеме веб-сервер периодически (например, раз в несколько часов) самостоятельно запрашивает у OCSP-ответчика подписанный ответ о статусе своего собственного сертификата. Затем, во время TLS-рукопожатия, сервер «вшивает» (staples) этот ответ в своё сообщение Certificate. Браузеру не нужно делать отдельный запрос к OCSP-ответчику — он получает готовый, подписанный ответ от сервера, что ускоряет проверку и сохраняет конфиденциальность.

OCSP Must-Staple

Расширение OCSP Must-Staple (RFC 7633) — это флаг в сертификате, который сообщает клиенту (браузеру), что сервер обязан предоставить подписанный OCSP-ответ через Stapling. Если сервер не делает этого, браузер должен отклонить соединение. Это повышает безопасность, так как предотвращает атаки, при которых злоумышленник отключает проверку OCSP на стороне клиента.

Лёгкий OCSP (Lightweight OCSP)

Существуют реализации OCSP, оптимизированные для встраиваемых систем и устройств с ограниченными ресурсами (IoT). Они используют упрощённые форматы запросов и ответов, а также могут работать через UDP вместо HTTP.

Преимущества и недостатки

Преимущества

• Оперативность: OCSP предоставляет статус сертификата в реальном времени, в отличие от CRL, которые обновляются с задержкой.
• Экономия трафика: OCSP-ответ значительно меньше по размеру, чем полный список CRL, что снижает нагрузку на сеть.
• Точность: Клиент получает информацию только о конкретном сертификате, а не обо всех отозванных.
• Масштабируемость: OCSP-ответчики могут быть распределены географически и обрабатывать большое количество запросов.

Недостатки

• Зависимость от сети: Для проверки требуется доступ к OCSP-ответчику. Если сервер недоступен, клиент не может проверить статус, что может привести к блокировке соединения (в строгих настройках) или к небезопасному соединению (в мягких настройках).
• Утечка данных: Классический OCSP раскрывает информацию о том, какие сертификаты проверяет пользователь, что может быть использовано для отслеживания. Эта проблема решается с помощью OCSP Stapling.
• Нагрузка на сервер: OCSP-ответчики должны быть высокопроизводительными, чтобы обслуживать миллионы запросов в день.
• Сложность внедрения: Требуется настройка и поддержка OCSP-ответчика со стороны CA, а также поддержка протокола на стороне клиента.

Применение

OCSP является неотъемлемой частью инфраструктуры открытых ключей и используется в следующих сценариях:

• Веб-безопасность (HTTPS): Браузеры (Google Chrome, Mozilla Firefox, Apple Safari) используют OCSP (в том числе Stapling) для проверки сертификатов веб-сайтов. Если сертификат отозван, браузер блокирует доступ к сайту.
• Электронная почта (S/MIME): Почтовые клиенты проверяют сертификаты подписи и шифрования писем.
• Кодовая подпись (Code Signing): Операционные системы проверяют сертификаты, которыми подписаны исполняемые файлы и драйверы.
• VPN и Wi-Fi (EAP-TLS): В корпоративных сетях OCSP используется для проверки сертификатов пользователей и устройств при аутентификации.
• Государственные информационные системы: В России OCSP используется в инфраструктуре электронной подписи (например, для проверки сертификатов Удостоверяющих центров, аккредитованных Минцифры).

Критика и альтернативы

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

• CRL (Certificate Revocation List): Традиционный, но менее оперативный метод. Используется как резервный или для офлайн-проверок.
• CRLite (Chrome): Экспериментальный подход, при котором браузер загружает сжатое представление всего реестра отозванных сертификатов и выполняет проверку локально, без сетевых запросов.
• Revocation Reason Codes: Вместо простого «отозван» OCSP может передавать код причины отзыва (например, компрометация ключа, смена должности пользователя), что позволяет клиенту принять более информированное решение.

Несмотря на критику, OCSP остаётся доминирующим протоколом для проверки отзыва сертификатов в Интернете, особенно в сочетании с OCSP Stapling, который устраняет его основные недостатки.

Источники

1. RFC 6960 — X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP.
2. RFC 6066 — Transport Layer Security (TLS) Extensions: Extension Definitions (раздел об OCSP Stapling).
3. RFC 7633 — X.509v3 Transport Layer Security (TLS) Feature Extension (OCSP Must-Staple).
4. RFC 2560 — X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP (устаревший, но исторически важный).
5. Национальный стандарт РФ ГОСТ Р ИСО/МЭК 9594-8-2010 (Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 8. Основные положения аутентификации).