Три дня назад в списке рассылки 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 бита).

Разница между 2⁶³ и 2⁶⁴ превышает 9 квинтиллионов, то есть 9?10¹⁸, это очень существенное число (хотя разница всего в два раза). Все сертификаты должны быть отозваны. У SSL.com и GoDaddy процедура займёт 30 дней, у других могут быть примерно такие же сроки, хотя по стандарту RFC5280 они обязаны отозвать некорректные сертификаты в пятидневный срок. Но они очевидно не успевают вложиться в норматив.

Как такое получилось? Предварительный анализ показал, что у всех сертификатов длина соответствующего поля ровно 64 бита: ни больше, ни меньше. Если ГСЧ выдаёт 64 бита энтропии и все сертификаты ровно 64 бита, то на первый взгляд всё нормально. Но проблема в том, что согласно RFC5280:

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

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

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

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

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

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

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

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

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

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