Ocsp stapling
Для решения этих проблем было предложено расширение протокола TLS, позволяющее прикреплять OCSP-ответы к сертификатам (
) и переносящее ответственность за выполнение OCSP на TLS-сервер.
На рисунке изображена схема использования OCSP stapling:
Схема описывает следующие шаги:
- TLS-сервер, выступая в роли OCSP-клиента, собирает информацию о статусе своей цепочки сертификатов, обращаясь к OCSP-серверам соответствующих УЦ;
- TLS-сервер кэширует полученные OCSP-ответы;
- При установке TLS-соединения сервер передаёт клиенту свою цепочку сертификатов вместе с соответствующими ей OCSP-ответами.
Таким образом:
«Но где же тут защита от атаки повторного воспроизведения?» — спросите вы. Тут её действительно нет, однако рассматриваемое расширение протокола TLS позволяет клиентам пересылать случайный одноразовый код при установке соединения:
Такой вариант использования OCSP stapling не позволяет кэшировать OCSP-ответы на сервере, из-за чего растёт время установки TLS-соединения и увеличивается нагрузка на серверы УЦ.
Следует отметить, что существует две версии OCSP stapling. Первая версия по неясной причине позволяет прикреплять OCSP-ответ только для сертификата самого сервера. При использовании этой версии ответственность за получение информации о статусе остальных сертификатов цепочки лежит на клиенте. Этот недостаток исправлен в новой версии.
Кратко о протоколе tls и инфраструктуре открытых ключей x.509
Современный защищённый Веб стоит на двух китах:
. Для установки защищённого TLS-соединения сервер должен передать клиенту свой открытый ключ. Аутентичность ключа сервера, пересылаемого через незащищённые публичные сети, обеспечивается цепочкой сертификатов открытых ключей инфраструктуры
Удостоверяющий центр (УЦ, certification authority, CA) может отозвать подписанный (изданный) им ранее сертификат, например, в случае компрометации закрытого ключа, соответствующего этому сертификату. Поэтому, чтобы исключить возможность подключения к «человеку посередине», при установке TLS-соединения клиент должен не только проверять корректность подписей всей предоставленной сервером цепочки сертификатов, но и проверять статус предоставленных ему сертификатов (сертификат действителен или отозван).
Криптопро | задачи криптопро ocsp
Использование ПАК «КриптоПро OCSP» позволяет участникам информационных систем получать актуальную информацию о статусе сертификатов открытых ключей. По сравнению с использованием списков отозванных сертификатов (Certificate Revocation List — CRL) использование OCSP-службы имеет следующие преимущества:
- Информация о статусе сертификатов, представляемая ПАК «КриптоПро OCSP», более актуальна по причине того, что данная служба за информацией о статусе сертификата может обращаться напрямую в Реестр Удостоверяющего центра – Базу данных Центра Регистрации или Центра Сертификации ПАК «КриптоПро УЦ»;
- OCSP-ответ службы ПАК «КриптоПро OCSP» фиксирован и сравнительно мал, тогда как списки отозванных сертификатов могут иметь большой объём. Это позволяет уменьшить время реакции пользовательских приложений, а также может иметь решающее значение при создании долговременного архива документов с электронной цифровой подписью (электронной подписью) для уменьшения объёма хранимых данных;
- Применение ПАК «КриптоПро OCSP» позволяет установить единую точку получения информации о статусе сертификатов, при использовании в информационной системе нескольких Удостоверяющих центров. Указанная служба обеспечит сбор списков отозванных сертификатов, публикуемых этими Удостоверяющими центрами, и на базе информации, содержащейся в этих списках, информировать участников информационных систем о статусе сертификатов посредством OCSP-ответов.
Для реализации сервиса OCSP необходимо на базе «КриптоПро OCSP Server» организовать Сервер службы OCSP, на клиентских рабочих местах использовать функционал «КриптоПро Revocation Provider», или встроить «КриптоПро OCSP Client» в программное обеспечение клиентских рабочих мест. Встраивание «КриптоПро OCSP Client» осуществляется с использованием комплекта средств разработки «КриптоПро PKI SDK».
Криптопро ocsp server
При совместной работе ПАК «КриптоПро УЦ» и ПАК «КриптоПро OCSP Server» для предоставления пользователям актуальной информации о статусах сертификатов по протоколу OCSP рекомендуется использовать совмещенный режим работы. При этом, в качестве источника информации о статусах сертификатов используются базы данных Центра Сертификации и Центра Регистрации ПАК «КриптоПро УЦ». Подробнее о данном режиме можно узнать здесь.
Механизм crl
УЦ публикуют CRL, в которые вносятся серийные номера отозванных сертификатов, в точках распространения CRL (CRL distribution point, CDP). Адреса (URL) точек распространения CRL, к которым следует обращаться для получения информации о статусе проверяемого сертификата, как правило, указываются в самом сертификате.
Механизм ocsp
OCSP, как следует из его названия, предназначен для получения наиболее актуальной информации о статусе сертификата в режиме онлайн и не обладает приведёнными выше недостатками CRL.
Механизмы проверки статуса сертификатов
Применяющиеся на практике механизмы проверки статуса сертификатов основаны на
(certificate revocation list, CRL) и
(online certificate status protocol, OCSP).
Продолжение следует… а пока — отличная новость!
В этой статье мы рассмотрели три основных механизма проверки статуса сертификатов. Проверки, осуществляемые на практике, являются надстройками над этими механизмами или их комбинацией. Тема дальнейшего обсуждения и следующей статьи — каким образом проверки статуса сертификатов реализованы в Веб-браузерах?
Про проблему отозванных сертификатов и «Кошмар скомпрометированных ключей» мы говорили на «очной ставке» NeoQUEST-2022. У нас даже есть отличное видео, в котором автор статьи рассказывает про отозванные сертификаты:
Пока у нас активно ведется подготовка к очередной «очной ставке» NeoQUEST-2022, которая пройдет в Питере 29 июня (и на которую мы ждём ВСЕХ желающих!), рассказываем интересную новость:
Мы объявляем конкурс докладов на «очную ставку» NeoQUEST-2022!
