OCSP Stapling

OCSP Stapling — это расширение протокола TLS, предназначенное для повышения производительности и конфиденциальности при проверке статуса сертификата X.509. Вместо того чтобы клиент самостоятельно запрашивал у центра сертификации (CA) информацию об отзыве сертификата через протокол OCSP (Online Certificate Status Protocol), сервер веб-сайта периодически получает от CA подписанный ответ OCSP («степлер» — от англ. staple) и «прикрепляет» (staples) его к своему сертификату во время рукопожатия TLS. Клиент, получив такой ответ, может проверить статус сертификата локально, без дополнительного сетевого запроса.

История и предпосылки

Протокол OCSP был разработан для замены устаревших списков отзыва сертификатов (CRL — Certificate Revocation List). CRL представляли собой большие списки серийных номеров отозванных сертификатов, которые клиент должен был загружать целиком, что было неэффективно. OCSP решал эту проблему, позволяя клиенту запрашивать статус только одного конкретного сертификата. Однако у OCSP были существенные недостатки:

• Задержка: Клиент должен был выполнить отдельный HTTP-запрос к OCSP-ответчику CA, что увеличивало время установки TLS-соединения.
• Нагрузка на CA: Каждый клиент, посещающий сайт, генерировал запрос к серверу CA, что создавало значительную нагрузку на инфраструктуру центров сертификации.
• Проблемы конфиденциальности: Запрос OCSP содержал серийный номер сертификата, что позволяло CA (или любому, кто перехватывал трафик) отслеживать, какие именно веб-сайты посещает пользователь.
• Отказ в обслуживании: Если OCSP-ответчик был недоступен, многие браузеры (особенно старые версии) могли либо заблокировать соединение («жесткий сбой»), либо, что случалось чаще, разрешить его («мягкий сбой»), что сводило на нет саму идею проверки отзыва.

OCSP Stapling, впервые предложенный в 2001 году и стандартизированный в RFC 4366 (а позже в RFC 6066 и RFC 6961), был призван решить все эти проблемы.

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

Процесс работы OCSP Stapling можно разделить на два этапа: подготовительный (на стороне сервера) и этап установки соединения.

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

1. Получение сертификата: Владелец веб-сайта получает сертификат X.509 от CA.
2. Периодический запрос: Веб-сервер (например, Apache, Nginx, IIS) периодически (обычно раз в несколько часов или дней, в зависимости от политики CA) сам отправляет запрос OCSP к серверу CA, запрашивая статус своего собственного сертификата.
3. Получение и кэширование ответа: CA возвращает подписанный цифровой подписью ответ OCSP, который содержит статус сертификата («хороший», «отозван» или «неизвестен»), время его выдачи и время следующего обновления (nextUpdate). Сервер кэширует этот ответ.

Этап установки TLS-соединения (рукопожатие)

1. ClientHello: Клиент (браузер) отправляет серверу приветствие, в котором указывает, что поддерживает расширение status_request (или status_request_v2 для нескольких сертификатов).
2. ServerHello и Certificate: Сервер отвечает своим приветствием и отправляет свой сертификат X.509.
3. CertificateStatus: Вместо того чтобы клиент делал отдельный запрос, сервер сразу же отправляет кэшированный, подписанный CA ответ OCSP в специальном сообщении CertificateStatus.
4. Верификация: Клиент получает сертификат и «прикреплённый» к нему ответ OCSP. Клиент проверяет:

• Цифровую подпись ответа OCSP (она должна быть от CA, выдавшего сертификат).
• Что ответ OCSP относится именно к полученному сертификату.
• Что ответ OCSP не просрочен (срок действия nextUpdate не истёк).
• Статус сертификата в ответе («хороший»).

1. Продолжение рукопожатия: Если проверка пройдена успешно, рукопожатие TLS продолжается. Если сертификат отозван или ответ недействителен, соединение прерывается.

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

• Повышение производительности: Клиенту не нужно выполнять дополнительный HTTP-запрос к CA. Время установки соединения сокращается, особенно на медленных каналах или при недоступности OCSP-ответчика.
• Снижение нагрузки на CA: Вместо тысяч отдельных запросов от клиентов, CA обрабатывает один периодический запрос от сервера.
• Повышение конфиденциальности: Сервер не раскрывает CA информацию о том, какие конкретно сайты посещает пользователь. CA знает только IP-адрес сервера, а не каждого клиента.
• Устойчивость к отказам: Если OCSP-ответчик CA временно недоступен, сервер может использовать свой кэшированный ответ до истечения его срока действия. Клиент не сталкивается с ошибкой из-за недоступности CA.

Недостатки и ограничения

• Зависимость от серверного ПО: OCSP Stapling должно быть явно включено и настроено на веб-сервере. Не все серверы поддерживают его, или он может быть настроен неправильно.
• Срок действия ответа: Кэшированный ответ OCSP имеет ограниченный срок действия. Если сертификат будет отозван после того, как сервер получил последний ответ, сервер будет продолжать использовать «хороший» ответ до его истечения. Это создает «окно уязвимости», в течение которого отозванный сертификат может использоваться. Проблема частично решается с помощью более коротких сроков действия ответов OCSP (например, 4 часа) и протокола OCSP Must-Staple.
• OCSP Must-Staple: Это расширение сертификата (RFC 7633), которое заставляет браузеры требовать от сервера обязательного предоставления «степлера» OCSP. Если сервер не предоставляет его, браузер должен разорвать соединение. Это решает проблему «мягкого сбоя», когда клиент просто пропускал проверку, если OCSP-ответчик был недоступен. Сертификаты с меткой OCSP Must-Staple не могут быть использованы без предоставления актуального ответа OCSP.
• Поддержка клиентами: Хотя все современные браузеры поддерживают OCSP Stapling, некоторые старые или специализированные клиенты могут не отправлять расширение status_request, и сервер в таком случае не будет отправлять «степлер».

Реализация и настройка

OCSP Stapling поддерживается большинством современных веб-серверов.

• Apache httpd: Начиная с версии 2.3.3, поддерживается через директиву SSLUseStapling On. Требуется указать путь к файлу ответов OCSP через SSLStaplingResponderTimeout и SSLStaplingReturnResponderErrors.
• Nginx: Начиная с версии 1.3.7, поддерживается через директиву ssl_stapling on;. Требуется указать цепочку сертификатов (ssl_trusted_certificate) и, опционально, OCSP-ответчик (ssl_stapling_responder).
• IIS: Начиная с Windows Server 2012 и IIS 8.0, поддерживается встроенными средствами. Требуется включить опцию «Send certificate status» в настройках сайта.
• Lighttpd: Поддерживается через директиву ssl.stapling-file.

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

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

• CRLite (Mozilla): Проект, использующий фильтры Блума для компактного представления всех отозванных сертификатов. Браузер загружает этот фильтр и может локально проверить статус сертификата без запроса к CA.
• Certificate Transparency (CT): Система, которая не проверяет отзыв, но делает выдачу сертификатов прозрачной. Любой сертификат, не зарегистрированный в публичных логах CT, считается недействительным. CT не заменяет проверку отзыва, но дополняет её.
• Short-lived certificates: Выдача сертификатов с очень коротким сроком действия (например, на несколько дней или часов). Если сертификат нужно отозвать, он просто не будет продлён. Это упрощает управление, но требует частого обновления сертификатов на серверах.

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

• Термин «stapling» (скрепление скрепкой) отражает идею «прикрепления» ответа OCSP к сертификату, как документ прикрепляется скрепкой.
• OCSP Stapling является одним из ключевых элементов для повышения производительности HTTPS, особенно на сайтах с высокой посещаемостью.
• В России, как и в других странах, OCSP Stapling используется для обеспечения безопасного соединения с государственными порталами (например, «Госуслуги») и банковскими системами, где критически важна проверка статуса сертификата.

Источники

1. RFC 4366 — Transport Layer Security (TLS) Extensions (раздел 3.1.1 Certificate Status Request).
2. RFC 6066 — Transport Layer Security (TLS) Extensions: Extension Definitions (раздел 8).
3. RFC 6961 — The Transport Layer Security (TLS) Multiple Certificate Status Request Extension.
4. RFC 7633 — X.509v3 TLS Feature Extension (OCSP Must-Staple).
5. Документация к веб-серверам Apache httpd, Nginx, IIS.
6. Статьи и обсуждения на ресурсах, посвященных безопасности и администрированию веб-серверов (например, SSL Labs, Mozilla MDN).