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

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

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

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

Глоссарий сокращений

АКМЕ

Среда автоматического управления сертификатами

ЧТО

центр сертификации

ТАКСИ

Форум CA/браузера

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

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

CRV

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

OCSP

Протокол статуса онлайн-сертификата

ИПК

инфраструктура открытых ключей

ТЛС

Безопасность транспортного уровня

История

Уязвимость Heartbleed , обнаруженная в 2014 году, спровоцировала массовый отзыв сертификатов, поскольку могла быть утечка их закрытых ключей. GlobalSign отозвала более 50% выданных сертификатов. StartCom подвергся критике за выдачу бесплатных сертификатов, но затем взимание платы за отзыв.

Исследование 2015 года показало, что общий уровень отзыва сертификатов, используемых в Интернете, составляет 8%. хотя это могло быть повышено из-за Heartbleed.

Несмотря на то, что веб-безопасность является приоритетом для большинства браузеров , из-за требований к задержке и пропускной способности, связанных с OCSP и CRL, браузеры накладывают ограничения на проверку статуса сертификата. В 2015 году Google Chrome активно проверял только сертификаты расширенной проверки , ни один мобильный браузер не выполнял никаких проверок действительности и ни один браузер не проверял полностью все сертификаты. Chrome и Firefox выполняют push-проверки для небольшого набора доменов, которые считаются критическими. Браузеры проявляют мало согласия в крайних случаях, касающихся действительности сертификата, что потенциально может сбить с толку даже опытных пользователей.

Количество сертификатов в Web PKI значительно выросло за последнюю половину 2010-х годов: с 30 миллионов в январе 2017 года до 434 миллионов в январе 2020 года. Существенным фактором этого роста является предоставление Let's Encrypt бесплатных сертификатов с проверкой домена . Размер потенциально отзывного набора сертификатов предъявляет требования к масштабируемости механизма отзыва.

Чуат и др. (2020) называют отзыв «заведомо сложной задачей». В 2022 году RFC 9325 охарактеризовал отзыв сертификата как важную проблему, «не имеющую полного и эффективного решения». OCSP и сшивание OCSP рекомендуются как «основа для возможного решения».

Необходимость

Отзыв сертификата является «важным инструментом» для борьбы с атаками и случайным взломом. RFC 9325 налагает нормативное требование на реализации TLS, чтобы иметь некоторые средства недоверия сертификатам. Без отзыва злоумышленник может использовать скомпрометированный сертификат, чтобы выдавать себя за его владельца до истечения срока его действия.

Отзыв может не потребоваться для сертификатов с достаточно коротким сроком действия, примерно от нескольких часов до дней, что сопоставимо со сроком действия ответа OCSP. Связанная с этим частая выдача сертификатов обычно требует автоматизации (например, протокола ACME) и может нагружать другие элементы инфраструктуры (например, журналы прозрачности). Кратковременные сертификаты также создают трудности с возобновлением соединения TLS , хотя и не обязательно непреодолимые.

Процедура

Отзыв может быть инициирован владельцем сертификата (который, например, может знать, что закрытый ключ был скомпрометирован), который информирует об этом центр сертификации. Затем центр сертификации создает и распространяет криптографически заверенные подтверждения того, что сертификат был отозван. Требования CA/B также позволяют центру сертификации самостоятельно отзывать сертификаты, если центр сертификации знает о возможности компрометации. Такие доказательства может предоставить любой желающий.

Статусы отзыва обычно не сохраняются и не архивируются в течение длительного времени после истечения срока действия сертификата, что затрудняет исследование и проверку поведения отзыва. Одно из предложений по решению этой проблемы включает отправку «постсертификатов» в журналы прозрачности сертификатов для каждого отзыва, что также позволит выполнять отзыв без каких-либо действий со стороны центра сертификации; альтернативное предложение, также основанное на прозрачности сертификатов, предполагает отправку CRV в журналы CT центрами сертификации.

Информирование клиентов

Соображения

Модель отказа

Если статус отзыва недоступен (что может быть безобидным или вызвано атакой), клиент сталкивается с дилеммой при оценке сертификата: он может выполнить сбой и предположить, что сертификат все еще действителен; или это может привести к сбою и предположить, что сертификат был отозван. Это компромисс между безопасностью и доступностью: Failing-Soft допускает атаки на понижение версии , а Fail-Hard допускает отказ в обслуживании (в результате атак) или вызывает недоступность.

Злоумышленник, имеющий возможность представить скомпрометированный сертификат, вероятно, также имеет возможность помешать клиенту выполнить онлайн-проверку статуса отзыва; в этом случае Failing-Soft вообще не обеспечивает никакой защиты. Браузеры выбрали эту сторону дилеммы и предпочли доступность безопасности.

Жесткий отказ может привести к возникновению новых векторов атак типа «отказ в обслуживании». Например, если клиенты ожидают сшивания OCSP, а в противном случае — жесткого отказа, отказ в обслуживании ответчиков OCSP усиливается до отказа в обслуживании всех служб, желающих использовать эти ответы OCSP.

Использование ресурсов

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

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

в 2014 году Heartbleed Во время массового отзыва Cloudflare , когда уровень отзыва вырос с 1% до 11%, по оценкам , пропускная способность , которую GlobalSign использовала для распространения CRL, могла стоить 400 000 долларов США (что эквивалентно 510 000 долларов США в 2023 году). ).

Своевременность

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

Конфиденциальность

Клиенты, выполняющие проверки на основе извлечения, могут передавать информацию о просмотре пользователя третьим лицам, а именно распространителю информации об отзыве.

Проверяемость

Желательно избегать создания доверенной третьей стороны в PKI. Если действующее лицо в схеме подлежит аудиту , то клиенты (или агенты, действующие от имени клиентов) могут доказуемо убедиться, что действующее лицо ведет себя правильно.

Возможность развертывания

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

Архитектуры

Существует три широкие архитектуры доступа клиентов к статусу отзыва: по запросу , когда клиенты получают статус отзыва во время проверки; push-based , где клиенты получают статус отзыва перед проверкой и кэшируют его; и с помощью сети , где проверка отзыва тесно интегрирована с протоколом TLS и отдельные проверки могут не потребоваться.

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

Проверка на основе push менее эффективна для использования полосы пропускания, чем проверка на основе запроса, но обеспечивает доступность и конфиденциальность. Для каждого сертификата можно использовать разные методы, что позволяет найти компромисс: и Google Chrome , и Mozilla Firefox выполняют push-проверки небольшого набора критически важных сертификатов.

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

Основная статья: Список отзыва сертификатов

Список отзыва сертификатов (CRL) перечисляет отозванные сертификаты. Они криптографически аутентифицируются выдающим центром сертификации.

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

CRL содержит информацию обо всех сертификатах, отозванных центром сертификации, а это означает, что дистрибьюторы и клиенты должны нести расходы на передачу информации, которая, вероятно, не имеет значения. Исследование 2015 года показало, что средний сертификат имел CRL размером 51 КБ, а самый большой CRL составлял 76 МБ.

OCSP

Основная статья: OCSP

Протокол онлайн-статуса сертификата (OCSP) позволяет клиентам в интерактивном режиме запрашивать сервер ( ответчик OCSP ) о статусе сертификата, получая ответ, который криптографически аутентифицирован выдающим центром сертификации. Он был разработан для решения проблем с CRL. Типичный ответ OCSP составляет менее 1 КБ.

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

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

Исследование 2018 года показало, что 1,7% запросов к ответчикам были недоступны на сетевом уровне, а еще один c. 2% предоставили непригодные для использования ответы OCSP со значительной неоднородностью между центрами сертификации и точками зрения клиентов.

Сшивание OCSP

Основная статья: Сшивание OCSP

Сшивание OCSP — это расширение TLS, обеспечивающее предоставление клиенту ответов OCSP вместе с сертификатом при инициации соединения.

Сшивание OCSP может решить эксплуатационные проблемы OCSP, а именно, дополнительные сетевые запросы, вызывающие задержки и ухудшение конфиденциальности. Однако он может быть подвержен атакам понижения версии со стороны злоумышленника на пути. RFC 7633 определяет расширение, которое встраивает требование в сертификат, который будет прикреплен к действительному ответу OCSP. Благодаря этому расширению сшивание может быть эффективным в случае, когда сертификат был скомпрометирован после надлежащего выпуска; однако, если сертификат может быть выдан неправильно без расширения, сшивание может не обеспечить никакой безопасности.

Помимо клиентов и центров сертификации, обеспечивающих сшивание и расширение must-staple, администраторы серверов также должны принимать меры для поддержки сшивания, регулярно получая ответы и затем предоставляя их клиентам во время рукопожатия. В 2018 году только Firefox поддерживал обязательное сшивание, а ни один из двух наиболее часто используемых веб-серверов ( Apache httpd и Nginx ) вообще не поддерживал сшивание OCSP.

CRLite

CRLite предоставляет статусы отзыва с помощью каскада фильтров Блума . Единственный фильтр, созданный на основе списка отозванных сертификатов, дает ложные срабатывания . При открытом домене это непреодолимая проблема для проверки отзыва. Однако, используя прозрачность сертификатов для перечисления всех сертификатов с истекшим сроком действия, можно получить исчерпывающий список ложных срабатываний. Этот список затем используется для создания второго фильтра, к которому обращаются, если сертификат соответствует первому (и, следовательно, имеет строго меньший домен); если второй фильтр не соответствует, то это действительно положительный результат и сертификат отозван; однако совпадение во втором фильтре может оказаться ложноотрицательным, что потребует использования третьего фильтра и так далее. Поскольку вселенная конечна и область определения каждого фильтра строго уменьшается на каждом шаге, эта процедура создает конечный каскад фильтров.

CRLite позволяет клиентам работать без сбоев.

Статус отзыва всех сертификатов в Web PKI в январе оценивался в 10 МБ при использовании каскада фильтров Блума с обновлениями 580 КБ в день. В марте 2018 года этот размер вырос до 18 МБ. В моделировании со 100 миллионами сертификатов, ежедневным сроком действия 1% и частотой отзыва 2% CRLite потребовалось первоначальное предоставление 3,1 МБ, а затем 408 КБ в день для обновлений.

Поскольку все клиенты получают одну и ту же информацию, CRLite не беспокоится о конфиденциальности.

CRLite еще не получил широкого распространения. Однако его можно развернуть: агрегатору требуется только получение CRL от центров сертификации, а затем предоставление каскада фильтров и его обновлений, а также его использование клиентами; никаких действий со стороны центров сертификации не требуется, как и со стороны владельцев сертификатов. Агрегатору не обязательно быть доверенной третьей стороной : каскад фильтров можно проверить, чтобы доказать, что он точно отражает входные CRL. Частные центры сертификации также требуют особого обращения в CRLite.

Давайте отменим

Let's Revoke использует битовые векторы статусов отзыва (называемые векторами отзыва сертификатов или CRV), чтобы позволить клиентам эффективно получать большое количество статусов отзыва. Центры сертификации генерируют CRV для своих собственных сертификатов, по одному CRV на дату истечения срока действия. Обслуживание CRV для центров сертификации линейно зависит от количества выданных сертификатов. Центры сертификации должны добавить новое поле — номер отзыва — к каждому выданному сертификату, что позволит идентифицировать сертификаты одного центра сертификации по кортежу даты истечения срока действия сертификата и номера отзыва; этот кортеж позволяет клиенту эффективно находить бит, указывающий статус идентифицированного сертификата в CRV. CRV могут быть сжаты; ожидается, что они будут очень хорошо сжиматься, поскольку большую часть времени большинство битов будут не установлены. Поскольку каждый CRV связан с фиксированной датой истечения срока действия, старые CRV можно эффективно удалить. Обновления CRV группируются, с отметкой времени обновления и подписью для распространения среди клиентов. Обновления могут быть в одной из трех форм, оптимальный выбор зависит от частоты отзыва, что позволяет обеспечить как эффективную нормальную работу, так и события массового отзыва.

Ожидается, что CRV будут достаточно маленькими, чтобы обеспечить возможность проверки на основе push, но более ограниченные клиенты могут по-прежнему выполнять проверки на основе извлечения, получая доступ только к избранным CRV или откладывая получение CRV до проверки сертификата. Клиент, использующий Let's Revoke с принудительной проверкой, может выполнить жесткую проверку любого сертификата с номером отзыва. Влияние на конфиденциальность и доступность Let's Revoke зависит от архитектуры: если все проверки основаны на push-уведомлениях, то не происходит утечки конфиденциальности и снижается уязвимость к отказу в обслуживании или простою; Однако если используются проверки на основе извлечения, некоторая информация о действиях пользователя теряется (в форме доступа к CRV), и CRV могут быть недоступны во время проверки.

В моделировании со 100 миллионами сертификатов, ежедневным сроком действия 1% и частотой отзыва 2%, Let's Revoke потребовалось первоначальное предоставление 2,2 МБ, а затем 114 КБ в день для обновлений.

Let's Revoke еще не получила широкого распространения. Помимо реализации клиента, центры сертификации должны вносить операционные изменения, и не предоставляет столько информации, сколько CRL или OCSP (только бит на сертификат для проверки достоверности); CRL или OCSP по-прежнему могут использоваться для дополнения Let's Revoke и предоставления дополнительной информации. Развертывание может выполняться ЦС за ЦС, при этом клиенты постепенно получают выгоду от отказоустойчивого поведения. Благодаря эффективности CRV по сравнению с CRL и ответами OCSP, центры сертификации могут быть заинтересованы в развертывании Let's Revoke.

Другие предложения

Методы получения частной информации могут смягчить проблему конфиденциальности с помощью проверок по запросу. Вместо того, чтобы клиенты выполняли проверки отзыва, промежуточный блок мог бы централизовать затраты на проверку отзыва и амортизировать их по множеству соединений; клиентам не нужно выделять хранилище для информации об отзыве. Другое предложение касалось трансляции информации об отзыве по FM-радио .

Цитируемые работы

• «Базовые требования к выпуску и управлению сертификатами, пользующимися общественным доверием» (PDF) . Форум CA/браузера . 14 декабря 2022 г.
• Брюнер, Карл Магнус; Линнарссон, Оскар; Немец, Матус; Арлитт, Мартин; Карлссон, Никлас (2022). «Смена караула: управление сертификатами и открытыми ключами в Интернете» (PDF) . Пассивное и активное измерение . Конспекты лекций по информатике. Том. 13210. стр. 50–80. дои : 10.1007/978-3-030-98785-5_3 . ISBN  978-3-030-98784-8 .
• Шуат, Лоран; Абду, Абдельрахман; Сассе, Ральф; Шпренгер, Кристоф; Басин, Дэвид; Перриг, Адриан (2020). «SoK: делегирование и отзыв, недостающие звенья в цепочке доверия в Интернете». Европейский симпозиум IEEE по безопасности и конфиденциальности 2020 года (EuroS&P) . стр. 624–638. arXiv : 1906.10775 . дои : 10.1109/EuroSP48549.2020.00046 . ISBN  978-1-7281-5087-1 . S2CID   215827701 .
• Чунг, Тэджун; Лок, Джей; Чандрасекаран, Балакришнан; Чоффнес, Дэвид; Левин, Дэйв; Мэггс, Брюс М.; Мислов, Алан; Рула, Джон; Салливан, Ник; Уилсон, Христо (2018). «Готов ли Интернет к обязательному закреплению OCSP?» (PDF) . Материалы конференции Internet Measurement Conference 2018 . стр. 105–118. дои : 10.1145/3278532.3278543 . ISBN  9781450356190 . S2CID   53223350 .
• Дурумерик, Закир; Ли, Фрэнк; Кастен, Джеймс; Аманн, Джоанна; Бикман, Джетро; Пайер, Матиас; Уивер, Николас; Адриан, Дэвид; Паксон, Верн; Бейли, Майкл; Хальдерман, Дж. Алекс (2014). «Дело сердечного кровотечения». Материалы конференции по измерениям в Интернете 2014 года . стр. 475–488. дои : 10.1145/2663716.2663755 . ISBN  9781450332132 . S2CID   142767 .
• Халлам-Бейкер, Филипп (октябрь 2015 г.). Расширение функции безопасности транспортного уровня (TLS) X.509v3 . дои : 10.17487/RFC7633 . РФК 7633 .
• Коган, Дмитрий; Корриган-Гиббс, Генри (август 2021 г.). «Частный поиск по черному списку с помощью контрольного списка» . 30-й симпозиум по безопасности USENIX (USENIX Security 21) . Ассоциация USENIX . стр. 875–892. ISBN  978-1-939133-24-3 .
• Коржицкий, Никита; Карлссон, Никлас (2021). «Статусы отзыва в Интернете». Пассивное и активное измерение . Конспекты лекций по информатике. Том. 12671. стр. 175–191. arXiv : 2102.04288 . дои : 10.1007/978-3-030-72582-2_11 . ISBN  978-3-030-72581-5 . S2CID   231846906 .
• Korzhitskii, Nikita; Nemec, Matus; Carlsson, Niklas (2022). "Postcertificates for Revocation Transparency". arXiv : 2203.02280 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
• Лариш, Джеймс; Чоффнес, Дэвид; Левин, Дэйв; Мэггс, Брюс М.; Мислов, Алан; Уилсон, Христо (2017). «CRLite: масштабируемая система для отправки всех отзывов TLS во все браузеры». Симпозиум IEEE по безопасности и конфиденциальности (SP) 2017 г. стр. 539–556. дои : 10.1109/sp.2017.17 . ISBN  978-1-5090-5533-3 . S2CID   3926509 .
• Лейбовиц, Хеми; Галваш, Хайтам; Сита, Ева; Герцберг, Амир (2021). «CTng: безопасный сертификат и прозрачность отзыва» . Архив электронной печати по криптологии .
• Лю, Ябин; Том, Уилл; Чжан, Лян; Чоффнес, Дэвид; Левин, Дэйв; Мэггс, Брюс; Мислов, Алан; Шульман, Аарон; Уилсон, Христо (2015). «Сквозное измерение отзыва сертификатов в сети PKI». Материалы конференции по интернет-измерениям 2015 года . стр. 183–196. дои : 10.1145/2815675.2815685 . ISBN  9781450338486 . S2CID   1955346 .
• Принц, Мэтью (17 апреля 2014 г.). «Скрытая цена сердечного кровотечения» . Блог Cloudflare . Облачная вспышка .
• Шеффер, Ярон; Сен-Андре, Пьер; Фоссати, Томас (ноябрь 2022 г.). Рекомендации по безопасному использованию Transport Layer Security (TLS) и Datagram Transport Layer Security (DTLS) . дои : 10.17487/RFC9325 . РФК 9325 .
• Смит, Тревор; Дикинсон, Люк; Симонс, Кент (2020). «Давайте отзовем: масштабируемый глобальный отзыв сертификатов». Труды 2020 Симпозиума по безопасности сетей и распределенных систем . дои : 10.14722/ndss.2020.24084 . ISBN  978-1-891562-61-7 . S2CID   211268930 .
• Салаховский, Павел; Шуат, Лоран; Ли, Тэхо; Перриг, Адриан (2016). «РИТМ: Отзыв посередине». 2016 36-я Международная конференция IEEE по распределенным вычислительным системам (ICDCS) . стр. 189–200. arXiv : 1604.08490 . дои : 10.1109/ICDCS.2016.91 . ISBN  978-1-5090-1483-5 . S2CID   761560 .
• Вазан, А.С.; Лаборд, Р.; Чедвик, Д.В.; Баррер, Ф.; Бензекри, А. (11 сентября 2017 г.). «Проверка TLS-соединения веб-браузерами: почему веб-браузеры до сих пор не согласны?» . 41-я ежегодная конференция IEEE по компьютерному программному обеспечению и приложениям (COMPSAC) , 2017 г. стр. 665–674. дои : 10.1109/COMPSAC.2017.240 . ISBN  9781538603673 . S2CID   28599113 .