Хабрахабр

Идёт массовый отзыв TLS-сертификатов от множества УЦ, по ошибке сгенерированных на 63-битном ГСЧ вместо 64-битного

Три дня назад в списке рассылки mozilla.dev.security.policy опубликовано сообщение о массовом нарушении в генерации TLS-сертификатов. Как показало расследование, пострадало несколько удостоверяющих центров, в том числе GoDaddy, Apple и Google. Общее количество неправильных сертификатов превышает 1 миллион, а может быть намного больше. GoDaddy первоначально назвала цифру в 1,8 млн сертификатов, а потом уменьшила оценку на два порядка, до 12 000. Представитель Apple назвал цифру 558 000 сертификатов.

Суть в том, что все пострадавцие УЦ использовали open source PKI-решение EJBCA с неправильными настройками, в результате чего для последовательных номеров сертификатов использовались случайные числа из 63-битного пространства, что нарушает требования CA/B Forum по минимальной энтропии (64 бита).

Все сертификаты должны быть отозваны. Разница между 263 и 264 превышает 9 квинтиллионов, то есть 9×1018, это очень существенное число (хотя разница всего в два раза). Но они очевидно не успевают вложиться в норматив.
Как такое получилось? У SSL.com и GoDaddy процедура займёт 30 дней, у других могут быть примерно такие же сроки, хотя по стандарту RFC5280 они обязаны отозвать некорректные сертификаты в пятидневный срок. Если ГСЧ выдаёт 64 бита энтропии и все сертификаты ровно 64 бита, то на первый взгляд всё нормально. Предварительный анализ показал, что у всех сертификатов длина соответствующего поля ровно 64 бита: ни больше, ни меньше. Но проблема в том, что согласно RFC5280:

Последовательный номер «Serial Number»

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

Представленные выше требования по уникальности предполагают, что последовательные номера могут быть длинными целыми числами. УЦ должны строго контролировать процедуру издания СЕРТ, чтобы последовательный номер никогда не был отрицательным целым числом. Следующие этому стандарту УЦ не должны использовать значения в субполе «serialNumber» длиной более 20 октетов. Пользователи СЕРТ должны быть способны обрабатывать значение в субполе «serialNumber» длиной до 20 октетов (включительно).

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

То есть фактически их ГСЧ выдаёт 63-битные числа, из-за чего и пострадало множество УЦ. Популярная PKI-система EJBCA, которую используют многие УЦ, по умолчанию генерирует 64-битные числа и для номеров сертификатов просто обнуляет старший бит.

Требование 64 бит по умолчанию для ГСЧ сформулировано не на пустом месте, а после хака 2008 года, когда кластер из 200 игровых приставок PlayStation 3 сгенерировал коллизии для хэша MD5, что позволяет создать поддельный удостоверяющий центр, которому будут доверять все браузеры и операционные системы.

В 2012 году этот трюк использовало американское кибероружие Flame, внедрившись в механизм обновлений Windows Update.

Специалисты говорят, что сейчас нет никаких шансов найти коллизии в 63 битах и как-то эксплуатировать найденную ошибку с некорректиными сертификатами. Впрочем, сейчас для генерации используется SHA256, это более современный алгоритм по сравнению с MD5, так что минимальное требование в 64 бита принято скорее в превентивных целях.

Но отзыв миллионов сертификатов — головная боль для системных администраторов множества компаний.

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

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»