- Введение
- Почему сейчас всё работает именно так?
- Google chrome/cromium
- Microsoft internet explorer/edge
- Ocsp или crl? – pki extensions
- Добиваемся ocsp stapling = yes для сертификатов от wosign на nginx
- Какие есть перспективы?
- Криптопро | задачи криптопро ocsp
- Настройка ca
- Настройка шаблона ca
- Параноидальная схема проверки статуса сертификатов для меньшинства
- Прочие браузеры и платформы
- Схема для большинства
Введение
Сегодня хочу поговорить про OCSP – Online Certificate Status Protocol, который служит для проверки статуса сертификата на предмет отозванности. Как известно, стандартным механизмом проверки статуса сертификата является публикация CRL (Certificate Revocation List). В жизни существует 2 вида CRL:
Почему сейчас всё работает именно так?
Об этом хорошо написано
. Отсутствие
hard fail
и отказ от явного выполнения OCSP-запросов на стороне клиента обусловлены следующими факторами:
- инфраструктура УЦ станет единой точкой отказа. Недоступность OCSP-сервера может стать причиной отказа в обслуживании целого сегмента Интернета. Инфраструктура УЦ становится новой целью для DDoS;
- увеличение затрат УЦ на поддержку инфраструктуры. УЦ требуется покупать каналы с большей пропускной способностью и обеспечивать защиту от DDoS;
- снижение надёжности TLS-соединений в нестабильных или зашумлённых сетях (например, мобильных сетях);
- увеличивается объём пересылаемого трафика и требуется большая полоса пропускания, что критично, опять же, для мобильных клиентов;
- проблемы использования OCSP вместе captive portal. Пароли, как правило, передаются поверх TLS, однако установить TLS-соединение и аутентифицироваться не получится, пока не были получены ответы от OCSP-серверов. Отправить же OCSP-запросы нельзя, поскольку OCSP-серверы (как минимум для сертификатов промежуточных УЦ), как правило, находятся в Интернете, и на этом этапе доступа к ним нет. Эта проблема может быть решена с помощью прикреплённых OCSP-ответов, однако проверка статуса промежуточных сертификатов на текущий момент всё равно требует отправки OCSP запросов, поскольку ни один браузер не поддерживает прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961).
При этом полного отказа от явного выполнения OCSP-запросов на стороне клиента не происходит, поскольку он всё ещё может защитить от «человека посередине» в случаях, когда он находится «близко» к серверу «далеко» от клиента, т.е., имеет доступ к TLS-трафику, но не может блокировать OCSP:
Google chrome/cromium
Браузеры Google Chrome и Chromium версии 59 при проверке DV-сертификатов ведут себя следующим образом:
Проверки, выполняемые Chrome похожи, на те, что выполняет Firefox, с тем исключением, что в Chrome вообще отказались от выполнения OCSP-запросов при проверке DV-сертификатов. «CRLSets» в Chrome является аналогом «OneCRL» в Firefox (строго говоря, механизм «CRLSets» появился даже раньше) и обладает теми же проблемами неполноты и неподконтрольности конечному пользователю.
OCSP-запросы используются при проверке EV-сертификатов (тут картина становится практически идентичной той, что мы наблюдали для Firefox):
Как и другие браузеры, Chrome и Chromium работают в режиме soft fail. Прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961) и защита OCSP-ответов от атак повторного воспроизведения не поддерживаются.
Изменить поведение Chrome и Chromium возможно внесением изменений в групповую политику (инструкция здесь) и включением следующих опций:
Эквивалентная настройка возможна и под Linux (здесь).
После внесения этих изменений Chrome и Chromium будут выполнять проверки, аналогичные тем, что делает Internet Explorer (при отсутствии прикреплённых OCSP-ответов начнут выполнять OCSP-запросы с откатом на загрузку CRL для всей цепочки сертификатов), но в режиме hard ail, т.е., при недоступности OCSP-серверов и точек распространения CRL подключение будет запрещено:
Microsoft internet explorer/edge
Браузеры Microsoft Internet Explorer версии 11 и Microsoft Edge версии 40 ведут себя одинаково для DV- и EV-сертификатов:
В схеме, как и ранее, для простоты не показано взаимодействие с кэшем полученных ранее OCSP-ответов и CRL, хотя этому можно посвятить отдельную статью.
Для каждого проверяемого сертификата в цепочке при отсутствии прикреплённых OCSP-ответов выполняется OCSP-запрос. При этом Internet Explorer и Edge не поддерживают прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961) и не обеспечивают защиту OCSP-ответов от атак повторного воспроизведения. Если OCSP-сервер недоступен, то выполняется попытка загрузки CRL.
Проверка также выполняется в режиме soft fail. Таким образом, атака «человек посередине» также проходит успешно и также не имеет значения, чей ключ был скомпрометирован изначально, ключ самого сервера или УЦ.
Изменить поведение Internet Explorer возможно, например, установив значение ключа реестра «HKEY_LOCAL_MACHINE SOFTWARE Microsoft Internet Explorer Main FeatureControl FEATURE_WARN_ON_SEC_CERT_REV_FAILED iexplore.exe» равным 1.
Для Edge подобных настроек не нашли.
Ocsp или crl? – pki extensions
Этим постом я начинаю серию небольших заметок по не всегда очевидным фактам в 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 составляет порядка 600 байт (но это значение может отличаться в зависимости от длины полей и длины ключа подписи). На каждую запись отозванного сертификата в CRL отводится 80 байт. Это, как я уже говорил, серийный номер отозванного сертификата, дата фактического отзыва и числовое обозначение причины отзыва. Т.е. если у вас отозвано 10 сертификатов, то размер CRL будет 600 80 * 10 = 1400 байт. Если отозвано 100 сертификатов, то размер CRL будет порядка 9кб и т.д.
Каждая проверка статуса сертификата потребляет определённый размер трафика — 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://my-sertif.ru/wiki/Certificate_revocation_list
Добиваемся ocsp stapling = yes для сертификатов от wosign на nginx
Доброго времени суток, Хабражители.
Прочитав статьи
№1
и
№2
(про бесплатные SSL сертификаты от китайских друзей
WoSign
столкнулся с тем, что многие не могут добиться
OCSP stapling = Yes
для этих сертификатов.
Хочу рассказать как этого добился я.
Мы получили сертификат WoSign, залили на сервер.
И так, приступим.
Во-первых — получаем промежуточные сертификаты.
cd /path/to/your/ssl/
wget -O - https://www.startssl.com/certs/ca.pem | tee -a ca-certs.pem > /dev/null
wget -O - https://www.startssl.com/certs/sub.class1.server.ca.pem | tee -a ca-certs.pem > /dev/null
wget -O - http://aia.startssl.com/certs/ca.crt | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null
wget -O - http://aia1.wosign.com/ca1g2-server1-free.cer | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null
wget -O - http://aia6.wosign.com/ca6.server1.free.cer | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null
Во-вторых — в коняги Nginx’а добавляем
#########################################################
#
#
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
ssl_prefer_server_ciphers on;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate "/path/to/your/ssl/ca-certs.pem";
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
#
#
#########################################################
В-третьих — в коняги домена прописываем для 443 порта в раздел server следующее:
ssl on;
ssl_certificate /path/to/your/ssl/ssl.crt;
ssl_certificate_key /path/to/your/ssl/ssl.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'HIGH:!aNULL:!MD5:!kEDH';
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
И напоследок — перезапускаем Nginx
service nginx restart
Теперь при проверке на SSL-тестере мы видим результат А и включенный OCSP stapling.
Так же можно проверить это прямо на сервере командой
openssl s_client -connect YourDomain.com:443 -tls1 -tlsextdebug -status
Если в результате есть следующее,
Вот результаты теста моего блога
В комментариях к вышеупомянутым статьям были попытки (очень похожие на мою), но неуспешные.
Я не навязываю бесплатные сертификаты, но всё же если платить не хочется — пользуйтесь!
Спасибо.
Какие есть перспективы?
Очевидный вывод из всего сказанного ранее: проверки статуса сертификатов в браузерах не работают, и это не новость. При этом просто взять и перейти на
hard fail
нельзя по объективным причинам.
Есть ли применимое на практике решение данной проблемы? Проанализировав и собрав воедино множество уже предложенных частичных решений данной проблемы (в частности расширение сертификатов «TLS feature», сертификаты с коротким сроком действия, агрегаторы CRL и др., о чём подробно будет рассказано ниже), предлагаем вашему вниманию наше представление о том, как проверка статуса сертификатов должна происходить на практике.
В основе лежит утверждение о том, что не для всех сервисов требуется онлайн-проверки статуса сертификатов. Для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме hard fail, не окупают риски, связанные с атакой «человек посередине» с использованием отозванных сертификатов. Иначе говоря, с точки зрения проверки статуса сертификатов, сервисы делятся на два типа:
1. Меньшинство, для которого будут проводиться строгие онлайн-проверки статуса сертификатов в режиме hard fail.2. Большинство, для которого онлайн-проверки статуса сертификатов не будут выполняться вовсе (будут предприниматься другие меры по защите).
Браузеры могут различать такие сервисы по наличию специального расширения в сертификате сервера. В зависимости от типа сервиса клиент либо будет выполнять «параноидальную» проверку статуса сертификатов, либо не будет выполнять её вовсе. Теперь подробнее о каждой из этих двух схем.
Криптопро | задачи криптопро ocsp
Использование ПАК “КриптоПро OCSP” позволяет участникам информационных систем получать актуальную информацию о статусе сертификатов открытых ключей. По сравнению с использованием списков отозванных сертификатов (Certificate Revocation List – CRL) использование OCSP-службы имеет следующие преимущества:
- Информация о статусе сертификатов, представляемая ПАК “КриптоПро OCSP”, более актуальна по причине того, что данная служба за информацией о статусе сертификата может обращаться напрямую в Реестр Удостоверяющего центра – Базу данных Центра Регистрации или Центра Сертификации ПАК “КриптоПро УЦ”;
- OCSP-ответ службы ПАК “КриптоПро OCSP” фиксирован и сравнительно мал, тогда как списки отозванных сертификатов могут иметь большой объём. Это позволяет уменьшить время реакции пользовательских приложений, а также может иметь решающее значение при создании долговременного архива документов с электронной цифровой подписью (электронной подписью) для уменьшения объёма хранимых данных;
- Применение ПАК “КриптоПро OCSP” позволяет установить единую точку получения информации о статусе сертификатов, при использовании в информационной системе нескольких Удостоверяющих центров. Указанная служба обеспечит сбор списков отозванных сертификатов, публикуемых этими Удостоверяющими центрами, и на базе информации, содержащейся в этих списках, информировать участников информационных систем о статусе сертификатов посредством OCSP-ответов.
Для реализации сервиса OCSP необходимо на базе “КриптоПро OCSP Server” организовать Сервер службы OCSP, на клиентских рабочих местах использовать функционал “КриптоПро Revocation Provider”, или встроить “КриптоПро OCSP Client” в программное обеспечение клиентских рабочих мест. Встраивание “КриптоПро OCSP Client” осуществляется с использованием комплекта средств разработки “КриптоПро PKI SDK”.
Настройка ca
Следующим этапом нужно подготовить сам CA для работы с OCSP. Для этого вызываем свойства самого CA и переходим на вкладку Extensions:
fig.3
Настройка шаблона ca
Итак, для начала нам потребуется установленный в сети Certification Authority под управлением Windows Server 2008 (любой редакции, кроме Web). По умолчанию с добавлением роли AD CS добавляется и служба Online Respnder. Для этого так же потребуется установить службы IIS, о чём мастер вам сообщит и предложит сделать.
fig.1
Данный шаблон характеризуется следующими свойствами:
- срок действия сертификата составляет 2 недели
- на вкалдке Request Handlings добавлено право чтения приватного ключа для службы Network Service, поскольку служба OCSP работает от лица Network Service, а не LocalSystem (для LocalSystem отдельных разрешений не требуется)
- шаблон не содержит CDP и AIA расширений
- шаблон помечен как неподлежащий для проверки на отзыв (см. fig.1)
На вкладке Security необходимо для учётной записи компьютера, на котором размещён OCSP выдать право Allow Read и Allow Enroll. Это единственное изменение, которое необходимо выполнить для шаблона. Теперь нужно открыть оснастку Certificate Authority и добавить этот шаблон для выдачи:
правой кнопкой на Certificate Templates –> New –> Certificate Template to Issue –> OSCP Response Signing. Далее нужно создать оснастку Certificates для учётной записи компьютера и запросить сертификат на основе этого шаблона с компьютера, где установлен OCSP Responder.
После запроса сертификата не стоит закрывать оснастку Certificates, а выбрать новый сертификат и в All Tasks выбрать Manage Privete keys. В открывшемся окне Permissions выдайте право Read для учётной записи Network Service:
fig.2
Параноидальная схема проверки статуса сертификатов для меньшинства
В 2021 году вышла спецификация нового расширения сертификатов стандарта X.509, называемого
(на ранних этапах разработки стандарта также известное, как «OCSP must staple»). Это расширение сертификата позволяет зафиксировать в сертификате те опции протокола TLS, которые TLS-сервер, предъявляющий данный сертификат, обязуется поддерживать. Такой опцией протокола TLS в частности являются прикреплённые OCSP-ответы. Пример сертификата с таким расширением схематически изображён ниже:
В сертификате присутствует расширение «TLS Feature» (выделено красным), сообщающее о том, что TLS-сервер обязан поддерживать прикреплённые OCSP-ответы, специфицированные в RFC 6066 («Status Request (Version 1)»), и более новую версию данной опции («Status Request (Version 2)»), специфицированную в RFC 6961 — множественные прикреплённые OCSP-ответы. Новая версия данной опции протокола TLS позволяет прикреплять OCSP-ответы и для сертификатов промежуточных УЦ.
Прочие браузеры и платформы
Для других популярных браузеров и платформ ситуация такая же: везде проверки статуса сертификатов выполняются в режиме
soft fail
, либо не выполняются вовсе. Подробнее можно почитать
или
Схема для большинства
Как было сказано ранее, для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме
hard fail
, не окупают риски связанные с атакой «человек посередине» с использованием отозванных сертификатов. В таком случае лучше не защищаться от данной атаки, а максимально сократить временной промежуток, в течение которого проведение данной атаки будет возможным. Для этого используются сертификаты с коротким сроком действия (например, 1-2 дня).
Таким образом, большинство сервисов будет использовать сертификаты без расширения «TLS Feature», но с коротким сроком действия. Для таких сертификатов онлайн-проверки статуса сертификатов не будут выполняться вовсе. Вместо этого будет проводиться частое обновление быстро устаревающих сертификатов.
Добавим, что использование сертификатов с коротким сроком действия эквивалентно использованию сертификатов с расширением «TLS Feature», обязывающим использовать прикреплённые OCSP-ответы, вместе с прикреплёнными OCSP-ответами, не защищёнными от атаки повторного воспроизведения (т.е.
Подход с использованием сертификатов с коротким сроком действия обладает целым рядом достоинств, однако малопригоден для сертификатов УЦ. Для проверки статуса таких сертификатов можно использовать периодически обновляемые чёрные списки аналогичные «CRLSets» и «OneCRL», но предоставляющие пользователям больший контроль на агрегаторами CRL.
Пользователи, например, должны иметь возможность добавлять новые опрашиваемые точки распространения CRL. Это важно, поскольку некоторые организации разворачивают собственные не публичные УЦ для внутреннего использования. Решением может стать возможность использования приватных агрегаторов CRL.