Наследие Comodo: как доверие к сертификатам может рухнуть из-за делегированного выпуска

Кратко

• Подтверждённый публичный факт:в отчёте Comodo об инциденте сказано, что 15 марта 2011 года была скомпрометирована учётная запись регистрационного центра, через которую выпущено девять мошеннических сертификатов для семи доменов; там же сказано, что все они были немедленно отозваны после обнаружения, а мониторинг трафика OCSP-ответчиков не выявил попыток использования после отзыва. (Отчёт Comodo об инциденте)
• Реакция браузеров и платформ:Mozilla, Microsoft и другие операторы браузеров и платформ отнеслись к событию не как к внутреннему вопросу удостоверяющего центра. Mozilla выпустила обновление чёрного списка сертификатов, Microsoft опубликовала бюллетень безопасности 2524375 и обновление, поместившее девять сертификатов в хранилище недоверенных сертификатов Windows, а в последующем сообщении Mozilla описан путь через скомпрометированную учётную запись регистрационного центра. (Рекомендация Mozilla,Рекомендация Microsoft,Материал Mozilla)
• Граница ответственности:открытые данные подтверждают сбой делегированного выпуска, а не публичный вывод о компрометации корневых ключей Comodo или аппаратных модулей безопасности. Comodo заявила, что её инфраструктура УЦ и ключи HSM не были скомпрометированы. Это различие сужает техническое утверждение, но не снимает проблему ответственности: делегированная учётная запись всё равно позволила выпустить доверяемые браузерами сертификаты для доменов повышенной ценности.
• Оценка:ответственность за вторжение и попытку злоупотребления несёт злоумышленник. Comodo контролировала модель делегированного выпуска, аутентификацию реселлеров и меры после инцидента; вендоры браузеров и операционных систем контролировали экстренное объявление сертификатов недоверенными; корневые программы контролировали сохранение доверия; сервисы, полагающиеся на сертификаты, и пользователи несли последствия, которые не могли наблюдать напрямую.

Удостоверяющий центр может отказать далеко от корневого ключа

Инциденты удостоверяющих центров часто представляют как один кинематографичный взлом: злоумышленник похищает закрытый корневой ключ, подделывает весь веб, и вся система доверия сгорает. Инцидент Comodo был более обыденным и более поучительным. Comodo заявила, что её инфраструктура УЦ не была скомпрометирована и ключи в аппаратных модулях безопасности также не были скомпрометированы. Мошеннические сертификаты были выпущены через учётную запись регистрационного центра — делегированную входную дверь к платформе заказа сертификатов. (Отчёт Comodo об инциденте)

Это различие важно. Компрометация корневого ключа ставила бы вопрос о том, остаётся ли пригодным фундаментальный криптографический якорь. Компрометация делегированного выпуска ставит более жёсткий операционный вопрос: какой практической мощью УЦ наделены партнёрские учётные записи, процессы реселлеров, персонал проверки, автоматизированные системы и каналы экстренного отзыва? Если делегированная учётная запись способна привести к выпуску сертификатов для mail.google.com,www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org и login.live.com, значит, система доверия отказала не на математическом корне. Она отказала на административной периферии.

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

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

Сами имена несут в себе проблему. Сертификат для точки входа в систему — не декоративный артефакт. Это учётные данные, предъявляющие браузерам криптографическую идентичность. Если злоумышленник может соединить такой сертификат с перенаправлением трафика, манипуляцией DNS, контролем локальной сети, вмешательством в маршрутизацию, вредоносным ПО или доступом к сети на государственном уровне, пользователь может не иметь обычного способа заметить, что соединение установлено не с тем сервисом. Microsoft предупреждала, что сертификаты могут использоваться для подмены контента, фишинговых атак или атак типа «человек посередине» против пользователей браузеров. (Рекомендация Microsoft 2524375)

Корректный вывод ограничен. Открытые данные не показывают, что все девять сертификатов использовались в успешном масштабном перехвате. Comodo сообщила, что в интернете был замечен только один, а мониторинг трафика OCSP-ответчиков не выявил попыток использования после отзыва. Microsoft и Mozilla всё равно сочли событие срочным, потому что доверие к сертификатам по своей конструкции превентивно. Сертификат, способный выдать себя за крупный домен входа в систему, опасен ещё до того, как данные после инцидента докажут массовую эксплуатацию.

Публичная хронология необычно конкретна

Отчёт Comodo об инциденте даёт первый жёсткий каркас. В нём сказано, что 15 марта 2011 года регистрационный центр подвергся атаке, в результате которой была взломана одна учётная запись пользователя этого РЦ. Затем эта учётная запись была использована для мошеннического выпуска девяти сертификатов по семи доменам. Comodo заявила, что все сертификаты были отозваны немедленно после обнаружения. В том же отчёте перечислены домены и серийные номера, а сертификаты, замеченные в сети, отделены от тех, что замечены не были. (Отчёт Comodo об инциденте)

В последующем материале Mozilla связала этот сбой на уровне учётной записи с доверием браузеров. Mozilla сообщила, что партнёр — регистрационный центр Comodo — понёс внутренний взлом безопасности, и злоумышленник использовал учётную запись этого РЦ в Comodo, чтобы добиться выпуска девяти мошеннических сертификатов. Mozilla также отметила, что сертификаты отозваны, что Firefox выпустил обновления для их внесения в чёрный список и что Mozilla обсуждает дальнейшие меры с Comodo и другими УЦ. (Материал Mozilla)

Рекомендация по безопасности Mozilla Foundation Security Advisory 2011-11 кратка, но важна. 22 марта 2011 года она объявила об обновлении чёрного списка HTTPS-сертификатов с высоким уровнем воздействия, затрагивающем Firefox и SeaMonkey, и сообщила о помещении нескольких недействительных HTTPS-сертификатов в чёрный список для предотвращения злоупотреблений. Запись в Bugzilla о блокирующей работе — это публичный след реакции на стороне браузера. (MFSA 2011-11,Mozilla Bugzilla 642395)

Бюллетень безопасности Microsoft 2524375 добавил платформенный уровень. Microsoft сообщила, что Comodo уведомила её 16 марта 2011 года о том, что девять сертификатов были подписаны от имени третьей стороны без достаточной проверки её личности. Microsoft перечислила затронутые свойства, описала риски подмены, фишинга и атаки «человек посередине» и сообщила, что Comodo отозвала сертификаты и включила их в свой список отзыва сертификатов.

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

(Рекомендация Microsoft 2524375)

Этот последний пункт — ключевой. Если бы одного отзыва было достаточно, обновление операционной системы было бы менее срочным. В рекомендации Microsoft проблема изложена прямо: когда конечные точки CRL или OCSP недоступны, браузеры и приложения могут продолжать работу так, что пользователи остаются незащищёнными. Сертификаты были отозваны издателем, но программному обеспечению полагающихся сторон всё равно требовалась логика локального недоверия, чтобы устранить неопределённость. Именно в этот момент инцидент УЦ становится инцидентом браузеров, операционных систем и всей экосистемы.

Последующая деталь от 26 марта в отчёте Comodo тоже показательна. Comodo сообщила, что 26 марта обнаружила и пресекла вторжение в учётную запись пользователя-реселлера, и что новые меры контроля, введённые после инцидента 15 марта, устранили любой риск мошеннического выпуска сертификатов. Она также заявила, что считает атаку делом того же злоумышленника. Это обновление — не просто примечание на полях. Оно указывает на повторную попытку атаки на делегированный выпуск после первого взлома и ставит пост-инцидентные меры контроля под пристальное внимание. (Отчёт Comodo об инциденте)

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

Делегирование — не лазейка в ответственности

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

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

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

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

Современные базовые правила и политики корневых хранилищ говорят об этих вопросах более явно, чем экосистема 2011 года. Базовые требования CA/Browser Forum (Baseline Requirements) теперь содержат публичные требования к выпуску серверных сертификатов, проверке, отзыву и работе УЦ. Политика корневого хранилища Mozilla и материалы о правоприменении определяют условия включения удостоверяющих центров, которым доверяют продукты Mozilla, и мер воздействия на них. (Базовые требования CA/Browser Forum,Политика корневого хранилища Mozilla,Политика Mozilla по принудительным мерам к УЦ)

Эти действующие документы не следует читать задним числом как доказательство того, что конкретная мера контроля 2011 года нарушала нынешнее правило. Они значимы потому, что показывают, как экосистема научилась переводить доверие в опубликованные операционные требования. Делегирование допускается, только если УЦ остаётся ответственным за результат. УЦ не может передать на аутсорсинг социальный смысл сертификата, которому доверяет браузер. Он может передать на аутсорсинг части проверки, но корневая программа браузера и пользователь по-прежнему воспринимают сертификат как доверие УЦ.

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

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

Отзыв сработал, но не решил проблему до конца

Comodo заявила, что все девять сертификатов были отозваны немедленно после обнаружения. Это значимый факт. Отзыв — первый экстренный тормоз при неправомерном выпуске сертификата. Но инцидент показал, что отзыв — это не то же самое, что надёжная защита пользователя. Сертификат может быть отозван в УЦ, внесён в CRL и помечен OCSP как недействительный, но при этом требовать обновлений на стороне клиента, потому что реальная проверка отзыва работает неравномерно.

В рекомендации Microsoft проблема полагающихся сторон была объяснена с необычной ясностью. Проверки CRL и OCSP полезны, когда они доступны, но сетевые сбои и поведение клиентов могут оставлять пробелы. Поэтому Microsoft выпустила обновления, добавляющие мошеннические сертификаты в хранилище недоверенных сертификатов Windows. Это решение заставило платформу считать сертификаты недоверенными, даже когда обычное получение данных об отзыве не могло обеспечить защиту. (Рекомендация Microsoft 2524375)

Базовые стандарты помогают объяснить устройство. RFC 5280 определяет профиль сертификатов и CRL инфраструктуры открытых ключей X.509 в интернете, а RFC 6960 определяет OCSP как способ получения клиентами информации о статусе сертификата. Эти инструменты создают публичный словарь для выпуска и отзыва, но не гарантируют, что каждый пользователь, браузер, устройство, сеть и приложение реализует одинаковое поведение при сбое в один и тот же момент. (RFC 5280,RFC 6960)

Именно из-за этого пробела в правоприменении важны чёрные списки браузеров. Обновление Mozilla поместило недействительные HTTPS-сертификаты в чёрный список для предотвращения злоупотреблений. Чёрный список браузера — грубый инструмент, но он решителен. Он устраняет зависимость от сетевого запроса, который злоумышленник может заблокировать, перехватить или добиться его сбоя. Цена — в том, что вендоры должны выпустить, а пользователи получить обновления достаточно быстро, чтобы это имело значение. (MFSA 2011-11)

Инцидент Comodo продемонстрировал многоуровневую модель экстренного реагирования. УЦ отзывает сертификаты. Вендоры браузеров объявляют их недоверенными локально. Вендоры операционных систем объявляют их недоверенными локально. Операторы сайтов следят. Корневые программы задают вопросы о контроле УЦ. Пользователи ждут, пока заработает невидимая машинерия. Существование нескольких уровней — это сила, но также и доказательство того, что ни один уровень не был достаточен.

Этот момент должен смягчить и похвалу, и критику. Справедливо отдать должное Comodo за то, что она обнаружила, раскрыла и отозвала сертификаты достаточно быстро, так что публичные данные не показали широкого использования после отзыва. Справедливо также сказать, что немедленного отзыва было недостаточно. Инцидент потребовал, чтобы Mozilla и Microsoft обновили свои продукты, потому что защиту полагающихся сторон нельзя было полностью оставить на «живой» отзыв. Это не противоречие. Это обычная форма реагирования на инцидент с сертификатами, когда ошибочный сертификат уже оказался на свободе.

Последующая эволюция Certificate Transparency придаёт уроку ещё один аспект. RFC 6962 описывал экспериментальную схему публичного логирования сертификатов, а RFC 9162 позже специфицировал Certificate Transparency версии 2. Политика Google по Certificate Transparency для Chrome отражает идею о том, что публично зарегистрированные в журнале сертификаты легче обнаруживать и проверять. (RFC 6962,RFC 9162,Политика Chrome по Certificate Transparency)

Certificate Transparency не сделала инцидент Comodo 2011 года невозможным задним числом. Она изменила среду ответственности для последующих инцидентов, затруднив сокрытие скрытого выпуска и облегчив его обнаружение владельцам доменов, мониторингу и браузерам. Дело Comodo помогает объяснить, почему такая видимость важна. Если делегированная учётная запись может выпускать сертификаты для домена повышенной ценности, владелец домена и экосистема браузеров не должны полагаться только на частное обнаружение.

Доверие корневых хранилищ — это публичная инфраструктура, которой управляют частные программы

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

Материалы корневой программы Mozilla формулируют публичные ожидания к УЦ, которые стремятся получить доверие в продуктах Mozilla. Chromium и Apple публикуют собственные требования и политики корневых программ. Microsoft также поддерживает программу доверенных корневых сертификатов. Эти программы не идентичны, но их объединяет центральная посылка: доверие браузеров и платформ условно. (Политика корневого хранилища Mozilla,Политика корневой программы Chromium,Программа корневых сертификатов Apple,Программа доверенных корневых сертификатов Microsoft)

Условное доверие легче описать, чем обеспечить. Удаление или ограничение крупного УЦ может сломать веб-сайты, предприятия, государственные сервисы, локальные порталы, встроенные системы и старые устройства. Оставление плохо контролируемого УЦ в хранилищах доверия может подвергнуть пользователей перехвату. Поэтому корневые программы несут трудное бремя ответственности: они должны воздействовать на УЦ достаточно жёстко, чтобы защитить пользователей, но достаточно предсказуемо, чтобы веб не страдал от излишних сбоев доступности.

В 2011 году публичные материалы Mozilla показали это напряжение. Немедленная работа заключалась во внесении плохих сертификатов в чёрный список. Более широкая работа состояла в том, чтобы обсудить случившееся, спросить, требуются ли дополнительные меры, и решить, оправдывают ли контроль и реакция УЦ сохранение доверия. Это не суждение в одну строку. Оно требует доказательств по скомпрометированному пути, локализации, контролю партнёра, мониторингу, аудиту и вероятности повторения.

Инцидент Comodo не привёл к простому публичному стиранию доверия к Comodo во всём вебе. Сам этот исход показателен. Корневые программы могут терпеть инцидент, если считают, что УЦ эффективно отреагировал, локализовал сбой, улучшил контроль и предоставил достаточно доказательств. Но терпимость не следует путать с индульгенцией. Сохранение доверия — это перспективное решение о риске, а не декларация о том, что инцидент был безвреден.

Публика также узнала, что программы корневых хранилищ были частью цепочки реагирования, а не пассивными потребителями отчётов УЦ. Mozilla опубликовала бюллетень безопасности. Microsoft опубликовала бюллетень безопасности и обновление. Вендоры браузеров выпустили код. Корневые программы и вендоры сделали инцидент понятным для пользователей, у которых не было никаких отношений ни с учётной записью РЦ, ни с реселлером Comodo. Публичным лицом системы доверия были браузер и операционная система, а не продавец сертификатов.

Это создаёт полезное разделение ответственности. Comodo контролировала выпуск и отзыв. Вендоры браузеров и платформ контролировали экстренное недоверие и защиту пользователей. Корневые программы контролировали будущее доверие. Операторы сайтов контролировали мониторинг своих доменов. Ни один участник не контролировал всю систему, но несколько участников контролировали ключевые шлюзы. Когда УЦ говорит, что его собственная инфраструктура не была скомпрометирована, это может отвечать на один шлюз. Это не отвечает на все.

Sectigo унаследовала больше, чем имя бренда

Субъект этой статьи — Sectigo, потому что нынешняя компания является брендом-преемником бизнеса удостоверяющего центра Comodo. Публичные материалы Sectigo описывают ребрендинг Comodo CA и её бизнес по управлению жизненным циклом сертификатов и цифровому доверию. (Comodo CA — теперь Sectigo,О Sectigo)

Это не означает, что нынешняя Sectigo несёт ответственность за каждую операционную деталь 2011 года так же, как её нёс менеджмент Comodo в 2011 году. Корпоративная история требует точности. Инцидент 2011 года принадлежит послужному протоколу удостоверяющего центра Comodo. Ответственность Sectigo — это наследование доверия, рыночной позиции, ожиданий аудита, отношений с корневыми программами и обязанности показать, что уроки более ранних инцидентов УЦ усвоены в нынешних мерах контроля.

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

Для клиентов практический вопрос не в том, остаётся ли учётная запись РЦ 2011 года актуальной как прямой технический риск в 2026 году. Вероятно, в буквальном смысле нет. Практический вопрос в том, может ли современный УЦ показать сильный контроль над делегированным выпуском, безопасностью учётных записей, доменами повышенного риска, раскрытием инцидентов, логированием Certificate Transparency, качеством службы отзыва и коммуникацией с корневыми программами. Исторический сбой делегированного выпуска — это доказательство того, почему такой контроль важен.

Для корневых программ исторический вопрос стоит ещё острее. УЦ с большим масштабом выпуска и множеством делегированных или автоматизированных каналов должен доказывать, что способен быстро обнаруживать аномалии и предоставлять публичные отчёты об инцидентах, когда что-то идёт не так. Общая база данных УЦ (Common CA Database) существует в том числе для координации публичной информации об УЦ и их соответствии требованиям корневых программ. (CCADB) Публичная ответственность улучшается, когда отчёты об инцидентах и доказательства исправлений достаточно видимы, чтобы исследователи, клиенты и полагающиеся стороны могли оценивать закономерности, а не отдельные заявления.

Проблема наследования не уникальна для Sectigo. В экосистеме УЦ было множество инцидентов: неправомерный выпуск, слабая проверка, компрометация промежуточных сертификатов, провалы аудита и споры о раскрытии. Каждый инцидент учит одному и тому же неудобному уроку: доверие браузеров липкое, и цена недоверия к УЦ может быть высокой. Эта липкость даёт УЦ экономическую ценность, но она же повышает стандарт доказательств, когда доверие повреждено.

Домены повышенной ценности вскрывают политическую экономию злоупотреблений

Затронутые имена не были случайными. В материалах Comodo и Microsoft перечислены сертификаты для крупных коммуникационных и идентификационных узлов: Google, Yahoo, Skype, дополнений Mozilla, Microsoft Live и имени "Global Trustee". Эти цели значимы, потому что это места, где пользователь может проходить аутентификацию, загружать доверенный код или получать чувствительные сообщения.

Технический риск — это перехват типа «человек посередине». Экономический и политический риск в том, что кто-то другой может использовать систему УЦ, чтобы позаимствовать легитимность у сервиса-жертвы. Владелец домена-жертвы мог защитить свои серверы, включить HTTPS, тщательно управлять закрытыми ключами и приучить пользователей доверять значку замка. Мошеннический сертификат, выпущенный доверенным УЦ, может обойти значительную часть этой работы, если трафик перенаправлен или перехвачен на сетевом уровне.

Именно поэтому в манифесте риска появляется власть делегирования DNS. DNS и сертификаты — отдельные системы, но они сходятся в ощущении пользователя «где я?». DNS может направить пользователя на адрес. TLS-сертификаты сообщают браузеру, может ли конечная точка предъявить принятую идентичность для домена. Если подорвана любая из систем, пользователь в опасности. Если на обе системы может влиять злоумышленник или принуждающая сетевая среда, риск становится гораздо серьёзнее.

Экономика злоупотреблений неприглядна. Владелец домена мог ничего не покупать у скомпрометированного УЦ или реселлера. Ему всё равно приходится реагировать на мошеннический сертификат на своё имя. Вендоры браузеров могли не быть причиной выпуска. Им всё равно приходится выпускать обновления. Пользователи могли сделать всё правильно. Они всё равно зависят от отзыва, чёрных списков и обновлений платформ. Сторона, выигрывающая от рынка с низким трением при выпуске, — не всегда та сторона, которая несёт экстренные издержки, когда выпуск даёт сбой.

Современный мониторинг CT помогает владельцам доменов быстрее замечать несанкционированные сертификаты, но видимость — лишь часть экономики. Кто-то всё равно должен следить за журналами, сортировать оповещения, связываться с УЦ, запрашивать отзыв, уведомлять клиентов при необходимости и оценивать, не был ли перехвачен трафик. Для крупной платформы такая работа выполнима. Для небольшой организации это ещё один скрытый налог на безопасность. Инцидент УЦ с малым доменом может быть для такой организации не менее экзистенциальным, чем инцидент с крупным доменом — постыдным для экосистемы.

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

Хорошая реакция на инцидент всё равно оставила вопросы без ответа

Публичная реакция Comodo включала полезные факты: дату, взлом учётной записи РЦ, девять сертификатов, доменные имена и серийные номера, немедленный отзыв, формулировки о мониторинге OCSP, отрицание компрометации инфраструктуры УЦ и HSM, а также более позднюю заблокированную попытку. Вендоры браузеров и платформ добавили публичные рекомендации. Для 2011 года это лучший протокол, чем у многих инцидентов.

Тем не менее публичный протокол оставляет без ответа вопросы, важные для ответственности. Какой именно сбой контроля позволил использовать учётную запись РЦ? Какая аутентификация и авторизация требовались до и после 15 марта? Были ли проверки доменов повышенного риска, а если нет — почему? Какой мониторинг заметил мошеннический выпуск? Как долго сертификаты существовали до отзыва? Какие стороны были уведомлены и в каком порядке? Какие независимые аудиторские доказательства рассматривали меры контроля? Что произошло с отношениями с делегированным партнёром?

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

Заблокированная попытка 26 марта делает это особенно важным. Comodo заявила, что новые меры контроля предотвратили мошеннический выпуск во время более поздней попытки. Это сильное и полезное утверждение. Однако публика получила лишь сжатое описание этих мер. Более полный публичный пост-инцидентный протокол объяснил бы категории мер без чувствительных деталей: более строгая аутентификация реселлеров, обнаружение аномалий выпуска, одобрение доменов повышенного риска, ротация учётных данных партнёра, проверка аудитом, дополнительный мониторинг и отчётность перед корневыми программами.

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

Что инцидент изменил в разговоре о доверии

Событие Comodo приходится на более широкий период, когда веб-PKI становилась менее склонной относиться к доверию к УЦ как к невидимой фоновой сантехнике. 2011 год принёс и компрометацию DigiNotar — гораздо более серьёзный сбой УЦ, приведший к широкому недоверию. Вместе такие события подтолкнули экосистему к более строгой публичной работе с инцидентами, CT, лучшему правоприменению корневых программ и более детальным базовым требованиям.

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

Нынешний ландшафт стандартов и политик отражает этот сдвиг. Базовые требования CA/Browser Forum придают проверке доменов и отзыву более формальную публичную основу. Mozilla, Chromium, Apple и Microsoft публикуют ожидания к корневым программам. Логирование CT даёт владельцам доменов и браузерам публичный источник данных о выпущенных сертификатах. CCADB обеспечивает координацию корневых программ и публичную информацию об УЦ. Ни один из этих механизмов не идеален, но вместе они затрудняют для УЦ отношение к инциденту как только к приватной проблеме клиентского обслуживания. (Базовые требования CA/Browser Forum,CCADB,Политика Chrome по Certificate Transparency)

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

Рамка риска Дэниела Кейда (Daniel Kade) прорезает эту бумажную волокиту вопросом о том, кто контролировал переменные последствий. В случае Comodo ответ не мистический. Comodo контролировала делегированный выпуск, аутентификацию реселлеров, отзыв и публичную реакцию. Вендоры браузеров и платформ контролировали локальное недоверие и обновления. Корневые программы контролировали сохранение включения. Владельцы доменов контролировали мониторинг и коммуникацию с клиентами. Злоумышленники контролировали вредоносное действие. Пользователи не контролировали почти ничего.

Этот последний факт — причина, по которой ответственность УЦ должна быть строгой. Пользователям говорят искать HTTPS, избегать предупреждений и доверять своему браузеру. Когда система УЦ отказывает выше по цепочке, пользователи не могут проверить учётную запись реселлера, взлом РЦ, OCSP-ответчик, CRL, чёрный список или обсуждение в корневой программе. Они полагаются на институциональные меры контроля. Институциональные меры контроля заслуживают институциональной ответственности.

Лучший тест на ответственность для делегированного выпуска

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

В-третьих, УЦ должен быть способен доказать скорость и надёжность отзыва. Это значит не просто сказать, что сертификат отозван, но объяснить, как были защищены полагающиеся стороны, когда проверки отзыва не сработали или были заблокированы. Вендорам браузеров и платформ всё равно могут понадобиться обновления локального недоверия, но у УЦ должен быть готов экстренный канал связи и пакет доказательств для этих вендоров. В-четвёртых, УЦ должен уметь публиковать ограниченный отчёт об инциденте, в котором сказано, что произошло, чего не произошло, что остаётся неизвестным и какие меры контроля изменились.

В-пятых, корневые программы должны уметь объяснить, почему после инцидента уместно сохранение доверия. Это объяснение не обязано раскрывать приватные материалы аудита, но должно называть категории рассмотренных доказательств: локализацию, контроль партнёра, изменения проверки, последующий аудит, мониторинг, работу службы отзыва и прозрачность инцидента. В-шестых, владельцы доменов должны иметь практические способы следить за несанкционированным выпуском и быстро связываться с УЦ при появлении оповещений.

Инцидент Comodo показывает, почему важен каждый элемент. Злоумышленнику не нужен был корневой ключ Comodo. Достаточно было делегированной учётной записи. Отзыв не устранил необходимость действий браузеров и операционных систем. Публичные рекомендации не сняли всех вопросов о контроле партнёров. Небольшое число сертификатов не сделало инцидент малым, потому что целями были домены, критичные для идентичности, а затронутое доверие было глобальным.

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

Наиболее защитимое прочтение протокола 2011 года — ни паника, ни преуменьшение. Comodo обнаружила и отозвала мошеннические сертификаты и заявила, что её корневая инфраструктура не была скомпрометирована. Mozilla и Microsoft всё равно пришлось выпускать защитные обновления. Злоумышленник показал, что делегированный выпуск способен создавать доверяемые браузерами идентичности для крупных доменов. Экосистема усвоила, что отзыв, корневое доверие и контроль реселлеров — не отдельные темы. Это одна поверхность ответственности.

Именно поэтому этот инцидент и пятнадцать лет спустя остаётся в серии о рисках и ответственности. Видимым артефактом был сертификат. Реальным активом было доверие публики к тому, что браузер может отличить один домен от другого. Как только это доверие можно позаимствовать через скомпрометированную делегированную учётную запись, вопрос больше не в том, остался ли корневой ключ в безопасности в HSM. Вопрос в том, использовал ли каждый, кто имел практический контроль над делегированным доверием, этот контроль с дисциплиной, которой требует глобальная зависимость от него.