Резюме

  • Let's Encrypt 29 февраля 2020 года сообщила, что в её ПО удостоверяющего центра Boulder была ошибка в повторной проверке записей DNS Certification Authority Authorization для запросов сертификатов с несколькими именами. Организация заявила, что выпуск сертификатов был остановлен через несколько минут после подтверждения проблемы и возобновлён после развёртывания исправления [1].
  • CAA — это ресурсная запись DNS, позволяющая владельцу доменного имени указать, какие удостоверяющие центры имеют право выпускать сертификаты для этого домена. В RFC 8659 она рассматривается как дополнительный механизм защиты от непреднамеренного ошибочного выпуска сертификатов, а не как необязательная брендовая метка [2].
  • Вопрос подотчётности заключался не в том, поддерживает ли Let's Encrypt CAA в целом. Речь шла о том, получало ли каждое имя, входящее в повторно используемый набор проверок, требуемую свежую проверку авторизации достаточно близко к моменту выпуска, и могли ли затронутые подписчики заменить сертификаты до их отзыва [1].
  • Отдельный производственный прецедент в справочнике BTW связывает покрытие доверия к сертификатам Let's Encrypt сСубъект:internet-society; непосредственным публичным субъектом этой статьи остаются Let's Encrypt и служба Internet Security Research Group, описанная на официальной странице «О Let's Encrypt» [3].
  • Практический вывод для контроля заключается в том, что DNS-политика, ПО удостоверяющего центра, автоматизация подписчиков и публичное информирование об отзыве должны проверяться как единая цепочка. Проверяющая сторона не может заглянуть в закрытые журналы удостоверяющего центра, поэтому публичные материалы посмертного анализа и детерминированные механизмы предотвращения повторения становятся частью границы доверия.

Что произошло

Уведомление об инциденте Let's Encrypt описывало дефект, обнаруженный 29 февраля 2020 года в Boulder — ПО удостоверяющего центра, которое используется для выпуска сертификатов. Обычно Boulder проверяет записи CAA при подтверждении контроля подписчика над доменным именем. Поскольку некоторые проверки остаются пригодными для использования в течение определённого периода после первоначальной проверки, удостоверяющему центру может потребоваться повторно проверить CAA непосредственно перед выпуском сертификата.

Let's Encrypt сообщила, что применимое правило требовало проверки CAA в течение восьми часов до выпуска, если проверка была старше этого срока [1].

Режим отказа был специфичным. Когда запрос содержал несколько доменных имён, для которых требовалась повторная проверка CAA, Boulder выбирал одно доменное имя и проверял его многократно вместо проверки каждого релевантного имени. Это означало, что запрос сертификата мог пройти процедуру выпуска, хотя одно или несколько имён в запросе не получили предусмотренную свежую проверку авторизации в DNS. Let's Encrypt сообщила, что подтвердила ошибку в 03:08 UTC, остановила выпуск в 03:10 UTC, развернула исправление в 05:22 UTC, после чего снова включила выпуск [1].

Эта хронология важна, потому что подотчётность удостоверяющего центра доказывается не только заявлением о том, что код исправлен. Система также должна была определить сертификаты, которые могли быть выпущены без требуемой повторной проверки, уведомить подписчиков, обеспечить возможность замены и провести отзыв. В ветке обсуждения инцидента подписчикам затем было рекомендовано обновить и заменить затронутые сертификаты до начала отзывов. Таким образом, публичная запись включала три операционных этапа: выявление дефекта, исправление выпуска и очистку жизненного цикла сертификатов [1].

Почему CAA — это механизм DNS-контроля, а не бумажная формальность

RFC 8659 определяет ресурсную запись DNS CAA как способ для владельца доменного имени указать, какие удостоверяющие центры могут выпускать сертификаты для этого домена. Тот же стандарт говорит, что CAA даёт публичным удостоверяющим центрам дополнительный механизм снижения непреднамеренного ошибочного выпуска сертификатов [2]. На практике это делает CAA границей между состоянием DNS оператора домена и решением удостоверяющего центра о выпуске.

Для рамки риска и подотчётности Daniel Kade важна не марка сертификата, а цепочка операционных полномочий. Владелец домена публикует CAA в DNS. Рекурсивная и авторитативная DNS-инфраструктура возвращает состояние записи, которое видит удостоверяющий центр. ПО удостоверяющего центра интерпретирует это состояние в соответствии с правилами выпуска. Автоматизация подписчиков рассчитывает на то, что продление работает в масштабе. Проверяющие стороны доверяют тому, что публичный сертификат выпущен при соблюдении требуемых механизмов контроля.

Если одно из звеньев этой цепочки сжимается до размытой формулировки «проверка пройдена», граница доказательств становится слишком мягкой.

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

Справочник и границы субъекта

В текущем производственном справочнике опубликован субъектinternet-society, а отдельного текущего опубликованного субъекта для Internet Security Research Group или Let's Encrypt нет. Это не повод придумывать субъекта или менять атрибуцию инцидента. Исходным субъектом статьи являются Let's Encrypt и служба ISRG, описанная на официальной странице «О Let's Encrypt» [3]. Привязка в справочнике использует уже существующий в производстве прецедент Internet Society из предыдущей статьи Daniel Kade о доверии к сертификатам Let's Encrypt, при этом текст сохраняет ясного непосредственного субъекта и не утверждает, что Internet Society принимала инженерное решение по Boulder в 2020 году.

Это различие необходимо для точности источника. Строка справочника — это производственная поверхность связывания. Факты инцидента всё равно должны быть отнесены к организации, которая их раскрыла, и к документам стандартов, определяющим механизм контроля. Если импортёр или владелец требует прямого субъекта ISRG перед публикацией, этот кандидат должен завершиться отказом, а не быть пропущен через неправильную организацию.

Что должны показывать доказательства подотчётности

Обоснованное завершение разбора после подобного класса проблем должно отвечать как минимум на шесть вопросов.

Во-первых, какие имена в запросе требовали свежей повторной проверки CAA и почему? Ответ должен выводиться из возраста проверки, времени выпуска и альтернативных имён субъекта сертификата, а не из ручной таблицы постфактум.

Во-вторых, на какие ответы DNS опирался удостоверяющий центр? CAA — это запись DNS, поэтому граница доказательств должна включать время запросов, поведение резолвера, сохранённые авторитативные ответы и обработку ошибок тайм-аута или SERVFAIL.

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

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

В-пятых, как уведомили подписчиков и как отслеживали замену? Отзыв — лишь видимая конечная точка. Операционный риск — это промежуток между получением подписчиком уведомления, успешным продлением и тем, как старые сертификаты становятся недействительными.

В-шестых, что изменилось в мониторинге? Одноразовое исправление слабее постоянной проверки, которая сигнализирует, когда логика выпуска, количество проверок CAA и количество имён в сертификате расходятся.

Почему это важно за пределами Let's Encrypt

Крупные удостоверяющие центры работают в масштабе, при котором небольшие допущения о проверках могут быстро затронуть многих подписчиков. Автоматизация — часть модели безопасности: она снижает количество ручных ошибок и упрощает развёртывание HTTPS. Но автоматизация также означает, что неверный механизм контроля может повторяться со скоростью машины, пока его не остановят. Поэтому уровень подотчётности не может полагаться на доверие к намерениям. Он должен опираться на доказательства, показывающие, какой код выполнялся, какое состояние DNS было изучено и какие действия по жизненному циклу последовали.

Тот же урок применим к регистраторам, DNS-операторам, хостинг-провайдерам и платформам управляемых сертификатов. Если организация позволяет клиентам запрашивать сертификаты, менять DNS-записи, делегировать зоны или автоматизировать продление TLS, ей нужна запись о том, какие полномочия она использовала в момент действия. Механизм контроля, верный на момент проверки, но устаревший к моменту выпуска, не является актуальной авторизацией.

На что обращать внимание сейчас

Долгосрочный сигнал — сохраняют ли удостоверяющие центры и хостинговые платформы проверяемость поведения CAA по мере того, как продукты выпуска становятся более автоматизированными. Операторам стоит отслеживать инциденты, в которых упоминаются повторное использование проверок, запросы сертификатов с несколькими именами, сбои резолверов, экстренный отзыв, авторизация на уровне учётной записи, поведение ACME-клиентов и окна уведомления подписчиков. Каждый из этих терминов может обозначать границу, на которой механизм контроля молча считается уже выполненным.

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

Источники

  1. https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591
  2. https://www.rfc-editor.org/rfc/rfc8659
  3. https://letsencrypt.org/about/