Технология в деталях №15, май 2021

Отзыв сертификатов

Фото аватара
Джефф Хьюстон

PKI (Public Key Infrastructure, Инфраструктура открытых ключей) – это система, предназначенная для поддержки электронно-цифровых подписей (ЭЦП) с открытым/закрытым ключом в системе со структурированным транзитивным доверием. Смысл PKI в том, чтобы обеспечивать доверительные отношения между сторонами, которые, возможно, никогда не встречались и никогда не встретятся друг с другом. Обычно в PKI используются сертификаты X.509 с открытым ключом. Это цифровые объекты, содержащие проверяемое заявление о том, что издавший его удостоверяющий центр (УЦ) убедился — посредством процедур, описанных в его регламенте (Certificate Practice Statement, CPS), — что держатель данной конкретной пары «открытый/закрытый ключ» соответствует определенным критериям, перечисленным УЦ. Затем УЦ публикует сертификат, который связывает имя субъекта (например, личные данные для сертификатов идентичности или имя DNS для сертификатов доменных имен) с открытым ключом владельца, а затем добавляет к этому объекту электронно-цифровую подпись, сгенерированную с помощью закрытого ключа УЦ. Это действие, с одной стороны, проверяемо любой стороной, знающей открытый ключ УЦ, а с другой – не может быть впоследствии отозвано этим УЦ.

Сертификаты X.509 с открытым ключом используются для самых разных целей, так как поддерживают аутентичность, проверку подлинности и атрибуцию. Например, если человек подписывает электронный документ своим сертифицированным закрытым ключом, то затем любой, кто обратится к связанному сертификату идентичности, может проверить (это и есть проверяемость), что документ подписал именно тот самый человек (атрибуция) и что документ не менялся (аутентичность), подразумевая, что проверяющий доверяет практикам выпуска сертификатов в данном удостоверяющем центре.

В контексте Интернета мы наблюдаем рост популярности PKI в онлайне, поскольку веб-сайты публикуют свой контент с помощью протокола Transport Layer Security (TLS) (как видно по префиксу HTTPS в URL). Благодаря веб-PKI клиент может проверить аутентичность удаленного сервера, гарантировать, что транзакцию никто не подслушает, а содержимое транзакции никто не изменит, а также что сервер не может отказаться от проделанной транзакции. Очевидно, такой уровень доверия жизненно важен для Интернета, а следовательно, жизненно важен и фундамент этого доверия – система сертификации владельцев доменных имен. Сертификаты X.509 бывают самого разного вида, и их использование в том или ином контексте обычно определяется параметрами стандартного профиля. Стандартный профиль сертификатов X.509 для использования в Интернете закреплен в стандарте RFC 5280.

Доверие не вечно, поэтому не следует считать вечными и сертификаты. Сертификат X.509 с открытым ключом содержит два поля данных: notBefore и notAfter, – указывающих диапазон времени, в течение которого сертификат можно использовать. (Однако, полноты ради, нельзя не отметить, что на случай вечного доверия в RFC 5280 для поля notAfter предусмотрено значение «forever»!) В управлении сертификатами принято ставить в поле notBefore дату выдачи сертификата, а в поле notAfter – конец периода, предусмотренного контрактом или соглашением между УЦ, выдавшим сертификат, и субъектом.

Если субъекту требуется продлить сертификацию после даты в поле notAfter, ему положено обратиться за новым сертификатом до истечения срока действия текущего. Раньше, до прихода Let’s Encrypt на рынок сертификатов SSl/TLS, типичный период действия сертификата составлял 1-2 года. Теперь Let’s Encrypt прочно закрепился на рынке, а у его сертификатов период действия составляет 90 дней, поэтому средний по отрасли срок действия сертификата снизился.

В жизни всегда есть место неожиданностям, и сертификаты X.509 не исключение. Бывают ситуации, когда сертификаты нужно помечать как недействительные до наступления даты в поле notAfter. Причины бывают самые разные: от компрометации открытого ключа до выдачи сертификата по ошибке. Или, может быть, владелец сертификата перестал заниматься тем, для чего он ему требовался, или случилось что-то другое – вариантов масса.

Как же можно объявить сертификат недействительным (как еще говорят, отозвать или аннулировать его)? Для этого УЦ, выдавший сертификат, должен удалить его из своего репозитория, чтобы он стал недоступен для загрузки и использования проверяющими сторонами. Но ведь многие проверяющие стороны хранят копии сертификатов локально до истечения срока их действия. Как сообщить такой третьей стороне, что сертификат аннулирован и больше не может применяться для установки доверительных отношений? Например, как можно на практике поставить браузер в известность о том, что сертификат, используемый для установки сеанса TLS, отозван УЦ и сеанс нельзя открывать?

Перед тем как вдаваться в тонкости механизмов отзыва сертификатов, я хочу отметить еще один момент – отмену отзыва (unrevocation). При отзыве сертификата УЦ создает запись метаданных о том, что сертификат непригоден для пользования, но не выпускает измененного сертификата, который бы зафиксировал факт отзыва. Поэтому в теории УЦ может впоследствии просто убрать метаданные об отзыве сертификата, а поскольку сам сертификат при этом не изменился, его снова можно разместить в репозитории. Статус опубликованного сертификата после удаления метаданных об отзыве станет совершенно тем же, каким он был до отзыва. Это и есть отмена отзыва сертификата. На практике, однако, это очень плохая идея, и УЦ не стоит так поступать. Гораздо лучше обозначить восстановление доверия выпуском нового сертификата с новым серийным номером для того же субъекта. Новый сертификат может использовать ту же пару «открытый/закрытый ключ» или другую, и это решение должен принимать субъект, а не УЦ. А причина того, почему УЦ не следует пытаться срезать углы, отменяя отзыв сертификатов, заключается в том, что УЦ не имеет никакого контроля над обращением сторон с метаданными об отзыве. Вполне возможно (и даже разумно) для проверяющей стороны считать отзыв сертификатов необратимым и просто удалять аннулированные сертификаты из своего локального доверительного набора на все их оставшееся время действия. То есть проверяющая сторона может на практике расценивать отзыв сертификата как необратимое действие. А значит, УЦ ничего не может сделать, чтобы заставить такие проверяющие стороны восстановить состояние доверия к таким отозванным сертификатам, то есть по факту УЦ вынужден и сам расценивать отзыв сертификата как необратимое действие.

Списки отзыва сертификатов (CRL)

В инфраструктуре PKI удостоверяющие центры регулярно публикуют подписанные списки отзыва сертификатов (Certificate Revocation List или CRL). Такой CRL содержит список серийных номеров всех отозванных сертификатов с неистекшим сроком действия, выпущенных именно этим УЦ, с указанием времени отзыва для каждого. Также в CRL указываются дата выпуска самого CRL и ожидаемая дата публикации следующего для этого УЦ. CRL подписываются закрытым ключом удостоверяющего центра, который выпускает CRL. Стандартный профиль CRL для использования в Интернете закреплен в RFC 5280.

CRL задуман как полный документ, в том смысле, что на дату, указанную в нем, он содержит все отозванные сертификаты с неистекшим сроком действия для данного УЦ в данной области охвата (scope). Если областью охвата CRL является весь набор сертификатов, выпущенных этим УЦ, то получается следующее: если у сертификата не истек срок действия и он не значится в CRL, значит, этому сертификату можно доверять до момента выпуска следующего CRL.

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

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

Чем больше непросроченных отозванных сертификатов, тем массивнее оказывается CRL. Для крупного удостоверяющего центра нагрузка, связанная с обработкой CRL, может оказаться существенной. Отправлять каждый раз полный список всех отозванных сертификатов может показаться немного чересчур, особенно если автор запроса всего-то хотел узнать статус отзыва какого-то конкретного сертификата. Кроме того, генерация CRL не является обязательным требованием к работе удостоверяющих центров. УЦ может по своему выбору публиковать CRL регулярно, либо публиковать CRL и дополнять их так называемыми дельта-CRL, или вообще не публиковать CRL! Поэтому, как правило, CRL не используются конечными клиентами при создании сеансов TLS.

Протокол OCSP

OCSP (Online Certificate Status Protocol) – это альтернатива использования CRL. Клиент генерирует запрос OCSP, содержащий серийный номер сертификата, и отправляет его в УЦ, выдавший этот сертификат. В ответ на запрос УЦ отправляет подписанный отчет о статусе сертификата, где указывает, действителен ли сертификат или отозван. Этот протокол описан в RFC 6960.

Запрос OCSP является объектом ASN.1, содержащим один или несколько серийных номеров сертификатов, которые отправитель просит УЦ проверить. Ответ OCSP подписывается цифровой подписью УЦ, выпустившего сертификат, или назначенного УЦ респондера. Ответ содержит идентичность респондера, время ответа, ответы по каждому сертификату в запросе и необязательные дополнения. Коды ответов, используемые в OCSP, означают, что сертификат:

  • либо годен, что по сути означает – сертификат с таким серийным номером, выданный этим УЦ, не отзывался. В RFC 6960 это объясняется так: «Этот статус не обязательно означает, что сертификат вообще выдавался или что время, в которое был сгенерирован ответ, находится в пределах интервала действия сертификата»;
  • либо отозван, что означает – сертификат отозван, но его срок действия не истек; но также этот статус может означать, что данный УЦ не выдавал сертификата с таким серийным номером;
  • либо неизвестен, что означает – данный УЦ не распознает указанный серийный номер.

Дополнения к ответу могут включать в себя случайный код (nonce), который криптографически связывает запрос с ответом для предотвращения атак на ответ. Также можно указать ссылку на CRL. Ответы OCSP могут также содержать четыре значения времени:

  • thisUpdate – время генерации этой информации о статусе респондером;
  • nextUpdate – время, когда будет доступна обновленная информация;
  • producedAt – время подписания ответа респондером;
  • revocationTime – время отзыва сертификата.

Благодаря наличию этих полей клиент может кэшировать ответ OCSP вплоть до наступления времени nextUpdate. Ответы OCSP могут генерироваться заранее, при этом время генерации ответа указывается в поле producedAt.

Использование OCSP ставит ряд вопросов о конфиденциальности: раз клиент обращается в УЦ, значит, УЦ становится известно о том, какие клиенты используют этот сертификат и когда – для этого достаточно отследить источник запроса.

Кроме того, возникают проблемы с быстродействием, так как генерация запроса OCSP и ожидание ответа требует времени. Запрос не обязан быть единичным, так как осторожный клиент проверит не только статус отзыва сертификата, используемого сервером, но и статус отзыва всех сертификатов этого УЦ, используемых клиентом для формирования цепочки проверки от якоря доверия до этого сертификата.

Одним из вариантов решения проблемы, связанной с проверкой статуса сертификатов по требованию, является упаковка ответа OCSP и самого сертификата в одно целое – эта структура называется OCSP stapling («подшивка» OCSP, описана в RFC 6961). Поскольку ответ OCSP уже подписан и датирован CA, а сервер знает, какой сертификат он передавал клиенту, он также знает, какие запросы OCSP клиент будет направлять для проверки того, не отозвал ли УЦ этот сертификат. Сервер с помощью «подшивки» OCSP прикрепляет ответ OCSP к материалу TLS, используемому при «рукопожатии», и может также прикрепить ответы OCSP для других сертификатов УЦ, которые образуют цепочку проверки этого сертификата клиентом.

Тестирование отзыва сертификатов на разных браузерах

Чтобы поэкспериментировать с тем, как различные браузеры обрабатывают отозванные сертификаты, я с помощью Let’s Encrypt сгенерировал сертификат и затем отозвал его. Чтобы подтвердить, что сертификат отозван, я отправил запрос OCSP:

Служба OCSP на сервере Let’s Encrypt использует семидневные ответы OCSP. Для защиты ответа от повтора я запросил случайный код (nonce), но OCSP-сервер Let’s Encrypt не использовал его в ответе.

Потом я протестировал поведенние различных браузеров и операционных систем при попытке подключения к сайту, использующему этот отозванный сертификат, и результаты свел в таблицу 1. Сервер не был настроен на «подшивку» OCSP, поэтому браузер клиента должен был обнаружить отзыв посредством OCSP. В приведенной ниже таблице ДА означает, что браузер обнаружил отзыв сертификата, а НЕТ – что браузер подключился к сайту и объявил подключение безопасным. В таблице я также указал номера версий платформы и браузера, использованных в этом маленьком эксперименте.

Таблица 1. Опознание отозванных сертификатов браузерами

Вскрывшиеся в этом эксперименте различия в поведении браузеров обусловлены как различиями между сервисами разных платформ, так и выбором API-опций тем или иным приложением при взаимодействии с сервисами безопасности своей платформы. В наши дни подавляющее большинство людей в Интернете пользуется браузером Chrome на платформе Android. То есть получается, что большинство пользователей Интернета не проверяет сертификаты на действительность.

Стоит ли отзыв сертификатов свеч?

На первый взгляд – что за странный вопрос? Если закрытый ключ скомпрометирован, его нельзя использовать. С его помощью хакер может подменить сайт другим, а это недопустимо. Чтобы скомпрометированный ключ перестали принимать, необходимо распространить информацию о том, что данная пара ключей более недействительна, а это и достигается путем отзыва сертификата открытого ключа. По крайней мере, так думали авторы идеи сертификатов X.509 и их отзыва.

Но отзыв сертификатов используется не всегда – и даже не всегда полезен. Например, у DNSSEC, тоже использующей открытые/закрытые ключи, нет функции отзыва. Если закрытый ключ скомпрометирован, то решением будет переподписать зону свежим ключом и полагаться на то, что данные управления кэшем DNS TTL «вымоют» старые значения ключа из различных кэшей DNS. В DNS значения TTL обычно исчисляются часами или днями, а не месяцами или даже годами, как у веб-сертификатов PKI. Это означает, что окно уязвимости вследствие компрометации ключа в DNSSEC гораздо короче, чем в веб-PKI. Возможно, потому отзыв сертификатов в веб-PKI и является гораздо большей проблемой, чем в DNSSEC.

Получается, что при использовании открытого/закрытого ключа есть сценарии, в которых механизмы отзыва не считаются нужными. А как насчет обычной схемы использования сертификатов в веб-PKI? Есть ли польза от отзыва сертификатов? Или это просто еще один способ увеличить риск, добавив в структуру новые точки потенциальной уязвимости?

Для работы CRL по запросу и OCSP требуется, чтобы были доступны сервисные точки управляющего центра. В случае CRL можно полагаться на локальное кэширование списков CRL, что в известной степени смягчает требования к доступности УЦ, но для OCSP по запросу вариантов нет. Сервер OCSP должен быть доступен, мало того – доступен на скорости, соразмерной жестким временным ограничениям на установку сеанса TLS в приложении.

Для OCSP такая ситуация возможна не всегда, поэтому нужно внимательно изучить, что произойдет, если это не так. Если ответа на запрос OCSP нет, то как должен поступить клиент? Можно продолжить установку связи (принцип softfail), сделав клиента уязвимым к потенциальным опасностям, от которых и должен был защищать его OCSP. А можно поосторожничать и отказать (hard-fail), что чревато необоснованными блокировками. Сервисная точка OCSP становится точкой потенциального отказа, а в мире, и так набитом ограничениями доступа и ненадежными соединениями, последнее, что нужно – это создавать новые точки, где соединение может разорваться. Кроме того, принцип hard-fail сопряжен еще и с риском превратить серверы OCSP в лишнюю уязвимость при DoS-атаках. Похоже, что многие клиентские приложения и сервисные библиотеки операционных систем при отсутствии ответа OCSP действуют по принципу soft-fail. Это тоже уязвимость: хакер, находящийся на пути между пользователем и УЦ, может увидеть незашифрованный запрос OCSP и просто заблокировать его. Тогда функция проверки сертификата на клиенте отработает по soft-fail и сочтет отозванный сертификат действительным. В результате клиент будет доверять отозванному сертификату.

Можем ли мы сделать OCSP надежнее и противостоять атакам, удаляющим OCSP? Если проблемой является перехват запросов или ответов OCSP, то, возможно, имеет смысл перейти на обязательную «подшивку» OCSP. Это предложение описано в давно устаревшем интернет-драфте 2013 года (draft-hallambaker-muststaple-00.txt), согласно которому сервер, сообщающий сертификат при открытии сеанса TLS, также обязан был прикрепить к сертификату текущую информацию OCSP в качестве расширения. Поскольку флаг must staple находится внутри подписанного сертификата, хакер не может удалить его во время настройки сеанса TLS. В этом предложении УЦ (или, возможно, оригинальный субъект) предписывает всем серверам, использующим данный сертификат, использовать также «подшивку» OCSP. Так удается справиться с угрозами удаления OCSP и нарушения конфиденциальности, не добавляя к рукопожатию TLS дополнительных задержек на проверку действительности сертификата, которые неизбежны при отдельном обмене данными между клиентом и сервером удостоверяющего центра OCSP. В результате окно уязвимости из-за компрометации сертификата сокращается с нескольких лет (с текущего момента до прекращения срока действия сертификата) до нескольких дней (срок действия ответа OCSP).

С отзывом сертификатов связаны и другие проблемы – в том смысле, что отзыв не пресекает атаки, использующие скомпрометированные ключи. Хакер может сгенерировать с тем же скомпрометированным закрытым ключом новые учетные данные, а по ним повторно сертифицировать скомпрометированную службу. К тому моменту, когда компрометация исходного ключа будет обнаружена, хакер будет использовать новые ключи и новый сертификат, и теперь первоначальному владельцу службы придется доказывать удостоверяющему центру, выдавшему новый сертификат, что последний необходимо отозвать. Ловкий взломщик может повторить процедуру ресертификации несколько раз, все больше затрудняя усилия по вычистке незаконно полученных сертификатов из PKI.

Возможно, проблему отзыва лучше всего решить, просто отказавшись от сертификатов с большим сроком действия. Еще девять лет Адам Лэнгли (Adam Langley) из Google заметил:

Гораздо лучшим решением было бы ограничить срок действия сертификатов несколькими днями, а об отзыве просто забыть. Нет, менять закрытый ключ каждые несколько дней не надо, только сам сертификат. А сертификат относится к открытым данным, поэтому серверы могли бы просто загружать обновленные сертификаты по HTTP, периодически и автоматически (как при «подшивке» OCSP). Клиентам не нужно было бы возиться с проверками на отзыв (процедура очень сложная и долгая), УЦ не пришлось бы платить за большие серверные мощности с защитой от DDoS, а отзыв бы реально заработал. Если УЦ лег на шесть часов – ну и черт с ним. Проблема возникает только тогда, когда УЦ лежит несколько дней. А если сертификат нужно «отозвать», просто не возобновляйте его.

Есть ли другие подходы к отзыву сертификатов?

Как всегда, эта проблема тоже решается методом «а давайте используем DNS». В сравнительно недавнем интернетдрафте (от 2017 года) предлагается сделать OCSP типом записей ресурсов DNS (draft-pala-odin-02.txt). Запрос OCSP закодируется в имя запроса DNS, объединяя в себе и запрос, и ответ. Например, на запрос типа OCSP RR с именем запроса 123456.ca1.example.com последует ответ с указанием статуса OCSP у сертификата с серийным номером 123456, выпущенного УЦ с именем точки публикации ca1.example.com. Скорее всего, для аккуратной реализации потребуется также подписывать зону DNS по DNSSEC, хотя, поскольку сама запись OCSP подписана УЦ, основной смысл подписания по DNSSEC будет заключаться в гарантии наличия и актуальности.

При этом методе DNS помогает справиться с уязвимостью сервисной точки OCSP в удостоверяющем центре, поскольку эти данные кэшируются на рекурсивных резолверах DNS. Там, где такие запросы широко используются, кэширование DNS на резолверах невероятно повысит скорость запросов, даже с учетом проверки DNSSEC. Правда, если данных не будет в локальном кэше резолвера DNS, процедура будет гораздо медленнее обычного запроса и ответа OCP.

Mozilla возродила обсуждение подходов на базе CRL, разрешив проблему с объемом CRL. Ее метод – сжать эффективный размер CRL с помощью Bloom Filters, используя технику, которую назвали CRLite. Применение этого метода показало сокращение объемов данных CRL: список серийных номеров всех выданных и не отозванных сертификатов на 6,7 Гб ужался до какихто 1,3 Мб. Mozilla предлагает использовать эту технику для больших CA и возвращаться к OCSP там, где данные CRL не настроены как фильтр. Таким образом авторы метода пытаются устранить дополнительные задержки в OCSP по запросу, не полагаясь на поддержку must staple OCSP на серверной стороне, которой может и не быть.

Итак, на чем мы остановились?

УЦ выдают долгоживущие сертификаты, а это значит, что компрометация пары ключей может вылиться в уязвимость, которая будет оставаться незакрытой годами. Мы хотели бы аннулировать сертификаты быстрее. Такая возможность предоставляется списками отзыва сертификатов (CRL), но они разбухают до крупных размеров, а потому доставка «просто на всякий случай» такой горы данных клиентам вызывает проблемы. Мы обратились к OCSP, чтобы можно было запросить статус отзыва отдельного сертификата, но из-за сомнений в надежности OCSP клиентские системы применяют подход soft-fail, из-за чего доверие к отозванным сертификатам сохраняется.

Доверие

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

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

Можно последовать примеру Let’s Encrypt и выдавать лишь краткосрочные сертификаты, генерируемые с помощью автоматизированных процедур. Поскольку такие сертификаты недолговечны, их отзыв не создает больших проблем, а в перспективе можно выдавать сертификаты и на еще более короткий срок. Если списки отзыва обновляются раз в неделю, то сертификаты с недельным сроком действия можно вообще не отзывать, поскольку наличие или отсутствие отзыва мало что изменит для проверяющих сторон.

Но если мы выберем путь краткосрочных сертификатов, зачем тогда нам вообще X.509? Может быть, проще использовать DANE, закодировать ключи в DNS и обеспечение необходимой аутентичности возложить на DNSSEC, а о времени жизни кэшированных открытых ключей пусть позаботится механизм DNS TTL? С помощью расширений цепочек DNSSEC можно реализовать безопасное рукопожатие (security association handshake), при котором сервер отправляет клиенту ответ со своим открытым ключом, подпись DNSSEC и связанные ответы проверки DNSSEC, не выполняя вообще никаких запросов в DNS. Таким образом можно, подобно «подшивке» OCSP, внедрить «подшивку» DANE и цепочек DNSSEC, полностью устранив задержку запроса DNS.

Эта история еще далека от завершения. Мы наблюдаем скоростные атаки, где весь процесс внедрения, обмана и кражи данных занимает всего несколько часов, а вовсе не дни или недели. А контрмеры, на которые мы полагаемся сегодня, включая журналы прозрачности сертификатов и нерегулярное использование OCSP, оставляют в защите учетных данных дыры, которые исчисляются днями вместо секунд.

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

Ссылки и дополнительная литература

  1. RFC 5280, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, D. Cooper и др., май 2008 г. https://tools.ietf.org/html/rfc5280
  2. RFC 6960, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP”, S. Santesson и др., июнь 2013 г. https://tools.ietf.org/html/rfc6960
  3. RFC6961, “The Transport Layer Security (TLS) Multiple Certificate Status Request Extension”, Y. Pettersen, июнь 2013 г. https://tools.ietf.org/html/rfc6961
  4. “X.509v3 Extension: OCSP Stapling Required”, Internet Draft, P.Hallam-Baker, апрель 2013 г. https://tools.ietf.org/id/draft-hallambaker-muststaple-00.txt
  5. “OCSP over DNS (ODIN)”, Internet Draft, M. Pala, ноябрь 2017 г. 10. https://tools.ietf.org/id/draft-pala-odin-02.txt
  6. “Revocation Doesn’t Work”, Adam Langley, март 2011 г. https://www.imperialviolet.org/2011/03/18/revocation.html
  7. “No, don’t enable revocation checking”, Adam Langley, апрель 2014 г. https://www.imperialviolet.org/2014/04/19/revchecking.html
  8. “OCSP Stapling: How CloudFlare Just Made SSL 30% Faster”, Matthew Prince, октябрь 2012 г. https://blog.cloudflare.com/ocsp-stapling-how-cloudflare-just-made-ssl-30/
  9. “High-reliability OCSP stapling and why it matters”, Nick Sullivan, июль 2017 г. https://blog.cloudflare.com/high-reliability-ocsp-stapling/
  10. “Revocation is Broken”, Scott Helme, июль 2017 г. https://scotthelme.co.uk/revocation-is-broken/
  11. “The Problem with OCSP Stapling and Must Staple and why Certificate Revocation is still broken”, Hanno Böck, май 2017 г. https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-andwhy-Certificate-Revocation-is-still-broken.html