Одна индийская компания, выдающая сертификаты, сгенерировала восемь приватных ключей. Значение одного из них было равно 4.
В прошлую пятницу в 20:06 исследователь по имени Уэйн сообщил об этом Firefox и Chrome. Уже в 21:48 сотрудники Mozilla самостоятельно вычислили все восемь ключей. Они даже не спросили, каким способом воспользовалась другая сторона. В 22:59 список отзыва попал в Firefox с настройками по умолчанию. Меньше чем за три часа.
Это должны были быть приватные ключи для кривой P-384 с пространством поиска, эквивалентным 116-значному десятичному числу.
На деле значения ключей составляли 4, 56 и 115, а самое большое — всего 237. Все они меньше 256. Исследователь Скотт Хелм сообщил, что извлёк все восемь из открытых сертификатов меньше чем за секунду. Извлёк. Вот так быстро.
Многие думают, что если с сертификатами что-то не так, значит, систему взломали. Но в этот раз этого не произошло. В серверную никто не проникал, данные не пропали, физические и логические средства контроля остались в полном порядке — так говорилось в уведомлении eMudhra для Бомбейской фондовой биржи и Национальной фондовой биржи Индии. Так почему же ключ оказался слабым? Из-за ошибки в скрипте генерации. Во время церемонии генерации ключей 30 апреля прошлого года — всё прошло строго по процедуре, предусмотренной для аппаратного модуля уровня 3 по FIPS 140-2, без единого пропущенного шага, — на этапе wrap и unwrap создали дополнительный комплект слабых ключей. А метки у них выглядели точно так же. Позже при создании запроса на подпись взяли не тот комплект и отправили слабые ключи.
Компания прошла два аудита подряд и к середине 2025 года попала в списки доверенных поставщиков браузеров. И всё же за восемнадцать месяцев никто ничего не заметил. Аудит проверял, выполнили ли процедуры по документации, но не проверял, достаточно ли случайными были ключи.
Проблема заложена и в самой структуре цепочки доверия. Сертификаты, подписанные промежуточным центром сертификации, принимаются всеми нижестоящими участниками. Из восьми промежуточных ключей шесть использовались для TLS, ещё два — для подписи кода. Яш Кадакия из Security Brigade оценивает, что перевыпустить придётся около 30 тысяч действующих сертификатов. Он также отмечает: в глобальной цепочке доверия интернета одна ошибка компании может потянуть за собой организации, которые никогда с ней не взаимодействовали.
Скорость реакции четырёх браузеров заслуживает внимания. Chrome и Firefox заблокировали сертификаты в тот же день, 17-го числа. Apple — 19-го, Microsoft — 20-го. Cloudflare сообщили об инциденте 19-го, а 20-го опубликовали отчёт. Google заблокировал хэши открытых ключей, поэтому заодно оказались заблокированы и кросс-подписанные сертификаты, созданные с теми же ключами. Даже перезапуск не понадобился. Здесь всё сделали чётко.
Но за пределами браузеров проблема никуда не делась. Сервисы на Go, программы на Python, использующие certifi, webpki-roots в Rust, множество Android-приложений со встроенными хранилищами сертификатов, старые Java-системы в серверных, корпоративные шлюзы, камеры и маршрутизаторы — их списки доверия совершенно не совпадают со списком Chrome. Браузеры исправили всё за три часа, а этим устройствам остаётся ждать обновления собственной версии. Как быстро появится исправление, зависит от того, как часто обновляют конкретное устройство, и почти не связано с масштабом инцидента. Знаете, как часто обновляется ваш домашний маршрутизатор? Никто этого не подсчитывал, и точного ответа до сих пор нет.
Деннис Джексон из Mozilla опубликовал тестовую страницу, которая проверяет, доверяет ли клиент этим сертификатам. Это займёт несколько десятков секунд. Проверьте сами.
А вот над чем действительно стоит задуматься. Вся система HTTPS по сути держится на списке: я даю тебе перечень компаний, которым доверяю, а всем остальным — нет. Когда что-то идёт не так, самое решительное действие — вычеркнуть компанию из списка. И вычеркнуть её действительно можно. Список находится в руках браузеров, а вовсе не компании, у которой случился инцидент.
В блокчейне всё наоборот. В биткоине нет компании, чьей подписи достаточно, чтобы все поверили. Каждый узел самостоятельно проверяет всю историю, начиная с первой транзакции. Медленно. Неуклюже. Энергозатратно. Зато при сбое не нужно ждать, пока четыре браузера по очереди опубликуют списки. Цена за это тоже реальна: в блокчейне попросту нельзя ничего отозвать — если что-то отправлено ошибочно, оно навсегда останется в реестре.
Мультиподписи кроссчейн-мостов, данные о ценах от оракулов, доказательства резервов стейблкоинов — всё это работает точно так же, как промежуточный центр сертификации. Подписал вышестоящий участник — нижестоящие поверили. Если там произойдёт сбой, по форме он будет мало отличаться от нынешнего.
Разница лишь в том, можно ли после происшествия пересчитать всё заново. В цепочке сертификатов остаётся только ждать обновления списка. В цепочке блоков можно заново проверить каждую транзакцию.
На практике стоит сделать две вещи. Просмотрите службы, которыми пользуетесь постоянно, и проверьте, не держится ли какая-нибудь из них на старом сертификате. А ещё загляните в кошелёк и на биржу: посмотрите, кто указан в белом списке адресов для вывода средств и не управляют ли тремя участниками мультиподписи из одного офиса, через один облачный сервис или с одного номера телефона. Если два из этих трёх совпадают, от оставшегося уровня безопасности остаётся только название.
$BTC $ETH $LINK
#比特币 #以太坊 #网络安全 #Цепочка сертификатов
В прошлую пятницу в 20:06 исследователь по имени Уэйн сообщил об этом Firefox и Chrome. Уже в 21:48 сотрудники Mozilla самостоятельно вычислили все восемь ключей. Они даже не спросили, каким способом воспользовалась другая сторона. В 22:59 список отзыва попал в Firefox с настройками по умолчанию. Меньше чем за три часа.
Это должны были быть приватные ключи для кривой P-384 с пространством поиска, эквивалентным 116-значному десятичному числу.
На деле значения ключей составляли 4, 56 и 115, а самое большое — всего 237. Все они меньше 256. Исследователь Скотт Хелм сообщил, что извлёк все восемь из открытых сертификатов меньше чем за секунду. Извлёк. Вот так быстро.
Многие думают, что если с сертификатами что-то не так, значит, систему взломали. Но в этот раз этого не произошло. В серверную никто не проникал, данные не пропали, физические и логические средства контроля остались в полном порядке — так говорилось в уведомлении eMudhra для Бомбейской фондовой биржи и Национальной фондовой биржи Индии. Так почему же ключ оказался слабым? Из-за ошибки в скрипте генерации. Во время церемонии генерации ключей 30 апреля прошлого года — всё прошло строго по процедуре, предусмотренной для аппаратного модуля уровня 3 по FIPS 140-2, без единого пропущенного шага, — на этапе wrap и unwrap создали дополнительный комплект слабых ключей. А метки у них выглядели точно так же. Позже при создании запроса на подпись взяли не тот комплект и отправили слабые ключи.
Компания прошла два аудита подряд и к середине 2025 года попала в списки доверенных поставщиков браузеров. И всё же за восемнадцать месяцев никто ничего не заметил. Аудит проверял, выполнили ли процедуры по документации, но не проверял, достаточно ли случайными были ключи.
Проблема заложена и в самой структуре цепочки доверия. Сертификаты, подписанные промежуточным центром сертификации, принимаются всеми нижестоящими участниками. Из восьми промежуточных ключей шесть использовались для TLS, ещё два — для подписи кода. Яш Кадакия из Security Brigade оценивает, что перевыпустить придётся около 30 тысяч действующих сертификатов. Он также отмечает: в глобальной цепочке доверия интернета одна ошибка компании может потянуть за собой организации, которые никогда с ней не взаимодействовали.
Скорость реакции четырёх браузеров заслуживает внимания. Chrome и Firefox заблокировали сертификаты в тот же день, 17-го числа. Apple — 19-го, Microsoft — 20-го. Cloudflare сообщили об инциденте 19-го, а 20-го опубликовали отчёт. Google заблокировал хэши открытых ключей, поэтому заодно оказались заблокированы и кросс-подписанные сертификаты, созданные с теми же ключами. Даже перезапуск не понадобился. Здесь всё сделали чётко.
Но за пределами браузеров проблема никуда не делась. Сервисы на Go, программы на Python, использующие certifi, webpki-roots в Rust, множество Android-приложений со встроенными хранилищами сертификатов, старые Java-системы в серверных, корпоративные шлюзы, камеры и маршрутизаторы — их списки доверия совершенно не совпадают со списком Chrome. Браузеры исправили всё за три часа, а этим устройствам остаётся ждать обновления собственной версии. Как быстро появится исправление, зависит от того, как часто обновляют конкретное устройство, и почти не связано с масштабом инцидента. Знаете, как часто обновляется ваш домашний маршрутизатор? Никто этого не подсчитывал, и точного ответа до сих пор нет.
Деннис Джексон из Mozilla опубликовал тестовую страницу, которая проверяет, доверяет ли клиент этим сертификатам. Это займёт несколько десятков секунд. Проверьте сами.
А вот над чем действительно стоит задуматься. Вся система HTTPS по сути держится на списке: я даю тебе перечень компаний, которым доверяю, а всем остальным — нет. Когда что-то идёт не так, самое решительное действие — вычеркнуть компанию из списка. И вычеркнуть её действительно можно. Список находится в руках браузеров, а вовсе не компании, у которой случился инцидент.
В блокчейне всё наоборот. В биткоине нет компании, чьей подписи достаточно, чтобы все поверили. Каждый узел самостоятельно проверяет всю историю, начиная с первой транзакции. Медленно. Неуклюже. Энергозатратно. Зато при сбое не нужно ждать, пока четыре браузера по очереди опубликуют списки. Цена за это тоже реальна: в блокчейне попросту нельзя ничего отозвать — если что-то отправлено ошибочно, оно навсегда останется в реестре.
Мультиподписи кроссчейн-мостов, данные о ценах от оракулов, доказательства резервов стейблкоинов — всё это работает точно так же, как промежуточный центр сертификации. Подписал вышестоящий участник — нижестоящие поверили. Если там произойдёт сбой, по форме он будет мало отличаться от нынешнего.
Разница лишь в том, можно ли после происшествия пересчитать всё заново. В цепочке сертификатов остаётся только ждать обновления списка. В цепочке блоков можно заново проверить каждую транзакцию.
На практике стоит сделать две вещи. Просмотрите службы, которыми пользуетесь постоянно, и проверьте, не держится ли какая-нибудь из них на старом сертификате. А ещё загляните в кошелёк и на биржу: посмотрите, кто указан в белом списке адресов для вывода средств и не управляют ли тремя участниками мультиподписи из одного офиса, через один облачный сервис или с одного номера телефона. Если два из этих трёх совпадают, от оставшегося уровня безопасности остаётся только название.
$BTC $ETH $LINK
#比特币 #以太坊 #网络安全 #Цепочка сертификатов