OCSP

Протокол состояния сетевого сертификата (OCSP) - это интернет-протокол, используемый для получения статуса отзыва цифрового сертификата X.509. Механизм протокола описан в RFC 6960 и является одним из стандартов de-facto Интернета. Он был создан в качестве альтернативы спискам отзыва сертификатов (CRL), в частности для решения некоторых проблем, связанных с использованием CRL в инфраструктуре открытых ключей (PKI). Cообщения OCSP кодируются в ASN.1 и обычно передаются по HTTP. Диалоги «запрос/ответ» этих сообщений позволяют называть сервера OCSP ответчиками OCSP.

Не все веб-браузеры используют OCSP для проверки сертификатов SSL/TLS протокола HTTPS.

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

Базовая реализация PKI
  1. Алёна и Борис - респонденты, каждый имеет сертификат открытого ключа, выданный некоторым центром сертификации (Certificate Authority, CA).
  2. Алёна хочет выполнить транзакцию с Борисом и отправляет ему свой сертификат открытого ключа.
  3. Борис, обеспокоенный тем, что закрытый ключ Алёны мог быть скомпрометирован, создает «запрос OCSP», который содержит серийный номер сертификата Алёны и отправляет его в CA.
  4. Сервис OCSP Центра сертификации считывает серийный номер сертификата из запроса Бориса и производит поиск состояния сертификата Алёны. Возможное состояние, которое он обнаружит в базе данных Центра сертификации CA — сертификат отозван. В этом случае база данных CA является единственным достоверным источником, способным подтвердить факт компрометации сертификата Алёны.
  5. Сервис OCSP Центра сертификации подтверждает, что сертификат Алёны все еще в порядке, и возвращает подписанный, положительный «ответ OCSP» Борису.
  6. Борис криптографически проверяет подписанный ответ Центра сертификации CA. Открытый ключ CA был сохранён у Бориса заранее, и с его помощью он проверяет достоверность ответа Центра сертификации CA.
  7. Борис завершает транзакцию с Алёной.

Детали протокола

Ответчик OCSP (обычно сервер Центра сертификации) возвращает подписанный ответ со статусом сертификата, указанного в запросе: годный, отозван или статус неизвестен. Если он не может обработать запрос, он может вернуть код ошибки.

Формат запроса OCSP поддерживает дополнительные расширения. Это позволяет выполнить дополнительную настройку для конкретной схемы PKI.

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

OCSP может поддерживать более одного уровня CA. Запросы OCSP могут быть связаны между одноранговыми ответчиками для запроса выдающего ЦС, подходящего для сертификата субъекта, с ответчиками, проверяющими ответы друг друга на корневой ЦС, используя свои собственные запросы OCSP.

Ответчик OCSP может запрашивать информацию об отзыве с помощью серверов проверки делегированного пути (DPV). OCSP сама по себе не выполняет DPV поставляемых сертификатов.

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

 OID {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) keyPurpose(3) ocspSigning(9)})

Реализации

Существует несколько открытых и проприетарных реализаций OCSP, включая полнофункциональные серверы и библиотеки для создания пользовательских приложений. Поддержка клиентов OCSP встроена во многие операционные системы, веб-браузеры и другое сетевое программное обеспечение ввиду растущей популярности HTTPS и WWW.

Сервер
  • Boulder,[1] CA и OCSP ответчик разработан и используется Let's Encrypt (Go)
  • DogTag,[2] Центр сертификации с открытым исходным кодом CA, CRL и OCSP ответчик.
  • Ejbca,[3] CA и OCSP ответчик (Java)
  • OpenXPKI,[4] CA и OCSP как расширение в конфигурации OpenXPKI.
  • XiPKI,[5] CA и OCSP ответчик. С поддержкой RFC 6960 и SHA3 (Java)

Проприетарное программное обеспечение:

  • Службы сертификации CA и OCSP-ответчик, входящие в состав Windows Server[6].

Библиотеки

Поддержка в браузерах

Существует широкая поддержка OCSP среди большинства основных браузеров:

  • Internet Explorer построен на CryptoAPI Windows, и, таким образом, начиная с версии 7 на Windows Vista (но не Windows XP) поддерживает проверку OCSP.

Все версии Mozilla Firefox поддерживают проверку OCSP. Firefox 3 включает проверку OCSP по умолчанию.

  • Safari на macOS поддерживает проверку OCSP. Он включен по умолчанию с Mac OS X 10.7 (Lion). До этого он должен быть активирован вручную в настройках брелка.
  • Версии Opera от 8.0 до текущей версии поддерживают проверку OCSP.

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

Примечания
  1. GitHub - letsencrypt/boulder: An ACME-based certificate authority, written in Go
  2. Dogtag
  3. EJBCA - The Open Source CA
  4. Realm — OpenXPKI 3.1.1 documentation
  5. GitHub - xipki/xipki: Highly scalable and high-performance open source PKI (CA and OCSP responder). Minimal dependencies, No-JPA, No-Spring
  6. Certificate Services - Win32 apps | Microsoft Docs

Внешние ссылки
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.