Suicide
14.03.2019, 21:27
Проблемы (https://adamcaudill.com/2019/03/09/tls-64bit-ish-serial-numbers-mass-revocation/) с энтропией при генерации серийных номеров при помощи инструментария для удостоверяющих центров EJBCA (https://www.ejbca.org/) привели к формированию более миллиона TLS-сертификатов, подлежащих отзыву. Наибольшее количество проблемных сертификатов было выписано компаниями Apple, GoDaddy, Google, Actalis и SSL.com.
Проблема связана (https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/nnLVNfqgz7g/6I1et_O9BQAJ) с использованием при формирования серийных номеров случайного числа, включающего 63 бита энтропии, вместо 64 бит. Соответственно сложность подбора каждого числа снизилась с 264 до 263 комбинаций (разница около 9 квинтиллионов). Требования (https://cabforum.org/baseline-requirements-documents/), регламентирующие деятельность удостоверяющих центров, с сентября 2016 года предписывают применение как минимум 64-разрядных серийных номеров, поэтому все находящиеся в обиходе проблемные сертификаты подлежат отзыву и замене.
Использование 63 бит вместо 64 обусловлено тем, что при генерации серийного номера пакетом EJBCA не было учтено приведение значения к положительному целому числу. Чтобы избежать появления отрицательных значений и для соответствия требованиям (https://tools.ietf.org/html/rfc5280#section-4.1.2.2) спецификации в формируемом числе принудительно очищается старший бит, что должно учитываться при настройке пакета EJBCA, который поддерживает генерацию серийных номеров в диапазоне от 32 до 160 бит. Получение 64-битового значения без учёта описанной особенности (фактическое поведение при настройках по умолчанию отличается от ожидаемого) привело к тому, что значение одного бита оказалось изначально известным.
Снижение числа бит в серийном номере незначительно снижает стойкость сертификата к атакам (https://www.opennet.ru/opennews/art.shtml?num=19607), основанным на подборе коллизий - становится проще подобрать параметры (https://www.win.tue.nl/hashclash/rogue-ca/), на основе которых можно получить поддельный сертификат с идентичной цифровой подписью. Тем не менее стойкости 63 битовой энтропии более чем достаточно для обеспечения безопасности в современных реалиях и угроза компрометации исключена (https://twitter.com/hanno/status/1105792349572091904) даже при использовании уязвимых хэш-функций MD5 и SHA1, которые на практике не применяются и не поддерживаются браузерами с начала 2017 года.
Наибольшее число проблемных сертификатов было создано (https://bugzilla.mozilla.org/show_bug.cgi?id=1533655) компанией Apple - около 878 тысяч TLS-сертификатов, из которых время жизни ещё не истекло для 558 тысяч. Ещё около двух тысяч проблемных сертификатов было сгенерировано для S/MIME. Сертификаты генерировались с 2016 года. В 2017 году в процессе автоматизированного тестирования было выдано предупреждение о недостаточном размере серийного номера, но данное предупреждение по недосмотру оказалось не замечено.
Некоторые другие охваченные проблемой удостоверяющие центры:
Компания Actalis выдала (https://bugzilla.mozilla.org/show_bug.cgi?id=1534295) 350 тысяч проблемных сертификатов, из которых остаются активными 224 тысячи.
Компания GoDaddy изначально предположила наличие 1.8 млн проблемных сертификатов, но точный анализ показал (https://bugzilla.mozilla.org/show_bug.cgi?id=1533774), что проблема присутствовала только в 286 тысячах сертификатов, из которых 12152 остаются активными (проблемные сертификаты выписывались с 2016 года).
Компания Google с 2016 года выписала (https://bugzilla.mozilla.org/show_bug.cgi?id=1532842) около 100 тысяч проблемных сертификатов, из которых активными остаются только 7100.
Компания SSL.com сформировала (https://bugzilla.mozilla.org/show_bug.cgi?id=1534147) 6931 проблемных сертификатов.
Компания Camerfirma выдала (https://bugzilla.mozilla.org/show_bug.cgi?id=1534429) 924 проблемных сертификата, все из которых активны.
Компания QuoVadis выдала (https://bugzilla.mozilla.org/show_bug.cgi?id=1531800) 157 проблемных TSL-сертификатов и 118 сертификатов (https://bugzilla.mozilla.org/show_bug.cgi?id=1533899) S/MIME, все из которых активны;
Компания Siemens сгенерировала (https://bugzilla.mozilla.org/show_bug.cgi?id=1534535) 35 проблемных сертификатов;
Так как сертификаты должны быть отозваны в течение 5 дней (пункт 4.9.1.1 правил (https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf), регламентирующих работу удостоверяющих центров), в ближайшее время возможно появление предупреждений о проблемах с безопасным доступом к сайтам, с владельцами которых не смогли связаться удостоверяющие центры или администраторы которых не успели установить новый сертификат.
14.03.2019
http://www.opennet.ru/opennews/art.shtml?num=50310
Проблема связана (https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/nnLVNfqgz7g/6I1et_O9BQAJ) с использованием при формирования серийных номеров случайного числа, включающего 63 бита энтропии, вместо 64 бит. Соответственно сложность подбора каждого числа снизилась с 264 до 263 комбинаций (разница около 9 квинтиллионов). Требования (https://cabforum.org/baseline-requirements-documents/), регламентирующие деятельность удостоверяющих центров, с сентября 2016 года предписывают применение как минимум 64-разрядных серийных номеров, поэтому все находящиеся в обиходе проблемные сертификаты подлежат отзыву и замене.
Использование 63 бит вместо 64 обусловлено тем, что при генерации серийного номера пакетом EJBCA не было учтено приведение значения к положительному целому числу. Чтобы избежать появления отрицательных значений и для соответствия требованиям (https://tools.ietf.org/html/rfc5280#section-4.1.2.2) спецификации в формируемом числе принудительно очищается старший бит, что должно учитываться при настройке пакета EJBCA, который поддерживает генерацию серийных номеров в диапазоне от 32 до 160 бит. Получение 64-битового значения без учёта описанной особенности (фактическое поведение при настройках по умолчанию отличается от ожидаемого) привело к тому, что значение одного бита оказалось изначально известным.
Снижение числа бит в серийном номере незначительно снижает стойкость сертификата к атакам (https://www.opennet.ru/opennews/art.shtml?num=19607), основанным на подборе коллизий - становится проще подобрать параметры (https://www.win.tue.nl/hashclash/rogue-ca/), на основе которых можно получить поддельный сертификат с идентичной цифровой подписью. Тем не менее стойкости 63 битовой энтропии более чем достаточно для обеспечения безопасности в современных реалиях и угроза компрометации исключена (https://twitter.com/hanno/status/1105792349572091904) даже при использовании уязвимых хэш-функций MD5 и SHA1, которые на практике не применяются и не поддерживаются браузерами с начала 2017 года.
Наибольшее число проблемных сертификатов было создано (https://bugzilla.mozilla.org/show_bug.cgi?id=1533655) компанией Apple - около 878 тысяч TLS-сертификатов, из которых время жизни ещё не истекло для 558 тысяч. Ещё около двух тысяч проблемных сертификатов было сгенерировано для S/MIME. Сертификаты генерировались с 2016 года. В 2017 году в процессе автоматизированного тестирования было выдано предупреждение о недостаточном размере серийного номера, но данное предупреждение по недосмотру оказалось не замечено.
Некоторые другие охваченные проблемой удостоверяющие центры:
Компания Actalis выдала (https://bugzilla.mozilla.org/show_bug.cgi?id=1534295) 350 тысяч проблемных сертификатов, из которых остаются активными 224 тысячи.
Компания GoDaddy изначально предположила наличие 1.8 млн проблемных сертификатов, но точный анализ показал (https://bugzilla.mozilla.org/show_bug.cgi?id=1533774), что проблема присутствовала только в 286 тысячах сертификатов, из которых 12152 остаются активными (проблемные сертификаты выписывались с 2016 года).
Компания Google с 2016 года выписала (https://bugzilla.mozilla.org/show_bug.cgi?id=1532842) около 100 тысяч проблемных сертификатов, из которых активными остаются только 7100.
Компания SSL.com сформировала (https://bugzilla.mozilla.org/show_bug.cgi?id=1534147) 6931 проблемных сертификатов.
Компания Camerfirma выдала (https://bugzilla.mozilla.org/show_bug.cgi?id=1534429) 924 проблемных сертификата, все из которых активны.
Компания QuoVadis выдала (https://bugzilla.mozilla.org/show_bug.cgi?id=1531800) 157 проблемных TSL-сертификатов и 118 сертификатов (https://bugzilla.mozilla.org/show_bug.cgi?id=1533899) S/MIME, все из которых активны;
Компания Siemens сгенерировала (https://bugzilla.mozilla.org/show_bug.cgi?id=1534535) 35 проблемных сертификатов;
Так как сертификаты должны быть отозваны в течение 5 дней (пункт 4.9.1.1 правил (https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf), регламентирующих работу удостоверяющих центров), в ближайшее время возможно появление предупреждений о проблемах с безопасным доступом к сайтам, с владельцами которых не смогли связаться удостоверяющие центры или администраторы которых не успели установить новый сертификат.
14.03.2019
http://www.opennet.ru/opennews/art.shtml?num=50310