Идёт массовый отзыв 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 октетов.
    Требование положительного числа означает, что старший бит нельзя устанавливать. Если он установлен, то его нельзя использовать напрямую как последовательный номер сертификата.

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

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

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

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

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

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

    Комментарии 14

      0

      Самого интересного и не написали: про часть сертификатов google — да, а что с их же let's encrypt?

        +3
        LE использует 128-битные идентификаторы. По крайней мере на всех сертификатах, до которых мне удалось дотянуться, именно такие.
          0

          Спасибо.

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

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


        С этого места по подробнее, так мы используем этот несчастный старший 64 бит или нет? Если не используем в чём суть проблемы, пространство серийников всё равно будут 63-х битными…
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            ну, судя по тому, что мне GoDaddy в перевыпущенном сегодня из-за этого инцидента сертификате выставил старший байт Serial Number в 0xC8, да, используются все 64 бита, как значащие.
            Это же вопрос интерпретации данных уже…
              0
              Но этим комментарием вы снизили энтропию обратно до 63 бит :)
                +1
                Тогда уж до 56 бит.
                  0
                  Да, ошибся.
            0
              0
              Честно говоря не понял основного поинта статьи. На деле проблемы нет вообще никакой, если убрать пассажи типа «всего два раза это целых сколько-то квинтиллионов!». Так как на деле «два раза» это и есть всего в два раза.

              То есть когда-то в стандарте взяли хорошее «круглое» число 64 (так-как 32 вроде мало), но потом в реализации накосячили со снаковым битом. Что по факту практически никак не сказывается на безопасности, ну вот просто «не по стандарту» получилось.
              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  Я больше про то, что исправляется не проблема базопасности, а неточность в регламенте. Которая к непосредственно безопасности относится довольно опосредованно.
                +1
                Я один не понял, зачем использовать знаковый тип для величины, которая беззнаковая по определению? Это для какой-то совместимости с кривым софтом сделано?

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

                Самое читаемое