Contents of this directory is archived and no longer updated.

Этим постом я начинаю серию небольших заметок по не всегда очевидным фактам в PKI. И сегодня начну с первого факта — OCSP или CRL? OCSP и CRL — это 2 модели, которые могут использоваться для проверки сертификата на предмет его отзыва.

Сертификаты в случае когда в них больше не нуждаются или когда закрытый ключ от сертификата может быть доступен злоумышленникам подлежат отзыву. Этим самым полностью теряется доверие данному сертификату или человеку, который его предъявил, поскольку сертификат может предъявить злоумышленник, который его украл. Это достаточно важный момент в PKI, который позволяет достаточно однозначно сказать — можем ли мы доверять предъявителю конкретного сертификата или нет.

Модель CRL используется с самого начала существования PKI и выглядит следующим образом. Сервер CA отзывает некоторый сертификат и помещает о нём запись в специальный файл CRL. При этом туда помещается серийный номер сертификата, дата фактического отзыва (не обязательно совпадает со временем когда администратор отозвал сертификат) и причина отзыва. Клиенты при проверки сертификатов скачивают эти CRL и проверяют есть ли серийный номер этого сертификата в CRL. Логично, что чем больше сертификатов отозвано, тем больше файл, тем более нагружается сеть при частом скачивании относительно большого файла CRL.

В OCSP используется немного иной принцип. Клиент OCSP отправляет на сервер OCSP Responder специальный запрос, в котором содержится серийный номер проверяемого сертификата. OCSP Responder «пробивает номер по своей базе» и отвечает клиенту откликом. Этот отклик содержит однозначный ответ на вопрос: отозван или не отозван.

Казалось бы, если у вас и серверы и клиенты работают под управлением Windows Vista/2008 и выше, то ответ однозначный: OCSP — наше всё! Ну и вообще даже при наличии небольшого количества этих систем (а преимущественно используются устаревшие клиенты Windows XP/2003), то OCSP нам никак не помешает! Но на самом деле это не всегда так и в ряде ситуаций использование OCSP будет даже нежелательным. Давайте посмотрим почему. Сначала сделаем сравнительные характеристики обеих моделей проверки отзыва

  • CRL

Исходный размер пустого CRL составляет порядка 600 байт (но это значение может отличаться в зависимости от длины полей и длины ключа подписи). На каждую запись отозванного сертификата в CRL отводится 80 байт. Это, как я уже говорил, серийный номер отозванного сертификата, дата фактического отзыва и числовое обозначение причины отзыва. Т.е. если у вас отозвано 10 сертификатов, то размер CRL будет 600 + 80 * 10 = 1400 байт. Если отозвано 100 сертификатов, то размер CRL будет порядка 9кб и т.д.

  • OCSP

Каждая проверка статуса сертификата потребляет определённый размер трафика — 2кб. При этом неважно какого размера сам CRL. Даже если отозвано 100 000 сертификатов, то CRL будет размером примерно 8мб. И каждый устаревший клиент будет скачивать этот файл на 8 мегабайт. А с OCSP любой запрос и ответ на него займёт всего 2кб. Удобно? Безусловно.

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

  • сертификаты смарт-карт;
  • сертификаты аутентификации в IIS;
  • клиентские сертификаты компьютеров для VPN/L2TP и IPsec;
  • сертификаты аутентификации пользователей в VPN (EAP-TLS).

Почему? Дело в том, что аутентифицирующий сервер кеширует все данные об отзыве. Сначала в памяти, потом на диске (когда происходит свопинг). И давайте посмотрим на типичный сценарий:

У вас на предприятии используется корпоративный веб-сайт с аутентификацией пользователей по сертификату. У вас 1000 пользователей и они все утром подключаются к веб-сайту. Веб-сервер при проверке подлинности каждого пользователя будет посылать OCSP запрос на OCSP Responder запросы с серийным номером каждого сертификата. Мы знаем, что размер каждого ответа составляет 2кб, следовательно сервер отправит 1000 HTTP запросов и закеширует у себя в памяти 2 мегабайта памяти.

А теперь представьте, что у вас не используется OCSP, а только CRL и на сервере CA отозвано 100 сертификатов. Как мы знаем сам контейнер CRL занимает 600 байт и каждая запись по 80 байт. В итоге файл CRL будет занимать 9 килобайт! И в этом случае сервер сделает только одну «ходку» за CRL файлом и уже всех клиентов будет проверять именно по скачанному CRL. Как видите, профит от использования CRL здесь очевиден. Серверу надо меньше тратить сетевого трафика и меньше данных кешируется в памяти. При этом OCSP целесообразно включать для серверных сертификатов, потому что клиентов обычно много и им выгодней использовать небольшии порции трафика OCSP.

Подводя итоги, мы можем кратко констатировать следующие вещи:

  • для серверных сертификатов рационально использовать OCSP;
  • для клиентских сертификатов, которые используются для аутентификации часто рациональней будет использовать классические CRL, вместо OCSP.

Поэтому при рассмотрении вопроса внедрения OCSP вы должны учитывать эти моменты, чтобы ваша PKI была более эффективной.

Ссылки по теме:

OCSP (часть 1)
OCSP (часть 2)
http://en.wikipedia.org/wiki/Certificate_revocation_list


Share this article:

Comments:

KFeoktistov
KFeoktistov 29.01.2010 11:54 (GMT+3) OCSP или CRL?

Означает ли это, что в пользовательских сертификатах в AIA не стоит публиковать точку OCSP? Будет ли сервер входящий в состав домена при проверке сертификатов подключающихся пользователей проверять их статус по OCSP, если точка OCSP в AIA стоит 3-м пунктом после LDAP и HTTP ссылок и в сертификате указаны доступные для сервера точки доступа к CRL по LDAP и HTTP? Иными словами, делать то что, если издающий CA выдает сертификаты как для серверов (SSL), так и для пользователей сети, в том числе, и не являющихся членами домена/AD ?

Vadims Podāns
Vadims Podāns 29.01.2010 21:41 (GMT+3) OCSP или CRL?

Вопрос не совсем однозначный на самом деле. Дело в том, что аутентифицирующий сервер (контроллер домена) может скачивать CRL после получения 50 OCSP ответов для одного CA. Т.е. у вас одновременно логонятся тысяча пользователей. Контроллер домена проверяет по OCSP каждый логонный сертификат, который выдан одним и тем же CA. И после 50 ответов для конкретного CA контроллер может скачать CRL и проверять оставшиеся 950 сертификатов по CRL без использования OCSP. Пока неясен вопрос, при каких условиях аутентифицирующий сервер это будет делать, а при каких не будет. Поэтому этот вопрос пока висит в воздухе. на счёт AIA и OCSP. Если вы внимательно посмотрите расширение AIA, то там будут отдельные разделы Authority Info Access с разными методами доступа: Access Method=Certification Authority Issuer и Access Method=On-line Certificate Status Protocol. Первый содержит ссылки на CRT файлы и для него используется свой порядок ссылок. Второй метод содержит ссылки на OCSP и порядок использования определяется для каждого метода независимо.

KFeoktistov
KFeoktistov 02.02.2010 12:19 (GMT+3) OCSP или CRL?

Вадим, добрый день. Повторю оставшийся без ответа вопрос: Что делать, если издающий CA выдает сертификаты как для серверов (SSL), так и для пользователей сети, в том числе, и не являющихся членами домена/AD, чтобы проверяющий сервер не обращался по каждому сертификату к ответчику OCSP, а пользовался доступным ему CRL ?

Vadims Podāns
Vadims Podāns 03.02.2010 10:51 (GMT+3) OCSP или CRL?

а зачем отключать OCSP? Если хотите, то можете отключить проверку OCSP для конкретного сертификата CA, как это показано в документации: http://technet.microsoft.com/en-us/library/ee619786(WS.10).aspx

Comments are closed.