Проблемы (https://adamcaudill.com/2019/03/09/tls-64bit-ish-serial-numb.../) с энтропией в открытом инструментарии для удостоверяющих центрах EJBCA (https://www.ejbca.org/) привели к формированию более миллиона TLS-сертификатов, подлежащих отзыву. Наибольшее количество проблемных сертификатов было выписано компаниями Apple, GoDaddy, Google, Actalis и SSL.com.Проблема связана (https://groups.google.com/forum/#!msg/mozilla.dev.security.p...) с использованием при формирования серийных номеров для сертификатов генератора случайных чисел, выдающем 63 бита энтропии, вместо 64 бит. Соответственно сложность подбора каждого числа снизилась с 264 до 263 комбинаций (разница около 9 квинтиллионов). Требования (https://cabforum.org/baseline-requirements-documents/), регламентирующие деятельность удостоверяющих центров, предписывают применение как минимум 64-разрядных серийных номеров, поэтому все находящиеся в обиходе проблемные сертификаты подлежат отзыву и замене.
Использование 63 бит вместо 64 обусловлено тем, что при генерации серийного номера пакетом EJBCA применялось приведение значения к положительному целому числу, т.е. чтобы избежать появления отрицательных значений принудительно очищался старший бит. Таким образом значение одного бита в 64-разрядном числе оказалось изначально известным.Снижение числа бит в серийном номере незначительно снижает стойкость сертификата к атакам, основанным на подборе коллизий - становится проще подобрать параметры, на основе которых можно получить поддельный сертификат с идентичной цифровой подписью. Тем не менее стойкости 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. Сертификаты генерировались с 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 проблемных сертификата, все из которых активны.Так как сертификаты должны быть отозваны в течение нескольких дней, возможно появление предупреждений о проблемах с безопасным доступом к сайтам, с владельцами которых не смогли связаться удостоверяющие центры или администраторы которых не успели установить новый сертификат.
URL: https://adamcaudill.com/2019/03/09/tls-64bit-ish-serial-numb.../
Новость: https://www.opennet.me/opennews/art.shtml?num=50310
Читал недавно на HN, хочу подчеркнуть что проблема не в EJBCA, а в неправильной настройки и эксплуатации данного продукта:
EJBCA can be configured to generate certificate serial numbers (positive integers) from 32 to 160 bits.
> хочу подчеркнуть что проблема не в EJBCAТочно? А это о чём?
> Использование 63 бит вместо 64 обусловлено тем, что при генерации серийного номера пакетом EJBCA не было учтено приведение значения к положительному целому числу.
>> Использование 63 бит вместо 64 обусловлено тем, что при генерации серийного номера пакетом EJBCA не было учтено приведение значения к положительному целому числу.ну и дальше по тексту читайте, что вы кусок из контекста вырываете:
Чтобы избежать появления отрицательных значений и для соответствия требованиям спецификации в формируемом числе принудительно очищается старший бит, что должно учитываться при настройке пакета EJBCA, который поддерживает генерацию серийных номеров в диапазоне от 32 до 160 бит. Получение 64-битового значения без учёта описанной особенности (фактическое поведение при настройках по умолчанию отличается от ожидаемого) привело к тому, что значение одного бита оказалось изначально известным
> принудительно очищается старший бит, что должно учитываться при настройке пакета EJBCAТ.е. по Вашему, это нормально, что "принудительно очищается старший бит" при "приведении значения к положительному целому числу" и потому надо указывать в настройках 65 бит, вместо 64? Ну возможно... Но тогда эта "особенность" должна быть указана в документации.
"Документированный баг — это фича" ©
Но как же так? Ябблы всякие и прочие Google ведь деньги берут, там работают супер-пупер спецы. Это не какой-то там хипстерский Let'sEncrypt. Как так?А вот так.
"When Ballot 164 was passed, we confirmed that the CA Software was already configured for 64-bit serial numbers, but did not realize the serial number generation algorithm resulted in 63 bits of entropy.In addition to the CA Software, a validator (similar to linting tools) checks each issued certificate for compliance with SSL Baseline Requirements. Alerts were generated that the serial numbers were insufficient, however; because the checks were performed against individual certificates and not collections of certificates, the alerts were mistakenly determined to be incorrect and were suppressed."
«Мы увидели ошибку, но, такие, да наверняка же фигня, и выключили её, ибо нефиг, да и деньги от АНБ то не лишние».
Ну так они берут деньги как раз за то, что в случае подобной фигни у них есть, кому связаться с владельцем проблемного сертификата.
Обычно сертификаты от таких компаний берутся на пару лет чтобы поставить руками и на долго забыть про настройки. Связаться можно но не факт что пользователь будет быстро все менять. Не раз бывали новости что какая-то крупная компания вовремя не обновляла истекший сертификат. А тут уже не просто конкретную дату истечения помнить а следить за тем не отозван ли сертификат.С LE сертификат через пару месяцев истечет и тут можно даже ничего не отзывать при подобных проблемах так как за такое время найти коллизию скорее всего просто не успеют. И тут обычно у всех будет настроено автоматическое обновление сертификатов.
а вот так, да - приходят владельцы хипстерского лентсшиткрипт - и объявляют их сертификаты превращенными в тыкву.что расшифровать зашифрованное тем сертификатом не владея ресурсами АНБ у тебя не получится (а анб не нужно) - их не колебет, их задача - старательно уничтожать любые бизнесы, кроме своего.
АНБ всё делает правильно. ;-) Их "бизнес" живёт за счёт налогов тех, кого они душат.
Вот тебе как раз яркий пример того, что Let's Encrypt как раз не хипстерский, а очень даже нормуль.
> Наибольшее число проблемных сертификатов было создано компанией Apple - около 878 тысяч TLS-сертификатовА куда они столько выдали? Вроде не побличный ЦА типа тавте и не хостер типа амазона/клаудфларе. На каждый свой ай-телефон? Если да, то отозвать сертификаты во всех телефонах за неделю.. ? (ну и да, оно так важно, что ахтунг, за неделю!! а не "не торопясь", за пол года?)
Apple является реселлером DigiCert
Ну тогда наверное не реселеры, реселеры своего ЦА не имели бы.. ну в общем вопрос терминологии.Они конечным пользователям продают (перепродают) сертификаты или всетаки своим устройствам и своей инфраструктуре навыдавали?
> ну и да, оно так важно, что ахтунг, за неделю!!гуглю очень важно чтоб именно так, да.
определённо клиентам этих компаний стоит нанять хороших адвокатов - неплохая возможность настричь бабла. гарантия безопасности сертификатов (compromise warranty) к примеру у того-же GoDaddy - от $100,000 до $1,000,000
для этого сначала надо подделать сертификат - приступайте, приступайте.
адвокаты в любом случае настригут.
> адвокаты в любом случае настригут.с нанимателя уж точно ;-)
Адвокат никогда не проигрывает, клиент – довольно часто.
То есть, необходимое время подбора сократилось со 100500 миллиардов лет до 9000 миллиардов лет работы всех компьютеров Земли?
вы таки не понимаете - нашли "страшную и опасную уязвимость", позволяющую еще на шажок пропихнуть летсшиткрипт - гугель для этого даже пожертвовал собственными сертификатами (один хрен генеримыми и выдаваемыми автоматом)
Фигня какая то.
Ну выдали, ну меньше там немножко энтропии, но отзывать то зачем!?
Они и сами успеют просрочится раньше чем это станет проблемой.
вот именно поэтому и надо отозвать - чтобы это таки стало проблемой для пользователей "неправильных" CA."а не будут отзывать - отключим" (c)гугель
так модно щас. тут пацаны писали что ИТ динамически развивается и все такое... короче придумают гемор на ровном месте, лишь бы люди меньше времени жили реалом/отдыхали.
> Фигня какая то.
> Ну выдали, ну меньше там немножко энтропии, но отзывать то зачем!?
> Они и сами успеют просрочится раньше чем это станет проблемой.Действительно фигня.
Serial Number: Used to uniquely identify the certificate within a CA's systems.
При чём здесь вообще "надёжность"??
Он по ходу вообще должен бы последовательно меняться. Номер сертификата. Чтобы его идентифицировать по номеру. Дeбилы решили задействовать rnd? Ну тогда и правда возникает риск коллизий... Но опять-таки проблема решается пересмотром базы сертификатов и выявлением совпадений, если есть...
> ну меньше там немножко энтропии, но отзывать то зачем!?Ну как зачем - впихнуть новые дыры. А заодно отсеять тех, кто не заплатил.
Неужели вы и правда подумали, что ИХ беспокоит ВАША безопасность?
Задолбали со своими сертификатами, куда не глянь, везде напихали свое бесполезное шифрование, еще и заставляют активно переходить на него
ну да, толку-то от него. шифрование все прикрутили, а сотни миллионов учеток каждый год утекают из-за дырявях сервисов. админы этих сервисов наверное думали, что шифрование защищает от взломов :D
правильно - честному человеку нечего скрывать
аноним, выступающий против шифрования? Серьезно?
> аноним, выступающий против шифрования? Серьезно?человек, на открытом форуме на сайте размещенном в подконтрольном товарищмайору ящике, после того как предъявил свой паспорт провайдеру для оформления подключения, что-то там топит за "шифрование"? Серьезней некуда, это, скорее всего, неизлечимо.
А самое главное - железо-то всё дырявое в закладках майора,
думают они о безопасности пользователей, ага, верю.
>разница около 9 квинтиллионовНе школо 9 квинтиллионов, а ровно вдвое. То есть несущественная.
Между 18 квинтиллионами и 9 квинтиллионами разница 9 квинтиллионов :)
unsigned типы - это зло! Ну да...
>>Снижение числа битМожет, всё-таки битов? Это же не о бейсболе статья.
не припомню, чтоб где-либо звучало "битов" когда-либо
Entropy - heartless bitch.