ocsp pki goog что это
Криптография, электронная подпись и PKI
ПИК Безопасности имеет богатый опыт практического внедрения, применения и сопровождения технологий, описанных в данной статье. Продукты таких вендоров, как InfoTeCS, Код безопасности, Крипто-Про представляют собой комплексные, легко масштабируемые решения, позволяющие шифровать информацию при передаче по открытым каналам связи, разворачивать инфраструктуру PKI и систему обнаружения вторжений (IDS). Полную информацию вы всегда сможете получить у наших специалистов.
Часть 1. Криптография.
Интересно, что конфиденциальность сообщений интересовала людей еще в Древнем мире. Наверное, образно можно говорить о том, что шифрование появилось с того момента, когда люди научились писать. Некоторые из ранних упоминаний о шифровании сообщений датируются пятым веком до н.э. Если читателя интересует история шифрования, рекомендуем к прочтению книгу Саймона Сингха «Книга шифров. Тайная история шифров и их расшифровки». В данном труде автору удается изложить историю шифрования, начиная с древних времен и первого исторического произведения Геродота о греко-персидских войнах, до наших дней и появления квантовой криптографии – в достаточно увлекательной и захватывающей манере. В общем – категорически рекомендуем!
Ну а мы рассмотрим два принципиальных вида алгоритмов шифрования: симметричные алгоритмы шифрования и асимметричные алгоритмы шифрования.
В симметричных алгоритмах шифрования используется один и тот же ключ как для шифрования, так и для дешифрования сообщения. Таким образом, если в обмене сообщениями участвуют два субъекта, у обоих будет одинаковый ключ шифрования/дешифрования. Преимуществом данных алгоритмов шифрования является скорость работы и простота реализации. Основной же проблемой этого вида шифрования является общий ключ шифрования/дешифрования. Безопасная передача этого ключа является очень большой проблемой, ведь злоумышленник, перехватив ключ, сможет читать все сообщения. Поэтому в 70-х годах 20-го столетия появилась криптография с открытым ключом. Определяющими факторами для появления ассиметричного вида шифрования явились:
На алгоритмах RSA и Диффи-Хеллмана мы останавливаться не будем, а перейдем к сути криптографии с открытым ключом:
Стоит заметить, что в современных реализациях VPN (в качестве примера можно привести технологию ViPNet), используется комбинация симметричных и асимметричных алгоритмов шифрования. Например, сначала используются асимметричные алгоритмы для получения сессионного симметричного ключа шифрования (алгоритм Диффи-Хеллмана), а уже потом данные шифруются с помощью быстрого симметричного алгоритма с использованием ключа, который был выработан на первом шаге.
В нашем примере всего два субъекта и понятно, что в реальности, субъектов, обменивающихся информацией, будет гораздо больше. При этом открытый ключ не представляет из себя секрета, поэтому мы смело передаем его по открытым каналам. Таким образом, принципиальная проблема симметричных алгоритмов шифрования решена! Больше нет необходимости передавать секрет по открытым каналам связи. Но возникает другая – подтверждение подлинности открытого ключа. К примеру, субъект направляет нам свой открытый ключ и просит зашифровать на нем и отправить ему конфиденциальную информацию. При этом, мы не можем знать, действительно ли субъект является тем, за кого себя выдает, т.е. принадлежит ли открытый ключ нужному адресату. Возможно, что злоумышленник подменил открытый ключ и направил нам. Получив от нас сообщение, он сможет спокойно его расшифровать. Для решения этой проблемы и была придумана Инфраструктура открытых ключей (Public Key Infrastructure).
Перед тем, как мы перейдем к рассмотрению PKI, нужно немного сказать о технологии электронной подписи (ЭП). Существуют схемы ЭП, основанные на симметричных и асимметричных алгоритмах шифрования. Первый вариант мы рассматривать не станем ввиду малой распространенности. На асимметричных алгоритмах ЭП остановимся подробней.
В 1994 году Главным управлением безопасности связи ФАПСИ был разработан первый российский стандарт ЭЦП — ГОСТ Р 34.10-94 «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма».
В 2002 году для обеспечения большей криптостойкости алгоритма взамен ГОСТ Р 34.10-94 был введён одноимённый стандарт ГОСТ Р 34.10-2001, основанный на вычислениях в группе точек эллиптической кривой. В соответствии с этим стандартом, термины «электронная цифровая подпись» и «цифровая подпись» являются синонимами.
1 января 2013 года ГОСТ Р 34.10-2001 заменён на ГОСТ Р 34.10-2012 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.» Применение нового ГОСТ Р 34.10-2012 обязательно с января 2019 года – об этом мы уже писали. Если вы используете электронную подпись, нужно убедиться, что ваши средства ЭП поддерживают данный стандарт.
Асимметричные технологии электронной подписи отличаются от логики работы асимметричных алгоритмов шифрования. В отличие от асимметричных алгоритмов шифрования, где сообщение шифруется на открытом ключе получателя, а дешифрование происходит с помощью закрытого ключа, в алгоритмах электронной подписи сообщение подписывается с применением закрытого ключа, а при проверке подписи используется открытая часть. Логика следующая:
Парадигма PKI предполагает существование Корневого удостоверяющего центра (Certificate Authority), которому все участники взаимодействия безоговорочно доверяют. Создается иерархическая система доверия, т.е. Корневой УЦ может делегировать полномочия по подтверждению подлинности ключей пользователей другим УЦ. Система доверия выглядит как древовидная цепочка сертификатов УЦ, вплоть до конечного пользователя. Для подтверждения подлинности ключей пользователя, УЦ и выдает пользователям цифровые сертификаты.
Цифровой сертификат – это открытый ключ субъекта, подписанный закрытым ключом УЦ, содержащий в своем составе информацию о субъекте. Сертификаты создаются в соответствии со стандартом X.509, и могут использоваться для подписи, шифрования и аутентификации. Стандарт X.509 мы рассмотрим чуть дальше.
Таким образом, в состав компонентов PKI структуры входят:
Теперь процесс формирования ключей и обмена сообщениями, описанный ранее, в PKI выглядит следующим образом:
Многие УЦ генерируют и выдают субъекту ключевую пару, т.е. открытый и закрытый ключ. Таким образом пользователь сам ничего не создает. При такой схеме возможна компрометация закрытого ключа при выдаче оператором УЦ. С другой стороны, ведь УЦ мы безоговорочно доверяем?
Как правило, все УЦ, перечисленные в этом разделе, выдают сертификаты не пользователям, а подчиненным УЦ, которые в свою очередь работают с пользователями. Таким образом, можно приблизительно представить масштаб распространенности PKI и количество УЦ на сегодняшний день. Также нужно учитывать, что мы фактически безоговорочно доверяем создателю операционной системы, который поместил данные сертификаты в список доверенных. Конечно, для того, чтобы УЦ попал в список доверенных, он должен выполнять ряд требований, как технических, так и организационных.
Например, у Microsoft существует документ «Программа доверенных корневых сертификатов Майкрософт. Требования аудита для центров сертификации», где описаны общие требования для УЦ.
Кроме того существует программа сертификации WebTrust – это мировой стандарт, определяющий набор правил и критериев для УЦ. Критерии стандарта WebTrust были определены The American Institute of Certified Public Accountants (AICPA) и Canadian Institute of Chartered Accountants (CICA) в 1995 году. Любой крупный УЦ регулярно должен проходить аудит WebTrust.
Сертификаты PKI, выдаваемые согласно стандарту WebTrust, имеют статус проверенных и надёжных на мировом уровне, а также попадают в список доверенных в операционных системах (Windows, MAC OS X и др.) и веб-браузерах.
В Российской Федерации, согласно Федеральному закону от 06.04.2011 N 63-ФЗ «Об электронной подписи», аналогично с проведением международного аудита по требованиям безопасности, УЦ могут пройти процедуру аккредитации. Требования для аккредитованных УЦ устанавливает Федеральный закон и подзаконные правовые акты Минкомсвязи. Прохождение процедуры аккредитации дает право УЦ выпускать квалифицированные сертификаты электронной подписи. Такие сертификаты имеют юридическую значимость на территории РФ.
Говоря о PKI, мы по сути говорим о стандарте X.509. Стандарт X.509 предусматривает стандартную структуру сертификата (наборы полей), механизмы проверки действительности сертификата, а также стандартные механизмы получения и отзыва сертификатов:
Основные форматы файла сертификата:
Механизмы проверки действительности сертификата:
Любой сертификат в структуре PKI может быть скомпрометирован, поэтому стандарт X.509 предполагает механизмы их проверки. Проверка происходит с использованием «чёрных списков». Проверка происходит по серийному номеру сертификата. Существуют два основных формата:
C 31 декабря 2017 года начинает действовать редакция Федерального закона N 63-ФЗ «Об электронной подписи», согласно которой аккредитованный УЦ будет обязан иметь в своем составе OSCP-сервер.
Проблемы стандарта X.509:
Как видите, PKI не является идеальной инфраструктурой, и некоторые принципиальные моменты требуют решений. Тем более что сфер применения PKI становится всё больше и больше, и в глобальном значении этих областей сомневаться не приходится.
Часть 3. Заключение.
В качестве постскриптума, хочется кратко поговорить о существующих альтернативах и расширениях PKI:
Сеть доверия PGP (Pretty Good Privacy). Подробнее про PGP можно почитать в Интернете. Остановиться хочется именно на идее проверки принадлежности ключа конкретному пользователю. Как и в PKI, при использовании PGP, субъекты должны каким-нибудь способом проверить, что открытый ключ в сертификате действительно принадлежит отправителю. Если в PKI эту задачу решает существование доверенного УЦ, то в PGP используется схема проверки Web of Trust (Сеть доверия). Web of Trust основан на подписи ключей. Вы можете обозначить свое доверие ключу субъекта, которого знаете, подписав его своим ключом. Этот подписанный ключ вы можете отправить на key-server PGP (key-server выступает в роли публичного хранилища открытых ключей пользователя). Затем третье лицо, зная вас и вам доверяя, может обозначить свое доверие и тому лицу, чей ключ вы подписали. Таким образом, собирается сеть доверия. Существуют специальные мероприятия, которые называются PGP Key-signing party, где люди, показывая друг другу свои документы, удостоверяющие личность и открытый ключ (это не шутка), а затем, подписывая проверенные таким образом ключи друг друга, расширяют сеть доверия. Широкого распространения эта технология не получила и используется в довольно узких сферах (команды разработчиков, единомышленников). При этом key-server не играет ключевой роли, ключи могут быть опубликованы где угодно. Но сама идея с подписанными ключами и децентрализованной сетью доверия кажется очень интересной.
Расширение PKI – OCSP stapling. В целях снятия больших нагрузок в инфраструктуре PKI на сервер OCSP придуман механизм OCSP stapling. Он предполагает, что сайт, которому выдан сертификат, в определенные промежутки времени делает запрос в УЦ о статусе своего сертификата. УЦ отвечает метками действительности с проставлением штампа времени. При этом клиент, который заходит на сайт, видит метку УЦ на сертификате сайта, доверяет ему и не обращается к OCSP-серверу.
Расширение PKI – Certificate pinning. В общем случае клиент, который заходит на сервер, получает сертификат сервера, подписанный УЦ. Этот сертификат может быть подменен на сертификат от другого доверенного УЦ, который вдруг был взломан. Данное расширение предполагает, что на клиенте, как правило, в браузерах и мобильных приложениях, прописано соответствие серверов и сертификатов, т.е. прописан список разрешенных для домена сертификатов или УЦ, который хранится в исходных текстах браузера. Этот метод позволяет избежать подмены сертификата за счет сравнения с эталонными в защищенном хранилище браузера. Но этот метод не защищает нас от взлома УЦ, которые есть в списке соответствия данному домену.
Convergence. Так же как и в предыдущем пункте, данный метод призван защитить нас от атаки Man in the middle (MITM) или человек посередине, когда злоумышленник прослушивает канал и перенаправляет нас на свой сервер, передающий сертификат, подписанный УЦ, который находится в доверенных списках клиента. При этом мы предполагаем, что УЦ взломан. Распределенная система доверия предполагает, что в сети находятся специальные узлы, которые называются «нотариусами» (их может быть большое количество, расположены они могут быть в разных странах). Сертификаты нотариусов предварительно «зашиты» на клиенте. В момент получения сертификата с сервера, клиент, перед тем как доверять этому сертификату, обращается к «нотариусам» и просит их проверить со своей стороны, какой сертификат отдает целевой сервер при обращении к нему. Каждый нотариус идет на сервер и сравнивает сертификат сервера, который он получает с сертификатом в запросе клиента. При совпадении информации клиент доверяет сертификату сервера. Конечно, данный метод не защищает нас от взлома самого сервера.
Расширение для TLS протокола – TACK. В процессе установления соединения с сервером, клиент заявляет о поддержке расширения TACK и запрашивает TACK-ключ (эту ключевую пару генерирует администратор сервера, у данного ключа настраиваемое время жизни и порядок смены). В ответ сервер передает открытую часть TACK-ключа, сгенерированную администратором сервера. Передача происходит в рамках TLS handshake. Далее сервер передает клиенту сертификат, выданный УЦ, который подписан закрытым TACK-ключом, а клиент проверяет подпись с помощью открытой части TACK-ключа, переданной ранее. Таким образом, ответственность смещается на сторону сервера. Применение этой технологии не защищает от MITM при первоначальном подключении.
Google Key Pinning. Очень сильно похож на TACK. Отличия следующие: TACK – расширение для TLS, GKP – расширение HTTP. Ключи передаются не в рамках TLS handshake, а в заголовках сервера. У ключей GKP нет времени жизни. В целом технологии очень похожи. Стандарт предполагает генерацию резервных ключей совместно с основным ключом. В случае компрометации ключа используются резервные ключи. При этом также остается проблема MITM при первоначальном подключении.
Certificate Transparency. Технология разработана специалистами Google и призвана решить проблему поддельных сертификатов для доменов и их позднего обнаружения. Идея заключается в том, чтобы сделать невозможным создание сертификата для какого-либо домена незаметно для владельца этого домена. Технология предполагает существование трех объектов:
На этом мы остановимся и заметим, что представленные расширения в основном направлены на решение проблемы компрометации УЦ и предлагают делегирование ответственности на других участников взаимодействия. Но, к сожалению, полностью фундаментальные проблемы это не решает и о полноценной альтернативе PKI не может идти и речи.
Также как и любое правило, которое всегда содержит исключения, любая, даже по-настоящему отличная идея, всегда будет содержать в себе недостатки. PKI решает огромную массу задач и, несмотря на имеющиеся в технологии изъяны, является одним из самых значимых применений криптографии в сфере информационных технологий на сегодняшний день. К тому же, давайте говорить прямо, это очень неплохой бизнес для сотен УЦ. Поэтому можно с уверенностью говорить, что PKI будет только расширять свое присутствие в самых различных сферах применения.
Настройка и оптимизация OCSP
OCSP (Online Certificate Status Protocol) – полезная технология, делающая работу с PKI-системами более быстрой.
Несмотря на то что данная технология древняя, и поддерживается всеми крупными CA более десяти лет, в большинстве применений речь далее чем о “ну, те, у кого мы сертификаты берём, OCSP-сервер подняли и он работает” не идёт.
Однако и у самого OCSP есть настройки, и у связанных с этим протоколом технологий – тоже.
Немного углубимся в тему – от вас потребуется примерное представление о PKI (лучше подробное, но не обязательно) и желание сделать что-то лучше (это уже обязательно).
Настраиваем и оптимизируем OCSP и связанные с ним технологии
Кратко про OCSP
У сертификатов x.509, как и у любых сущностей, есть жизненный цикл. Они рождаются, живут, и умирают. Всё, как у людей.
Помимо фактической смерти сертификата от старости (в фиксированное время) у него бывает преждевременная кончина – она называется “отзывом”. Нужен этот механизм для того, чтобы резко прекратить использовать сертификат – по причине, например, компрометации ключа, либо изменения сущности, которую подтверждает сертификат, или какой-либо ещё неустранимой проблемы, после которой использование сертификата – как связки “криптографический материал плюс информация о связанной с ним сущности” – становится бессмысленным. Сертификат вроде как жив и срок годности ещё не завершился, но использовать его можно разве что в справочных целях вида “вот смотрите, когда-то это было сертификатом”. У людей это реализуется через каминг-аут или фразу “кстати я веган, отлично себя чувствую”.
Соответственно, возникает задача – как по сертификату определить, что его отозвали. Так как сертификат подписан, то редактировать его нельзя – следовательно, нельзя разместить прямо в нём какую-то информацию об отзыве в момент самого отзыва. Значит надо будет изначально предусмотреть в сертификате справочное поле, говорящее о внешней системе, обладающей информацией об отзыве. CA много, поднять CA может каждый, а значит информация эта будет специфична для каждого конкретного сертификата. Сертификат у нас идентифицируется уникальным id, по сути серийным номером, а раз так, то этой информации – id сертификата плюс данные о конкретном CA – хватит, чтобы проверить информацию об отзыве.
Первая и самая простая идея – формировать специальный документ в формате x.509v2 – называемый списком отозванных сертификатов (CRL). Это простой файл с линейным перечнем “кого отозвали”. Проблема в том что файл этот, выходит, постоянно растёт, и если у CA много сертификатов, то CRL-файл шустро увеличивается. Кроме того, ведь клиентам его надо обновлять по достаточно плотному расписанию, и чем чаще – тем лучше; нельзя же предположить, что через минуту не отзовут какой-либо сертификат, которым будет подписано пришедшее через пару минут письмо. Следовательно у этого файла появляется и явно прописанный “срок годности” – то время, через которое его точно надо обновить (скажем, неделя), плюс появляется задача “как можно чаще обновлять, чтобы оперативно отреагировать на свежеотозванный сертификат”.
Можно было также наделать много выдающих CA, чтобы “распределить” по их CDP – CRL Distribution Point’ам отозванных, но это уже совсем хардкор. Сама идея “разделить один огромный файл на части, чтобы перекачивать было проще” – рабочая, тут никто не спорит (впрочим, является явным “костылём”, т.к. не исправляет причину, а лишь временно отодвигает проблему роста CRL).
По итогам оба этих варианта не сильно исправили ситуацию, ну а с дельта-CRL некоторое клиентское ПО так работать и не научилось.
Всё скатывалось к тому что, приняв письмо размером в пять килобайт, подписанное цифровой подписью кого-то крупного – типа Verisign – надо подкачать здоровенный основной CRL и пачку дельта-CRL к нему, всё это собрать в единый массив и проверить подпись у письма, чтобы узнать, имеет ли смысл его читать, или нет. И все равно, даже если это старательно делать, то ситуацию “отозвали сертификат пару часов назад” можно упустить и принять поддельное сообщение за корректно подписанное.
При этом ситуация усугубляется тем, что информацию о старых отозванных сертификатах удалять нельзя. Почему?
Представьте себе архив электронной почты за, скажем, пять лет. Если хранить только информацию об отзыве за последний год, а более старую вычищать из CRL, то анализ архива за прошедшие 2-3 года превратится в сложную задачу. Если среди полученных 2 года назад писем будет подписанное отозванным на момент получения сертификатом, то оно будет ошибочно воспринято как “нормальное”. Ведь информация о том, что на момент получения этого письма его подпись была выполнена уже отозванным сертификатом – отсутствует.
Что делать? Очевидно – нужен сервис, лишённый всех этих вопросов по части “болезней роста”. Им и стала реализация протокола Online Certificate Status Protocol, или OCSP.
OCSP реализуется через веб-сервис, умеющий получить запрос “отозван ли вот этот конкретный сертификат” и ответить “да” или “нет”. Особенно полезно, отметим, то, что ответы OCSP представляют из себя отдельные объекты, подписанные сервером и обладающие сроком годности – а значит они могут передаваться между системами, кэшироваться и обновляться, следуя какой-либо нужной в специфичной ситуации логике. Адрес OCSP-сервиса не заменяет собой CRL в сертификате – он является дополнительным методом проверки валидности, указываемым в AIA-расширении.
Теперь кратко про то, как будут реализованы компоненты OCSP на практике.
OCSP-сервер
Поднять свой OCSP-сервер для локальной инфраструктуры PKI нетрудно – он будет встроен в, например, ОС Windows Server начиная с NT 6.0 и будет называться OCSP Responder. Про его настройку и так подробно говорится на курсах, но вкратце там всё очень просто – вы обеспечиваете OCSP Responder’у доступ к свежему CRL-файлу нужного CA (или файлАМ, если их несколько), выдаёте сервису специфичный OCSP-сертификат и сервис функционирует. По сути он получает запрос клиента, ищет id сертификата в локальном CRL-файле и отвечает “да” или “нет”, тривиально снимая с клиента задачу по загрузке полного CRL’а, сбору того из кусочков delta-CRL’ов и всякого подобного.
Оптимизировать там, опять же, особенно нечего – этот сервис должен быть постоянно доступен и очень быстр, что вообще характерно для современных сервисов, так что перейдём к клиентской стороне.
OCSP-клиент
Поддержка анализа и обработки OCSP-записей в поле AIA у x.509v3-сертификатов появляется в Windows Vista; там же появляется и возможность управлять работой OCSP. Сделана она штатно, через механизм объектов групповой политики:
Нас будет интересовать блок настроек про выбор между OCSP и CRL (когда для конкретного сертификата доступны оба) и модификацию времени валидности данных об отзыве:
Шучу, не будет. Тонкая настройка “как именно выбирать между OCSP и CRL” нужна крайне редко – например, в сценарии “в локальной сети высокий уровень безопасности и используется IPsec transport mode для защиты определённых видов трафика” можно будет “заставлять” обращаться к закэшированному CRL (который заранее через ту же Group Policy раздаётся), экономя время на установку SA. Увеличение срока валидности OCSP/CRL сверх указанного также пригодится очень редко – например у мобильного устройства, перемещающегося между имеющими частичный доступ к Интернету региональными объектами одного крупного предприятия.
Основное у клиента – это “Умеет ли читать OCSP-поле” / “Умеет ли обрабатывать множественный ответ OCSP-responder’а”. Сейчас это, в общем, почти у всех.
Вроде всё хорошо – задачу с растущими CRL’ами решили. Но технологии не стоят на месте и на базе OCSP развиваются более интересные возможности.
Первая по важности из них – это OCSP Stapling.
OCSP Stapling
Прикрепление OCSP-ответа – технология, развивающая применение OCSP и имеющая очевидные плюсы.
Ключевой – скорость. Вместо того, чтобы запросить у сервера сертификат, проверить его по всем параметрам (валидный по формату, действительный, обладает всеми нужными полями и использует понятные для хоста криптоалгоритмы), а потом сходить к OCSP responder’у, чтобы узнать про “отозван или нет”, OCSP Stapling предлагает “прикреплять” к ответу TLS-сервера и сертификат и OCSP-ответ от responder’а про этот сертификат. Это экономит время клиента – ему не надо устанавливать сессию до OCSP responder’а, плюс делает систему чуть безопаснее – OCSP responder не может собирать информацию “кто и с каких адресов подключается к серверам, которым мы выдали наши сертификаты” – он видит лишь факт того, что сервер многократно спрашивает про свой собственный сертификат.
Проблема со скоростью OCSP также завязана на то, что в первой реализации – RFC 6066 – OCSP разрешал в ответе только информацию про один сертификат. То есть клиент, даже получив от сервера полную цепочку сертификатов до какого-то trusted – ну или не от сервера, имея часть из сертификатов из этой цепочки локально – все равно делал несколько (обычно 3-4) запросов про каждый из них отдельно. В обновлённой спецификации, RFC 6961, которая “Multiple Certificate Status Request Extension”, OCSP responder может выдать информацию сразу про несколько сертификатов в одном ответе – но вопрос, насколько широко реализован обновлённый OCSP со стороны различного клиентского ПО (в частности, браузеров). Поэтому OCSP Stapling потенциально может выиграть ещё больше времени, экономя ещё и на количестве запросов.
В дополнение, OCSP Stapling потенциально делает установку соединения более надёжной – потому что если вы подключились к веб-серверу, и работает OCSP Stapling, то информацию об отзыве вы получите от этого же сервера, а не подключаясь к стороннему сервису (который может не работать). Сервер кэширует валидный OCSP-ответ, поэтому в случае кратковременных перебоев OCSP responder’а, ответственного за сертификат X, обладающий этим сертификатом X сервер будет отправлять клиентам валидный OCSP-ответ, а если бы клиенты обращались напрямую к responder’у, то они бы получали отказ в обслуживании после достаточно длительного тайм-аута.
OCSP Stapling, кстати, не просто “айтишная мелкая штука, ускоряющая работу”, а вполне серьёзная технология, упоминающаяся как нужная к реализации в разделе 3.4.1.2 стандарта NIST SP 800-52r1.
Надо использовать. Как?
OCSP Stapling в IIS
OCSP Stapling поддерживается начиная с NT 6.0 и детали его реализации в IIS, судя по всему, IIS унесёт с собой в могилу. Известно лишь то, что вопросы о “когда вы доделаете поддержку Multiple Certificate Status Request Extension?” подвисали в воздухе на форумах MSDN ещё в 2017 году. Что, в принципе, можно считать достаточным для принятия решения не особо использовать IIS для таких штук.
Что интересно, “неуправляемая” реализация OCSP Stapling в Microsoft IIS прошла все нужные сертификации американского Минобороны, о чём сообщается на специальной странице. Текущее состояние этой страницы довершает картину:
OCSP Stapling в nginx
В варианте с nginx всё куда как лучше.
Включается OCSP Stapling, выключенный по умолчанию, вот так:
Чтобы он (механизм OCSP Stapling) работал, нужна информация о “родительском” сертификате и прямое указание на DNS-сервер, через который будут разрешаться FQDN’ы из AIA-расширения.
Существует также возможность перекрыть адрес OCSP-сервера для конкретного сертификата – в разделе конфигурации про нужный сервер можно задать команду:
Это позволяет делать схемы вида “ферма nginx-серверов обращается к специальному серверу, кэширующему с запасом по времени OCSP-ответы и очень часто их проверяющему”, делая работу фермы более быстрой, снимая с nginx’ов несвойственные им задачи по сверхбыстрому рефрешу OCSP-ответов и улучшая надёжность всей системы. Грубо говоря, можно поставить специальный узел, который будет раз в 30 секунд бегать за OCSP-ответом про используемый сертификат (или сертификаты), и практически мгновенно реагировать на ситуацию “отозвали”, а также замаскирует реальные адреса серверов, которым нужна эта информация.
Дополнительной мерой безопасности будет проверка OCSP-ответа:
Это подстрахует от ситуации “нам отдали некорректно подписанный ответ и мы его, не читая, прикрепили к ответу для клиента, и клиент проверил его и понял, что он сбойный”.
В случае правильной настройки внешние средства проверки будут определять поддержку OCSP Stapling примерно так:
Что там у клиентской стороны?
OCSP Stapling со стороны клиентов
Основная задача для OCSP Stapling – это, конечно, упрощение жизни веб-браузеров. Большинство из них на этот момент (апрель 2018 года) давно уже имеют поддержку OCSP Stapling.
Проверить свой браузер можно, например, по ссылке на браузерный тест SSLLabs. Браузер с поддержкой OCSP Stapling будет выдавать что-то такое:
В некоторых браузерах можно будет управлять этой возможностью – т.е. говорить явно “если с ответом сервера идёт какая-то доп.инфа, называющаяся OCSP Response, то читай/игнорируй её”. В Firefox, например, так:
Вообще, как только речь идёт не о связке “веб-сервер – браузер”, лучше всего в явном виде убедиться, что OCSP Stapling поддерживается системой. К примеру, почтовый сервис Postfix не поддерживает OCSP вообще, исходя из логики “клиенту надо, пусть он и проверяет”. В плане почтового edge-сервера это, кстати, даже логично.
Далее, если перейти от ПО к компонентам ПО, то тоже будут особенности реализации. Например, возможность управления OCSP Stapling будет встроена в Windows’овскую реализацию Kerberos – что удивительно, т.к. в системе глобально этой возможности нет.
Вы сможете настроить следующее – использовать ли прикреплённый Kerberos-сервером ответ с OCSP-информацией, либо игнорировать и следовать к явно указанному в сертификате OCSP-серверу. Как понятно, всё это возможно только в случае, когда контроллер домена работает на NT 6.0 и выше, и имеет сертификат со специфичным OID’ом про Kerberos.
Так что обычно единица в этом ключе и упрощает настройки, и ускоряет работу Kerberos – но, опять-таки – именно когда у вас “усиленный” вариант, с дополнительной валидацией DC через x.509v3.
Далее – технология OCSP Must-Staple.
OCSP Must-Staple
OCSP Must-Staple (см. RFC 7633) – технология, нужная для дальнейшей оптимизации работы с TLS-серверами. Идея достаточно проста – в сертификат добавляется OID, который указывает на то, что к этому сертификату всегда должен идти “прикреплённый” OCSP-ответ. Браузер, таким образом, запрашивая сертификат сразу же получает сигнал о том, что сервер должен к этому ответу приложить OCSP – или, если не приложит, то это ленивый сервер и с ним надо разорвать связь. То есть клиентский браузер чётко знает – “я сам ходить за OCSP даже пробовать не буду – мне должны прислать валидный OCSP-ответ”. Что, как понятно, упрощает алгоритм подключения и исключает задержку на “решаем, так OCSP-ответ нам пришлют или самим сходить надо будет”.
Ещё раз – именно должны. Ваш сервер, предъявляя такой сертификат, подписывается под то, что к TLS-ответу будет прикреплён OCSP.
Добавить OCSP Must-Staple в сертификат несложно – это OID 1.3.6.1.5.5.7.1.24, со значением 5. Сделать это надо на фазе создания CSR, т.е. запроса на сертификат. В случае OpenSSL это будет выглядеть так – в openssl.conf в раздел “параметры запроса” надо будет добавить вот такую строчку:
(в случае старых версий OpenSSL, до 1.1.0, надо будет явно написать OID, т.к. там название status_request ещё не известно – и строчка будет 1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05).
[ req ] default_bits = 4096 default_keyfile = тут путь до файла с закрытым ключом/private.key distinguished_name = req_distinguished_name encrypt_key = no prompt = no req_extensions = req_v3_web
[ req_distinguished_name ] countryName = CN stateOrProvinceName = Hong Kong localityName = Hong Kong organizationName = Advanced Training commonName = www.atraining.ru
[ req_v3_web ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @alt_names 1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05
[ alt_names ] DNS.1 = www.atraining.ru DNS.2 = atraining.ru
Поэтому то, что хорошо для сертификатов веб-сервера – необязательно хорошо для любого сертификата вообще.
Использовать этот конфигурационный файл можно примерно так:
Т.е. первой строчкой создаём ключевую пару RSA на 4096 бит, второй – делаем из открытого ключа запрос на сертификат, учитывая конфигурацию в файле atraining-ru.conf (приведён выше).
После этот CSR можно использовать для запроса сертификата у любого CA. Варианты запроса через веб, где надо открыть CSR в блокноте и закопипастить в окошко, рассматривать не будем из-за тривиальности – рассмотрим в качестве примера распространённый сервис Let’s Encrypt.
OCSP Must-Staple для Let’s Encrypt / certbot
Разве что учитывайте, что файл cli.ini будет перекрывать собой настройки для конкретных сертификатов – т.е. если на одной системе у вас пачка доменов, и certbot регулярно пробегает и обновляет сертификаты, то заданное в cli.ini будет перекрывать всё остальное. С “айтишной” точки зрения это непривычно – общая настройка “для всей системы” перекрывает более специфичные частные. Однако тут логика чуть другая – файл cli.ini – это “то, что по умолчанию добавлять как будто бы админ это руками к каждому запросу дописывает”. Так что прописывайте OCSP Must-Staple в cli.ini только если это точно надо для всех сертификатов на данной системе, если же нет – то добавьте только в нужные.
Выглядеть это в результате будет примерно так:
Никаких специальных действий именно в настройках сервера – не нужно. Расширение OCSP Must-Staple – это просто атрибут в сертификате, чтобы клиент точно знал, что “я всегда присылаю OCSP вместе с сертификатом” и упрощал логику выбора поведения.
OCSP Expect-Staple
Заголовок сделан полностью по аналогии с HSTS, про который подробно есть в статье про настройку TLS. Выглядеть он будет например так:
max-age=31536000; report-uri=»https://www.atraining.ru/report-uri/expect-staple»; includeSubDomains; preload
Это, как понятно, само тело заголовка – а его добавление в случае nginx будет выглядеть, например, так:
add_header Expect-Staple ‘max-age=31536000; report-uri=»https://www.atraining.ru/report-uri/expect-staple»; includeSubDomains; preload’;
В идеальном случае после добавления этого заголовка и повторного обхода hstspreload.org запись про ваш домен будет доступна подключающимся самый первый раз браузерам и они сразу же будут и подключаться по TLS, и ждать OCSP-ответа, и ругаться по указанному в Expect-Staple report-uri про то, что такого ответа нет (про настройку report-uri можно прочитать здесь). Фактически, первичное подключение станет быстрее и безопаснее. Вот здесь можно посмотреть на процесс реализации Expect-Staple в Chromium.
Выглядит добавленный заголовок Expect-Staple примерно так:
Что ж, теперь можно про всякое дополнительное.
Вспомогательные вопросы при работе с OCSP
Действия, нужные со стороны сервера и клиентов – примерно понятны. Что пригодится админу?
Как определить время кэширования OCSP-ответа
Вы можете вручную посмотреть прикреплённый OCSP-ответ и увидеть срок годности. Например так:
Надо ли предварительно подготавливать OCSP-ответы
В различных источниках бытует мнение о том, что OCSP – плохая технология, потому что самый первый клиент будет подключаться, а OCSP-ответа нет. Поэтому предлагаются схемы типа “давайте после старта веб-сервиса сами к себе обратимся, сымитировав самого первого клиента, чтобы этот вопрос был снят”.
Идея неплохая, но есть мнение, что проще ускорить процесс кэширования OCSP-ответа, а также грамотно настроить тайм-ауты. Тайм-ауты OCSP – это время, за которое веб-сервер, получив запрос от клиента на OCSP Stapling, должен сбегать к OCSP responder’у и принести этот ответ. Соответственно, вопросы быстродействия сети, скорости разрешения DNS-имён и поиска рабочего OCSP responder’а из нескольких – весьма актуальны. Не бойтесь выставить тайм-ауты на 10 или даже 15 секунд – это не приведёт к замедлению работы с клиентом, это приведёт к снижению до нуля числа отбоев по причине “извини, братишка, не успел OCSP тебе передать – вот тебе TLS-ответ формата “уж как могу””.
В nginx существует возможность брать OCSP Stapling из файла – это делается через команду ssl_stapling_file и предполагает некий фоновый скрипт, который регулярно (это несложно, зная срок годности OCSP-ответа) ходит наружу и перезаписывает этот файл в случае получения удачного ответа. Применять ли этот метод – решать вам; в больших развёртываниях зачастую проще сделать отдельные системы, прекэширующие все OCSP-ответы для нужных сертификатов и очень быстро доступные для линейки проксирующих и выполняющих SSL termination серверов.
Теперь чуток про безопасность OCSP.
Вопросы безопасности OCSP
Казалось бы – удивительное дело; речь ведь идёт о технологии, которая в подавляющем большинстве случаев ускоряет проверку отзыва сертификата. Вроде как никаких дополнительных вопросов безопасности здесь быть не должно. Однако они есть, и их надо учитывать.
Концептуальная проблема зависимости от третьей стороны
В прекрасно мире высокотехнологичного будущего PKI занимает особое место – помимо ореола чистой науки и математики, PKI базируется на истинной независимости от сторонних участников в вопросе проверки подлинности. В самом деле, вы можете проверить сертификат на валидность лишь обладая нужным ПО, реализующим хорошо известные криптоалгоритмы. Каждая проверка – что повторное вычисление хэша, что проверка цифровой подписи – упрётся в строгую математику, которая скажет, что “если хэши разные – то речь точно о разных входных данных”, или “если то, что обработано открытым ключом, не сходится добитово с тем, что было обработано закрытым – значит, это не пара ключей”.
Проверка на отзыв сертификата базировалась на том, что у вас есть файл со списком отозванных сертификатов. Файл подписан CA, которому вы доверяете. Вы проверяете наличие нужного сертификата в этом файле как вам хочется и когда вам хочется.
В случае же OCSP мы получаем посредника, который не показывает нам оригинальный CRL-файл. Он получает от нас запросы и отвечает, подтверждая лишь свою подлинность. Ответ OCSP responder’а не содержит подтверждения подлинности ответа – лишь то, что ответ получен в определённое время и не был прочитан/модифицирован по пути от вас, запрашивающего, до него, отвечающего.
Проблема разглашения информации при OCSP-запросе
Вы отчитываетесь “какой я сертификат сейчас обрабатываю”, отправляя его идентификатор на OCSP-сервер. Он ведёт логи и имеет список “в какое время с какого адреса какой сертификат проверяли” – что, при доступности базы CA “какой сертификат с каким id я выдал какому домену”, даёт отличную картинку “вот на какие домены ходят с этого сетевого адреса”. При приближении числа SSL/TLS-сайтов к 100% – картинка становится всё более чёткой. Да, а вкупе с тем, что для внутренних систем предприятия – от электронной почты до RDP-серверов – тоже принято запрашивать “нормальные сертификаты от внешних PKI” – то картинка прекрасно дополняется журналированием “на какие внутренние сервера, опубликованные снаружи, ходит”.
Да, и чем более подробно информация о сертификатах дробится – например, “а чё мелочиться, на каждый FQDN по сертификату запросим, бесплатные же” – тем картинка ещё детальнее, потому что вообще однозначная связь “сертификат с серийником N = домену www.example.com”.
Работаете через VPN? Не беда; вы навряд ли пользуетесь PPTP, а значит попадаете на проверку на отзыв сертификата сервера, и делаете это исключительно разово при установке соединения. Ну, а обращаясь к локальным ресурсам уже после того, как VPN заработал – даже если по адресу вида https://192.168.0.1/ – вы все равно, получая сертификат, автоматически проверяете его через соединение, которое используется для работы с Интернет, а значит все равно показываете наружу “какой внутренний сервер я открываю и когда”. Вся информация опять-таки прозрачно сводится воедино, т.е. запросы выходят из-под одного адреса.
Как понятно, в серьёзных решениях по части безопасности вопрос маскировки OCSP-запросов и связанных с ними DNS-запросов – действительно актуален. И сбрасывать со счетов свою собственную, хорошо работающую PKI-инфраструктуру – рано, несмотря на крики про “да есть бесплатные вроде работающие в принципе нормальные сервисы”. Есть, но вопросы их монетизации – как всегда, под покровом лозунгов про Свободу и Открытость – достаточно очевидны. И “в принципе нормальные” – это не “отличные” и даже не хорошие – а “и так сойдёт”. Что далеко не во всех случаях пригодно для применения.
Резюме
Правильная настройка работы OCSP и связанных с этой технологией механизмов может улучшить безопасность и увеличить скорость работы HTTPS-сайтов. Так как сейчас практически весь Интернет состоит именно из них – то не забудьте об этой “мелочи”.