Перейти к содержимому
Новость

Секретный ключ оказался числом 4: браузеры срочно закрывают дыру в HTTPS

У индийского центра сертификации eMudhra обнаружили восемь криптографических ключей, которые можно восстановить практически мгновенно. Один из них вообще состоял из числа 4. Ошибка потенциально позволяла создавать поддельные HTTPS-сертификаты для чужих сайтов, поэтому Google, Mozilla и другие разработчики экстренно начали блокировать опасные сертификаты.

Александр Фомин
Секретный ключ оказался числом 4: браузеры срочно закрывают дыру в HTTPS

Автор: ITHome

Проблема возникла еще 30 апреля 2025 года, когда eMudhra создавала ключи для промежуточных центров сертификации. Вместо случайных 384-битных чисел восемь закрытых ключей получили значения 4, 56, 66, 115, 155, 156, 230 и 237.

Для понимания масштаба ошибки: нормальный ключ P-384 выбирается из огромного количества возможных значений. Здесь же все варианты помещались в диапазоне от 1 до 255. Исследователи смогли восстановить ключи по открытым сертификатам менее чем за секунду.

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

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

О проблеме сообщили 17 октября. Google заблокировала опасные ключи в Chrome через CRLSet уже в 19:45 UTC. Firefox получил аналогичную защиту через OneCRL к 22:59 UTC. Для большинства пользователей обновление сработало автоматически, без перезапуска браузера.

20 октября Mozilla дополнительно выпустила Firefox 158.0.1 и обновления веток ESR для пользователей с нестандартными настройками. Из доверенного хранилища NSS также удаляется корневой сертификат, связанный с проблемными промежуточными центрами.

При этом не все восемь сертификатов использовались для HTTPS. Шесть предназначались для TLS, еще два были связаны с подписью программного кода. Google отдельно уточнила, что последние не могли применяться для выдачи доверенных HTTPS-сертификатов в Chrome.

Сама eMudhra утверждает, что семь из восьми проблемных промежуточных сертификатов не использовались в рабочей среде, а ни один из них не выпускал конечные сертификаты. Компания продолжает расследование. Публичных подтверждений использования этих ключей в реальных атаках пока нет.

Но устранение проблемы в браузерах не означает, что вся остальная программная среда уже защищена. Отдельные приложения используют собственные наборы доверенных сертификатов, которые не получают обновления Chrome или Firefox. Поэтому исправления потребовались также инструментам и библиотекам Go, Python и Rust.

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

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

Источник: Ithome
3 показов