Протокол статуса онлайн-сертификата - Online Certificate Status Protocol

Статус Online Certificate Protocol ( OCSP ) является интернет - протокол , используемый для получения статуса аннулирования в X.509 цифрового сертификата . Он описан в RFC 6960 и находится на треке стандартов Интернета . Он был создан как альтернатива спискам отзыва сертификатов (CRL), в частности, для решения определенных проблем, связанных с использованием CRL в инфраструктуре открытых ключей (PKI). Сообщения, передаваемые через OCSP, кодируются в ASN.1 и обычно передаются через HTTP . Характер этих сообщений "запрос / ответ" ведет к серверам OCSP.называются респондентами OCSP .

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

Сравнение с CRL

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

Базовая реализация PKI

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

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

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

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

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

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

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

Ключ, которым подписывается ответ, не обязательно должен быть тем же ключом, которым подписан сертификат. Издатель сертификата может делегировать другой орган в качестве ответчика OCSP. В этом случае сертификат респондента (тот, который используется для подписи ответа) должен быть выпущен эмитентом соответствующего сертификата и должен включать определенное расширение, которое отмечает его как подписывающий орган OCSP (точнее, расширенный расширение использования ключа с OID {iso (1) идентифицированная организация (3) dod (6) Интернет (1) безопасность (5) механизмы (5) pkix (7) keyPurpose (3) ocspSigning (9)})

Проблемы конфиденциальности

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

Критика

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

Расширение MustStaple TLS в сертификате может требовать проверки сертификата с помощью сшитого ответа OCSP , что устраняет эту проблему. OCSP также остается надежной защитой от ситуаций, когда злоумышленник не является «посредником» (подпись кода или сертификаты, выпущенные по ошибке).

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

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

Информация OCSP в Firefox 89

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

  • Internet Explorer построен на CryptoAPI в Windows , и , таким образом , начиная с версии 7 на Windows Vista (не 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 году, ссылаясь на проблемы с задержкой и конфиденциальностью, и вместо этого использует собственный механизм обновления для отправки отозванных сертификатов в браузер.

Реализации

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

Сервер

Открытый исходный код

  • Ответчик Boulder, CA и OCSP, разработанный и используемый Let's Encrypt ( Go )
  • DogTag, центр сертификации с открытым исходным кодом CA, CRL и ответчик OCSP.
  • Ответчик EJBCA , CA и OCSP ( Java )
  • Ответчик XiPKI, CA и OCSP. С поддержкой RFC 6960 и SHA3 ( Java )

Проприетарный

  • ЦС служб сертификации и ответчик OCSP включены в Windows Server

Библиотека

Открытый исходный код

Клиент

Смотрите также

использованная литература

внешние ссылки