Массовые аннулирования: Миллионы сертификатов отменены компаниями Apple, Google & GoDaddy

07.05.2019

Дебаты о DarkMatter уже имеют последствия величиной во всю индустрию.

Миллионы сертификатов SSL/TLS отозваны в результате ошибки, которая привела к созданию несовместимых серийных номеров.

Как мы узнали, что Apple, Google, GoDaddy - и, возможно, несколько других CA (Certificate authority - Центров сертификации) - неправильно выпустили миллионы сертификатов? Давайте же разберемся с этим.

Как неправильно выпустили миллион сертификатов?

Давайте начнем с технической стороны произошедшего, мы дадим краткий ее обзор.

Начнем с EJBCA, который является программным пакетом центра сертификации с открытым исходным кодом. Он может использоваться сам по себе для создания полной инфраструктуры PKI, но многие доверенные ему CA используют его в качестве криптографически безопасного генератора псевдослучайных чисел (CSPRNG) для генерации серийных номеров.

Серийные номера указаны в Базовых требованиях к форуму C /B, раздел 7.1:

“CAs должны генерировать непоследовательные серийные номера сертификатов больше нуля (0), содержащие как минимум 64 бита выходных данных из CSPRNG.”

Эти серийные номера должны быть уникальными, положительными целыми числами с 64 битами энтропии. Это требует, чтобы один из 64 битов был фиксированным значением, чтобы гарантировать, что серийный номер является положительным. К сожалению, настройки по умолчанию для EJBCA не учитывали эту информацию, а вместо этого выводили 63-битные серийные номера.

Почему это важно? Адам Каудилл прекрасно объяснил это в своем блоге:

“Когда мы говорим о таких больших числах, легко предположить, что 1 бит не будет иметь большого значения, но разница между 2 ^ 64 и 2 ^ 63 существенна - если быть точным, 2 ^ 63 отклоняется более чем на 9 квинтиллионов или, более конкретно, 9,223,372,036,854,775,808.”

Это представляет «неприемлемый риск» для всей экосистемы. Таким образом, каждый сертификат с 63-разрядным серийным номером, созданный с использованием значений по умолчанию EJBCA, теперь должен быть отозван и заменен соответствующим сертификатом.

Это само по себе большое дело и серьезное нарушение бизнеса. Но это еще не вся история, потому что то, как мы дошли до этого, более важно.

Будьте осторожны, когда вы ищете крайнего

Давайте вернемся к обсуждению DarkMatter, которое проходило на корневом форуме Mozilla. В то время как ответ на вопрос о том, должен ли Dark Matter Group иметь корневую систему, включенную в разные корневые программы - что даст ему возможность выпускать доверенные цифровые сертификаты - это кажется очевидным на первый взгляд, но это решение будет иметь очень много последствий.

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

Как писал Софос Кори Боннелл:

“Я хотел бы поддержать мое предыдущее утверждение о том, что схема генерации серийного номера, используемая в иерархии сертификатов DarkMatter, вероятно, не соответствует требованиям, изложенным в Базовых требованиях, раздел 7.1…

Подводя итог, он обвиняет DarkMatter в неправильной выдаче сертификатов с 63-битными серийными номерами и указывает это как основание для отказа в использовании корневого приложения.

В ответ Скотт Реа из DarkMatter изложил свой метод генерации серийных номеров:

“DarkMatter использует платформу EJBCA с необходимыми настройками для 64-битных случайных серийных номеров, а наш источник энтропии - HSM, сертифицированный FIPS140, поэтому я тоже был удивлен результатами, о которых вы сообщили. Однако в ходе нашего исследования этой потенциальной проблемы мы обнаружили, что платформа, кажется, соответствует требуемому стандарту, и аномалия, которую вы выделяете, потенциально обусловлена только целочисленным представлением, которое вы используете в своих вычислениях.

Это возвращает нас к тому, что мы говорили ранее о том, что один из битов должен быть фиксированным значением, чтобы убедиться, что весь серийный номер был положительным целым числом. Это  момент, когда все остальные поняли, что проблема была не в DarkMatter, а в конфигурации EJBCA по умолчанию. Тот, который также использовали многие другие CA.

Apple, Google и GoDaddy признались в неправильной выдаче сертификатов. GoDaddy первоначально сказал, что это было 1,8 миллиона сертификатов, хотя с тех пор они пересмотрели это число. Apple взял ответственность за  878 000, хотя около 300 000 из них уже истекли или были отозваны на прошлой неделе. Тем временем Google подсчитал, что он выпустил более 100 000, хотя только около 7 100 из них все еще действительны.

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

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

Какой риск это представляет?

Угроза безопасности? Нет. Риск бизнеса? Конечно. 64-битная энтропия, необходимая для серийных номеров, соответствующих BR, была требованием, которое было добавлено в 2016 году в ответ на проверку концепции подмены SSL.

Это станет вторым серьезным нарушением, с которым индустрия цифровых сертификатов столкнулась за последние полтора года, и первым из них стало недоверие к Symantec.

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

Не доверяете Google!

Этот заголовок шутливый. Но одним из других побочных эффектов всей этой ситуации являются некоторые сходства, которые он имеет с вышеупомянутым недоверием Symantec. Только в этот раз Google выпустил несколько сертификатов, которые не представляют реальной угрозы. Если вы помните, Google практически вытеснил Symantec из отрасли, обнаружив, что в 2016 году он неправильно выдал 33 тестовых сертификата. Symantec заявил, что это не проблема, поскольку они не представляют реальной угрозы. Google заявил, что это недопустимое нарушение доверия.

Очевидно, что существуют определенные различия, но на определенном уровне неправильная эмиссия является ошибочной выдачей. Но Google не обнаружил этого самостоятельно. И дело не в том, чтобы обвинять Google, а просто в очередной раз подчеркнуть субъективность многих из этих решений. CA и далее будут неправильно выпускать сертификаты, потому что такое случается буквально с каждым.

GoDaddy дает себе 30 дней, для того чтобы проработать свои отзывы, в то время как Apple и Google работают в значительно более короткие сроки.

Это тоже имеет смысл. Apple и Google выдают свои сертификаты внутри своих организаций. Они не беспокоятся о кучке разъяренных клиентов. В отличии от GoDaddy. Но предоставление 30 дней также может привести GoDaddy к еще большим проблемам с точки зрения соответствия. Базовые требования требуют своевременного отзыва всех не соответствующих сертификатов согласно разделу 4.9.1.1:

“CA ДОЛЖЕН отозвать сертификат в течение 24 часов и ДОЛЖЕН отозвать сертификат в течение 5 дней, если произойдет одно или несколько из следующих событий:…

7. CA уведомлен о том, что сертификат не был выдан в соответствии с настоящими требованиями и политикой сертификации CA или заявлением о практике сертификации; “

Очевидно, что программы не будут доверять GoDaddy.

Между тем, многие веб-сайты и организации будут пытаться заменить свои сертификаты SSL/TLS на соответствующие.



« Назад