В криптографии с открытым ключом сертификат может быть отозван до истечения срока его действия, что означает, что он больше не действителен. Без отзыва злоумышленник может использовать такой скомпрометированный или неправильно выпущенный сертификат до истечения срока действия. Таким образом, отзыв является важной частью инфраструктуры открытого ключа . Отзыв выполняется выдавшим его центром сертификации , который создает криптографически аутентифицированное заявление об отзыве.
Для распространения информации об отзыве среди клиентов своевременность обнаружения отзыва (и, следовательно, окно для злоумышленника, чтобы использовать скомпрометированный сертификат) идет вразрез с использованием ресурсов при запросе статусов отзыва и проблемами конфиденциальности. Если информация об отзыве недоступна (из-за аварии или атаки), клиенты должны решить, следует ли использовать отказоустойчивый режим и рассматривать сертификат как отозванный (и таким образом ухудшать доступность ) или отказоустойчивый режим и рассматривать его как неотозванный (и позволить злоумышленникам обойти отзыв).
Из-за стоимости проверок отзыва и влияния на доступность потенциально ненадежных удаленных служб веб-браузеры ограничивают проверки отзыва, которые они будут выполнять, и будут давать слабые результаты там, где они это делают. Списки отзыва сертификатов слишком затратны для полосы пропускания для повседневного использования, а протокол статуса сертификата в режиме онлайн создает проблемы с задержкой соединения и конфиденциальностью. Были предложены другие схемы, но пока не были успешно развернуты для включения жесткой проверки отказов.
Уязвимость Heartbleed , которая была раскрыта в 2014 году, спровоцировала массовый отзыв сертификатов, поскольку их закрытые ключи могли быть раскрыты. GlobalSign отозвала более 50% выпущенных ими сертификатов. StartCom подверглась критике за выпуск бесплатных сертификатов, но затем взимание платы за отзыв. [1]
Исследование 2015 года выявило общий уровень отзыва 8% сертификатов, используемых в Интернете, [2] хотя этот показатель мог быть повышен из-за Heartbleed. [3]
Несмотря на то, что веб-безопасность является приоритетом для большинства браузеров , из-за задержек и требований к пропускной способности, связанных с OCSP и CRL, браузеры накладывают ограничения на проверку статуса сертификата. [4] В 2015 году Google Chrome активно проверял только сертификаты расширенной проверки , ни один мобильный браузер не выполнял никаких проверок действительности, и ни один браузер не проверял полностью все сертификаты. [5] Chrome и Firefox выполняют проверки на основе push-уведомлений для небольшого набора доменов, которые считаются критически важными. [6] Браузеры демонстрируют мало согласия в особых случаях, касающихся действительности сертификата, что может сбить с толку даже опытных пользователей. [7]
Количество сертификатов в Web PKI значительно возросло в течение последней части 2010-х годов, с 30 миллионов в январе 2017 года до 434 миллионов в январе 2020 года. Значительным фактором этого роста является предоставление Let's Encrypt бесплатных сертификатов с проверкой домена . Размер потенциально отзываемого набора сертификатов предъявляет требования к масштабируемости механизма отзыва. [4]
Чуат и др. (2020) называют отзыв «крайне сложной задачей». [8] В 2022 году RFC 9325 охарактеризовал отзыв сертификата как важную проблему, «не имеющую полного и эффективного решения». OCSP и сшивание OCSP рекомендуются в качестве «основы для возможного решения». [9]
Отзыв сертификата является «важным инструментом» для борьбы с атаками и случайными компрометациями. RFC 9325 предъявляет нормативное требование к реализациям TLS, чтобы они имели некоторые средства недоверия к сертификатам. [9] Без отзыва злоумышленник может использовать скомпрометированный сертификат, чтобы выдавать себя за его владельца до истечения срока действия. [4]
Отзыв может не потребоваться для сертификатов с достаточно коротким сроком действия, примерно порядка часов или дней, что сопоставимо со сроком действия ответа OCSP. Сопутствующая частая выдача сертификатов обычно требует автоматизации (например, протокола ACME) и может нагружать другие инфраструктурные элементы (например, журналы прозрачности). [10] Краткосрочные сертификаты также создают сложности с возобновлением соединения TLS , хотя и не обязательно непреодолимые. [11]
Отзыв может быть инициирован держателем сертификата (который, например, может знать, что закрытый ключ был скомпрометирован), который информирует CA. Затем CA создает и распространяет криптографически аутентифицированные подтверждения того, что сертификат был отозван. [12] Требования CA/B также позволяют CA автономно отзывать сертификаты, если CA известно о возможности компрометации. [13] Любой может предоставить такие доказательства. [14]
Статусы отзыва обычно не сохраняются и не архивируются в течение длительного времени после истечения срока действия сертификата, что затрудняет исследование и аудит поведения при отзыве. [15] Одно из предложений по решению этой проблемы заключается в отправке «постсертификатов» в журналы прозрачности сертификатов для каждого отзыва, что также позволит выполнять отзыв без действий со стороны CA; [16] альтернативное предложение, также основанное на прозрачности сертификатов, предполагает отправку CRV в журналы CT центрами сертификации. [17]
Если статус отзыва недоступен (что может быть безобидным или вызвано атакой), клиент сталкивается с дилеммой при оценке сертификата: он может выполнить soft-fail и предположить, что сертификат все еще действителен; или он может выполнить hard-fail и предположить, что сертификат был отозван. Это компромисс между безопасностью и доступностью: soft-fail допускает атаки понижения , в то время как hard-fail допускает отказ в обслуживании (из-за атак) или приводит к недоступности. [18]
Злоумышленник, способный предоставить скомпрометированный сертификат, вероятно, также имеет возможность помешать клиенту выполнить проверку статуса отзыва в режиме онлайн; в этом случае failing-soft фактически не обеспечивает никакой защиты вообще. Браузеры выбрали эту сторону дилеммы и предпочли доступность безопасности. [19]
Failing-hard может ввести новые векторы атак типа «отказ в обслуживании». Например, если клиенты ожидают сшивания OCSP и fail-hard в противном случае, отказ в обслуживании против OCSP-ответчиков усиливается до отказа в обслуживании против всех служб, желающих использовать эти ответы OCSP. [10]
Существует два сценария оценки использования ресурсов: нормальные условия и массовые события отзыва. Схемы отзыва должны быть эффективными в нормальных условиях и функциональными во время массовых событий отзыва. [4]
Получение информации об отзыве влечет за собой затраты на пропускную способность и задержки для клиентов. [20]
Во время массового отзыва сертификатов Heartbleed в 2014 году , когда уровень отзыва вырос с 1% до 11%, Cloudflare подсчитала, что пропускная способность , которую GlobalSign использовала для распространения списков отзыва сертификатов, могла стоить 400 000 долларов США (что эквивалентно 510 000 долларов США в 2023 году [21] ). [22]
Если статус отзыва не извлекается заново для каждой проверки (например, из-за кэширования или периодических извлечений), существует задержка между отзывом сертификата и гарантированным получением всеми клиентами информации об отзыве. Это представляет собой компромисс между задержкой, эффективностью и безопасностью: более длительное время кэширования или менее частые обновления используют меньше ресурсов и сокращают задержку, но означают, что скомпрометированный сертификат может использоваться дольше. [23]
Клиенты, которые выполняют проверки на основе запроса, могут передавать информацию о просмотренных пользователем страницах третьим лицам, а именно распространителю информации об отзыве. [24]
Желательно избегать создания доверенной третьей стороны в PKI. Если субъект в схеме поддается аудиту, то клиенты (или агенты, действующие от имени клиентов) могут доказуемо подтвердить, что субъект ведет себя правильно. [25]
Распределение статуса отзыва, которое возлагает тяжелое бремя на CA, может не увенчаться успехом, особенно если CA не может получить компенсирующие выгоды от внедрения. Сокращение числа сторон, которые должны вносить изменения для его принятия, также облегчает развертывание: потенциально вовлечены CA, клиенты, администраторы серверов и производители серверного программного обеспечения. Прямая совместимость — палка о двух концах, поскольку старые клиенты и серверы не будут нарушены новой схемой, но их пользователи могут не осознавать, что они теряют преимущества отзыва. [26]
Существует три основных архитектуры доступа клиентов к статусу отзыва: основанная на извлечении , когда клиенты извлекают статус отзыва во время проверки; основанная на проталкивании , когда клиенты извлекают статус отзыва до проверки и кэшируют его; и сетевая архитектура , когда проверка отзыва тесно интегрирована с протоколом TLS, и отдельные проверки могут не потребоваться. [27]
Проверка на основе pull-based обычно имеет проблемы с задержкой и доступностью. Клиенты, выполняющие проверку на основе pull-based, обычно кэшируют ответы на короткий период. Чистая проверка на основе pull-based в сочетании с failing-soft не добавляет безопасности. [28]
Проверка на основе push-уведомлений менее эффективна с точки зрения пропускной способности, чем проверка на основе pull-уведомлений, но обеспечивает доступность и конфиденциальность. Различные методы могут использоваться на основе сертификата за сертификатом, что позволяет точно настроить компромисс: и Google Chrome , и Mozilla Firefox выполняют проверки на основе push-уведомлений для небольшого набора критических сертификатов. [28]
Список отзыва сертификатов (CRL) перечисляет отозванные сертификаты. Они криптографически аутентифицированы выдавшим CA. [29]
Списки CRL имеют проблемы с масштабируемостью и зависят от наличия у клиента достаточного сетевого доступа для их загрузки перед проверкой статуса сертификата. [9]
CRL содержит информацию обо всех сертификатах, отозванных CA, что означает, что дистрибьюторы и клиенты должны нести расходы на передачу информации, которая, скорее всего, не имеет значения. [30] Исследование 2015 года показало, что медианный сертификат имел CRL размером 51 КБ, а самый большой CRL составлял 76 МБ. [2]
Протокол статуса сертификата в режиме онлайн (OCSP) позволяет клиентам интерактивно запрашивать сервер ( ответчик OCSP ) о статусе сертификата, получая ответ, который криптографически аутентифицирован выдавшим его центром сертификации. [29] Он был разработан для решения проблем со списками отзыва сертификатов. [30] Типичный ответ OCSP составляет менее 1 КБ. [31]
OCSP страдает от проблем с масштабируемостью. Он полагается на наличие у клиента доступа к сети во время проверки статуса отзыва сертификата; кроме того, ответчик OCSP должен быть доступен и выдавать пригодные для использования ответы, иначе проверка не пройдет, и клиент должен будет выбрать между отказом-мягким и отказом-жестким. Многие центры сертификации не публикуют полезные ответы OCSP для промежуточных сертификатов . [9]
Поскольку запросы к ответчику делаются в ответ на просмотры пользователей, ответчики OCSP могут узнать о просмотре пользователей, что является проблемой конфиденциальности . Это также вносит задержку в соединения, поскольку ответчик должен быть запрошен, прежде чем можно будет использовать новое соединение. [18]
Исследование 2018 года показало, что 1,7% запросов к ответчикам были недоступны на сетевом уровне, а еще около 2% давали непригодные ответы OCSP со значительной неоднородностью по центрам сертификации и точкам наблюдения клиентов. [32]
Сшивание OCSP — это расширение TLS, обеспечивающее отправку ответов OCSP клиенту вместе с сертификатом при инициировании соединения. [30]
Сшивание OCSP может решить эксплуатационные проблемы OCSP, а именно дополнительные сетевые запросы, вызывающие задержку и ухудшение конфиденциальности. [33] Однако оно может быть подвержено атакам с понижением уровня со стороны злоумышленника на пути. [9] RFC 7633 определяет расширение, которое встраивает требование в сертификат, чтобы быть сшитым с допустимым ответом OCSP. [34] С этим расширением сшивание может быть эффективным в случае, когда сертификат был скомпрометирован после надлежащей выдачи; однако, если сертификат может быть неправильно выдан без расширения, сшивание может не обеспечить никакой безопасности. [35]
Помимо клиентов и CA, включающих сшивание и расширение must-staple, администраторы серверов также должны предпринять действия для поддержки сшивания, регулярно получая ответы и затем предоставляя их клиентам во время рукопожатия. В 2018 году только Firefox поддерживал must-staple, и ни один из двух наиболее используемых веб-серверов ( Apache httpd и Nginx ) вообще не поддерживал сшивание OCSP. [36]
CRLite предоставляет статусы отзыва с помощью каскада фильтров Блума . Один фильтр, созданный из списка отозванных сертификатов, дает ложные срабатывания . При открытом домене это непреодолимая проблема для проверки отзыва. Однако, используя Certificate Transparency для перечисления всех неистекших сертификатов, можно получить исчерпывающий список ложных срабатываний. Затем этот список используется для построения второго фильтра, к которому обращаются, если сертификат совпадает с первым (и, следовательно, имеет строго меньший домен); если второй фильтр не совпадает, то это истинное срабатывание, и сертификат был отозван; однако совпадение во втором фильтре может быть ложным срабатыванием, что требует третьего фильтра и т. д. Поскольку вселенная конечна, а домен каждого фильтра строго уменьшается на каждом шаге, эта процедура создает конечный каскад фильтров. [37]
CRLite позволяет клиентам быть отказоустойчивыми. [23]
Статус отзыва всех сертификатов в Web PKI в январе оценивался в 10 МБ при использовании каскада фильтров Блума с обновлениями 580 КБ в день. В марте 2018 года этот показатель вырос до 18 МБ. [28] При моделировании со 100 миллионами сертификатов, 1% ежедневным сроком действия и 2% уровнем отзыва CRLite потребовал первоначального предоставления 3,1 МБ, а затем 408 КБ в день для обновлений. [38]
Поскольку все клиенты получают одну и ту же информацию, CRLite не имеет проблем с конфиденциальностью. [23]
CRLite пока не получил широкого распространения. [9] Однако его можно развернуть, для этого требуется только агрегатор для извлечения списков CRL из центров сертификации, а затем предоставления каскада фильтров и обновлений для него, а также для использования его клиентами; никаких действий со стороны центров сертификации не требуется, как и никаких действий со стороны владельцев сертификатов. [23] Агрегатору не обязательно быть доверенной третьей стороной : каскад фильтров можно проверить, чтобы доказать, что он точно отражает входящие списки CRL. [39] Частные центры сертификации также требуют специальной обработки в CRLite. [40]
Let's Revoke использует битовые векторы статусов отзыва (называемые векторами отзыва сертификатов , или CRV), чтобы позволить клиентам эффективно извлекать большие объемы статусов отзыва. [4] CA генерируют CRV для своих собственных сертификатов, с одним CRV на дату истечения срока действия. Техническое обслуживание CRV для CA линейно по количеству выданных сертификатов. CA должны добавлять новое поле, номер отзыва, к каждому выданному сертификату, позволяя идентифицировать сертификаты из одного CA по кортежу даты истечения срока действия сертификата и номера отзыва; этот кортеж позволяет клиенту эффективно находить бит, дающий статус идентифицированного сертификата в CRV. CRV могут быть сжаты; ожидается, что они будут сжиматься очень хорошо, так как большинство битов будут неустановлены большую часть времени. Поскольку каждый CRV связан с фиксированной датой истечения срока действия, старые CRV могут быть эффективно отброшены. Обновления CRV пакетируются, при этом обновление имеет временную метку и подписано для распространения среди клиентов. [41] Обновления могут быть в одной из трех форм, при этом оптимальный выбор зависит от частоты отзыва, что позволяет как эффективно осуществлять нормальную работу, так и проводить массовые события отзыва. [42]
Ожидается, что CRV будут достаточно малы для включения push-проверки, но более ограниченные клиенты могут по-прежнему выполнять pull-проверки, получая доступ только к выбранным CRV или откладывая извлечение CRV до проверки сертификата. [43] Клиент, использующий Let's Revoke с push-проверкой, может выполнить отказоустойчивую проверку для любого сертификата с номером отзыва. [23] Влияние на конфиденциальность и доступность Let's Revoke зависят от архитектуры: если все проверки основаны на push-проверке, то утечки конфиденциальности нет и снижается уязвимость к отказу в обслуживании или простою; однако, если используются pull-проверки, некоторая информация о действиях пользователя утекает (в форме, в которой осуществляется доступ к CRV), и CRV могут быть недоступны во время проверки. [23]
При моделировании со 100 миллионами сертификатов, ежедневным сроком истечения срока действия 1% и ежедневным показателем отзыва 2% Let's Revoke потребовал первоначального предоставления 2,2 МБ, а затем 114 КБ в день для обновлений. [44]
Let's Revoke пока не получил широкого распространения. [9] Помимо клиентских реализаций, он требует от CA внесения операционных изменений, [45] и не предоставляет столько информации, как CRL или OCSP (только немного на сертификат для действительности); CRL или OCSP все еще могут использоваться для дополнения Let's Revoke и предоставления этой дополнительной информации. [46] Развертывание может выполняться CA за CA, при этом клиенты постепенно получают выгоду от отказоустойчивого поведения. Благодаря эффективности CRV по сравнению с CRL и ответами OCSP, CA могут быть заинтересованы в развертывании Let's Revoke. [45]
Методы поиска конфиденциальной информации могут смягчить беспокойство о конфиденциальности с помощью проверок на основе опроса. [47] Вместо того, чтобы клиенты выполняли проверки отзыва, промежуточное устройство могло бы централизовать стоимость проверки отзыва и амортизировать ее по многим соединениям; клиентам не нужно выделять хранилище для информации об отзыве. [48] Другое предложение включало трансляцию информации об отзыве по FM-радио . [37]
{{cite journal}}: Цитировать журнал требует |journal=( помощь )