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