dxdt.blog: занимательный интернет-журнал

Напишу, пожалуй, несколько общих змечаний, касающихся компрометации ключей УЦ eMudhra.

Секретные ключи ECDSA, соответствующие нескольким промежуточным сертификатам данного УЦ, оказались угадываемыми. Буквально – их можно угадать, перебрав любым простым способом менее 255 натуральных чисел. Секретный ключ в ECDSA – это обычное натуральное число. При этом открытый ключ, соответствующий угадываемому секретному, на вид ничем не отличается от стойкого ключа. Потому что открытый ключ в ECDSA это точка на кривой (P-256, в данном случае), то есть, ещё пара натуральных чисел из определённого множества.

Однако утилиты, проверяющие нестойкие ключи, были и есть, но их, как мы видим, далеко не всегда используют (УЦ TLS из “коробочных версий” браузеров, в теории, должны использовать такие утилиты, но практика – далека от теории). Таким образом, ничего необычного в угадываемых ключах, вообще говоря, нет: ошибки, к сожалению, случаются, не следует переоценивать возможности “коробочного” TLS-окружения в вебе, как это принято делать.

Сертификаты промежуточных УЦ eMudhra с нестойкими ключами были опубликованы в прошлом году, такие сертификаты не являются секретными, а наоборот – о них УЦ должны заявлять. Но никто долгое время не замечал, что с ключами в данных сертификатах что-то не так (в том числе, и внутри УЦ никто не замечал). С одной стороны – это странно. С другой – мало кто следит за подобным, не удивляйтесь, такова реальность инфраструктуры TLS в вебе, тут уж ничего не поделать (зато есть квантовостойкие криптосистемы и хеш-деревья, да).

Угадываемый ключ означает, что можно взять открытый ключ из сертификата УЦ, найти за полсекунды секретный ключ, а потом начать самостоятельно выпускать доверенные TLS-сертификаты – то есть, сертификаты, в которые будет верить обычный браузер, в том числе, Chrome или “Яндекс.Браузер”; см. ниже про Certificate Transparency (CT). (И ещё тут всё будет работать, но за некоторыми исключениями: для ряда TLS-узлов может использоваться так называемый key pinning – то есть, привязка по ключам сервера или УЦ в цепочке, но это редкие детали.)

Если у вас есть доверенный сертификат, то можно активно перехватывать TLS-соединение: подменять практически любой HTTPS-узел, потому что дополнительной привязки ключей к именам, фактически, в вебе нет (DANE не используется, HPKP – запретили, и т.д.). Но для такого перехвата нужно контролировать канал. Расшифровать чужой, “не подменённый”, трафик доверенный сертификат не позволяет. Как только что отмечено, для особо важных узлов, типа некоторых сервисов Google, может использоваться упомянутый key pinning на уровне браузера, и тогда активная подмена сессии будет обнаружена браузером (и об этом может быть автоматически заявлено в Google, например).

В современных браузерах, в общем случае, доверие TLS-сертификату требует, чтобы в сертификате были доверенные SCT-метки, которые выдают операторы CT-логов. Метки подписаны. И подписаны они другими ключами, ключами оператора лога. Эти ключи – в другой цепочке доверия, которая никак к сертификатам УЦ не привязана. Поэтому компрометация ключа УЦ “от сертификатов” не позволяет подделать SCT-метку (для этого нужен секретный ключ лога; насколько “секретны” эти ключи – другой вопрос).

Однако в процессе выпуска сертификата можно предъявить соответствующий пресертификат оператору лога и получить доверенную SCT-метку, которую уже потом добавить в сам сертификат. Операторы логов принимают все подходящие по интервалу валидности сертификаты, выпущенные в цепочке от доверенных корней. Это доверие примерно эквивалентно доверию в браузере. Соответственно, если скомпрометирован ключ такого доверенного УЦ, то можно просто штатным образом предъявлять пресертификат с валидной подписью и получать SCT-метку (да, тут не оговорены разные возможные ограничения доступа к размещению пресертификатов, но это другая история; обычно, ограничений нет – главное, чтобы было доверие корню). Таким образом, получить SCT-метки и сделать сертификат доверенным с точки зрения браузера – возможно. Но останется отметка в CT-логе (в общем случае).

Следов сертификатов от скомпрометированных ключей eMudhra в CT-логах пока выявить не удалось. Это не означает, что сертификаты не были выпущены и использованы в приложениях, которые, в отличие от браузеров, не требуют SCT-меток при валидации. Таких приложений тоже немало: это разные утилиты для работы с вебом, почтовые системы и т.д. Кто, как и где использовал такие сертификаты, если использовал, – неизвестно. И это речь шла про TLS. Хуже всего, что есть сертификаты ключей подписи кода, и доверие там выстраивается похожим способом.

Ключи eMudhra были кросс-подписаны Sectigo. Это означает, что доверие распространялось от корней УЦ Sectigo. Кросс-подпись, в смысле доверия, зависит от ключа, а не от сертификата, так что с точки зрения компрометации – лучше не делает. Почему Sectigo не проверяли стойкость ключей, которые находятся в “их цепочке доверия”? Это тоже “большая загадка”. Но, опять же, таковы реалии инфраструктуры TLS-сертификатов в вебе.

Сертификаты скомпрометированных ключей можно и нужно отозвать. Это сделано. Проблема в том, что отзыв работает плохо, а CRL (списки отзыва) мало какие клиенты проверяют. Chrome – не проверяет. Однако в браузерах типа Chrome есть инструменты исключения доверия по отпечаткам ключей, новые отпечатки – распространяются с обновлением браузера. Именно так доверие данным ключам и было “снято” на днях. Однако тривиальный секретный ключ означает, что его, этот ключ, невозможно удержать в секрете.

Почему в браузеры (например) сразу не встроены подобные тривиальные ключи как недоверенные? Причин две. Первая – мало кто верил, что угадываемый ключ может быть использован полноценным УЦ, а каждая проверка по списку – это дополнительные такты процессора в программе, реализующей TLS-стек. Вторая причина – непонятно, на каком количестве ключей нужно остановиться: 128? 256? 2^16? И каждая итерация – довольно большие затраты вычислительного ресурса.

Вот.

Занятно, кстати, что секретные ключи скомпрометированного УЦ TLS eMudhra просто оказались угадываемыми – их значения лежали в интервале от 1 до 256:

The 8 impacted keys all used integers less than 256. (Все восемь затронутых ключей являлись целыми меньше 256.)

В УЦ, естественно, сертифицированные HSM и т.д., и т.п. Бывает. Байтовый скаляр можно угадать меньше чем за секунду, HSM “по FIPS” тут не мешает.

Недавно у меня студенты МГТУ делали курсовую работу по поиску секретных скаляров для ключей ECDSA на P-256 табличным методом: ну, что ж, вот вам очередной живой пример полезности данного метода (пусть и тривиального, с точки зрения теоретической математики).

В комментарии Beldmit прислал ссылку на описание того, что скомпрометированы ключи УЦ eMudhra, который находится в списках доверенных всех распространённых браузеров. В качестве доказательства там предъявлены подписи от этих ключей. Проблема большая: это означает, что тот, у кого есть секретные ключи, мог выпускать доверенные сертификаты для произвольных имён и выполнять атаку MITM. (Да, метки логов Certificate Transparency (SCT) – тоже можно было получать на такие сертификаты, это несложно.)

Немного пояснений к предыдущей записке, о том, что в стандартную библиотеку Go crypto/x509 “гвоздями прибили” некоторые отпечатки открытых ключей, которым библиотека теперь не доверяет напрямую, минуя все прочие проверки. Причина, как бы, в том, что у некоторого УЦ утекли ключи от доверенных промежуточных сертификатов (по ссылке от Beldmit есть важные подробности). Что тут можно сказать? Основное: это максимально странная история – типичный костыль, неожиданность постановки которого только укрепляется тем, что это сделано в Go. Далее – чуть подробнее.

Во-первых, таким способом можно заблокировать на уровне библиотеки любые ключи из TLS-сертификатов, вне зависимости не только от системных настроек, но и от программного кода, который эту библиотеку вызывает. Например, можно заблокировать ключи какого-нибудь корпоративного УЦ. Из-за того, что в библиотеку встроены отпечатки (значения хеш-функций), даже понять, что это за ключ, не зная соответствующего сертификата, очень сложно. Представьте, что обычный разработчик использует данную библиотеку в своём приложении. Теперь этот разработчик обновил среду сборки на новую версию Go, пересобрал код приложения без изменений – бах! сертификаты не валидируются. Никаких политик, ничего подобного – не менялось.

А ведь данная библиотека даже не проверяет статус сертификата (не отозван ли), о чём там прямо написано в документации и комментариях. Конечно, если бы статус проверялся, то и вопрос бы, возможно, решился. Но не проверять статус сертификата автоматически – это совершенно нормально для такой, достаточно низкоуровневой, библиотеки. Прибивать внутри конкретные ключи – не нормально совсем. Ключи, заметьте, это даже не алгоритмы – алгоритмы в библиотеках Go для TLS блокировались и раньше, ключи в таком виде – пока не прибивали, это первый случай.

Во-вторых, что касается отзыва сертификатов, статуса, который, якобы, невозможно проверить. Да, в современных браузерах есть механизмы распространения отпечатков недоверенных ключей с обновлениями. Есть CRLSet (Chrome), который равно так и работает: без штатного механизма отзыва, по отпечаткам ключей напрямую. Но в данном случае речь про среду разработки. Неужели кто-то считает, что можно моментально пересобрать все те сотни приложений, которые используют данную библиотеку? Нет, это невозможно. В конкретном браузере – единый канал распространения обновлений и отлаженный процесс. При этом иногда приложения вообще не имеют автоматического механизма обновлений. Некоторые приложения не обновляются месяцами и годами, и там нет не то что механизма “пересборки”, но даже и процесса, который позволил бы штатно и быстро что-то пересобрать и доставить новые бинарные исполняемые файлы. То есть, “костыльная” схема с прибиванием ключей заведомо не является оперативной: многие и многие скомпилированные ранее приложения как работали, так и продолжат работать.

В-третьих, если такие экстраординарные меры, – специальный релиз Go, – приняты, то считаются ли теперь все вышеупомянутые приложения, собранные на старой версии, скомпрометированными? Непонятно. Да, механизмы управления списком доверенных сертификатов есть в ОС. Но, получается, эти механизмы тут сразу признаны неработающими. Надо заметить, что работают они, действительно, очень плохо, но это не означает, что нужно теперь в неплохую библиотеку “прибивать ключи гвоздями”. Более того, очевидно, что если приложение не имеет механизма управления списком доверия, то это приложение, вполне вероятно, не имеет и возможности нормального обновления через пересборку.

Нехорошая тенденция, в общем.

В стандартной библиотеке Go crypto/x509, к сожалению, тоже начали понемногу разламывать внутреннюю логику: в свежем релизе 1.27.3 добавлена функция, которая внутри библиотеки, в ветке проверки валидности цепочки сертификатов, непосредственно признаёт невалидными сертификаты по отпечаткам некоторых открытых ключей.

Нормальных объяснений – что это за ключи, почему их нужно встроить непосредственно в библиотеку, – нет. Сказано только, что это результат компрометации УЦ. Почему это должно требовать изменения логики работы verify.go, с привязкой к конкретным ключам, не объясняется. Очень странно.

Заметьте, что данный способ отбрасывания сертификатов по отпечаткам ключей работает вне зависимости от того, какой список доверенных сертификатов вы используете: ещё раз – ключи зачем-то зашили прямо в исходный код библиотеки (distrustedSPKIHashes в коде verify.go).

Какую статистику могут собирать системы Let’s Encrypt, как крупнейшего, по количеству оконечных TLS-сертификатов, удостоверяющего центра (УЦ) в Интернете? Вроде, часть статистики очевидна – имена доменов, IP-адреса, которые вносятся в сертификаты, и т.д. Но можно “загадать” и неочевидные элементы.

Начнём, впрочем, с очевидных. Понятно, что любые имена, которые УЦ вносит в сертификаты, это предмет внутренней статистики: общее количество, количество сертификатов на имя, разбивка по дереву DNS. Тут, при разбивке, не только по доменам верхнего уровня нужно делить: куча сертификатов Let’s Encrypt выпускается для технических доменов четвёртого, пятого уровня, и даже ниже (максимум – десятый, это ограничение УЦ). Сюда же относится и срок действия выпущенного сертификата: сколько коротких, сколько – обычных, как это проецируется на имена.

Менее очевидные показатели. Прежде всего, проверка права управления ресурсом (именем). Тут напрашивается подсчёт вариантов: DNS, HTTP, ALPN и т.д. Всё с разбиением по типам сертификатов, по открытым ключам. Узлы, с которых запрашиваются ACME-проверки, обозначат IP-адреса источников ACME-запросов. В рамках проверки можно обнаружить, где размещаются проверяемые ресурсы: хостинг DNS, хостинг веб, распределение IP-адресов. Причём, можно построить соответствие адресов, на которых используется сертификат (см. ниже), с адресами, которые “засветились” в процессе проверки права управления.

Важна статистика по результатам проверки: успешно, не успешно, причины отказа. Данные по CAA-записям – какие имена, где размещены сами записи (не обязательно совпадает с DNS-DCV, потому что CAA-запись может быть выше уровнем).

И, конечно, всё с разбивкой по ACME-аккаунтам. Потому что каждый ACME-аккаунт имеет собственный набор идентификаторов (ключ, номер и т.д.).

Откуда тут вообще возьмутся IP-адреса, отличные от тех, которые, – возможно, – указаны в сертификатах? Прежде всего, ACME-клиент приходит с какого-то IP-адреса. Это можно зафиксировать и привязать к ACME-аккаунту. Когда DCV-подсистема проверяет право управления, эта подсистема осуществляет опрос DNS (во всех случаях, кроме, возможно, проверки управления конкретным IP-адресом) – IP-адреса авторитативных серверов DNS разных уровней тоже можно записывать. При проверке HTTP – запросы к веб-серверу отправляются по конкретным IP-адресам; если процесс связан с DNS-проверкой, то IP-адрес берётся из DNS, если с проверкой IP-адреса, то этот адрес указывается в заказе, отправленном по ACME. Соответственно, получаем ещё адреса, пригодные для включения в статистику. И эти адреса можно привязать к сертификатам, ключам, доменным именам.

Откуда взять IP-адреса узлов, на которых используется сертификат? Для сертификата, который выпущен для IP-адреса – очевидно: из самого сертификата. Для DNS-имён – чуть менее очевидно: заказ и получение сертификата не обязаны выполняться с тех же серверов, где сертификат будет использоваться. Однако всякий уважающий себя УЦ выполняет, при помощи специального бота, обход узлов, имена которых указаны в выпущенных сертификатах, как раз для того, чтобы вести статистику использования. Из этого процесса и возьмутся IP-адреса носителей. Если, конечно, соответствующие узлы доступны для бота.

Некоторую статистику можно было бы видеть по OCSP-респондерам, но их в Let’s Encrypt больше нет. Из действующих схем проверки статуса сертификата остаются списки отзыва (CRL). Соответственно, можно строить статистику запросов к точкам раздачи этих списков – с каких IP-адресов и какие именно CRL-файлы запрашивают. Ещё есть точки раздачи промежуточных и корневых сертификатов УЦ. Опять же, запросы к ним – дополнительный источник статистики.

В прошлом году я упоминал на страницах dxdt про “капчу” от “Яндекса” на “Хабре” и сетовал, что при обычных настройках – мне сложно зайти в свой “Хабра-аккаунт”. Чуть больше года прошло – смотрю, “капчу” от “Яндекса” убрали из формы логина, заменили на имевшийся раньше вариант, но со зверятами. Оно, конечно, скорее всего, связано с тем, что “Яндекс-капча” просто перестала работать почти для всех (это предположение, не проверял), но всё же.

Как известно, буква S в аббревиатуре IoT означает Security (бзеопасность). Свежая публикация от Anthropic (компания из области AI/LLM, Claude) рассказывает о том, что “ИИ/LLM” смогут “самореплицироваться” и распространяться по IoT-системам. То есть, рассказывают, что вот теперь LLM будут свои наборы коэффициентов загружать на устройства типа “умных” пылесосов. Буквально, основная идея большой публикации по ссылке выше (с картинками!) в том, что, мол, LLM-агент взломает управляющую систему пылесоса, – или, может, даже холодильника, – перенесёт туда гигабайты своих коэффициентов, и запустит “инференс” на этом вновь захваченном устройстве, чтобы взламывать следующее. И это вызывает воспоминания о полиморфных вирусах для ПК под MS-DOS, появившихся в начале 90-х годов прошлого века, более тридцати лет назад.

Полиморфные вирусы “запаковывали” и зашифровывали основную свою программу, а распаковщик – генерировали разный, по шаблону, обычно. То есть, на новой системе у запакованного вируса не было статических сигнатур, за которые могла бы зацепиться антивирусная программа, осуществлявшая поиск. Ещё раз: после того, как вирус выбирал путь распространения на новую систему (через исполняемый файл-носитель, обычно), этот вирус генерировал собственный распаковщик, прикреплял к нему зашифрованное тело вируса, и записывал этот код на носитель, для распространения дальше. На новой системе вирус распаковывался, исследовал окружение, закреплялся в системе разными способами (их было где-то с десяток, некоторые – довольно изящные), и начинал собственное распространение.

“Полиморфность” – только одна из особенностей. Продвинутые компьютерные вирусы уже тридцать лет назад имели довольно сложную встроенную логику, позволявшую обнаруживать другие вирусы и блокировать конкурентов, обнаруживать и отключать/блокировать антивирусы, выбирать способ закрепления в системе согласно имеющейся конфигурации и т.д., и т.п. Были вирусы, которые могли переходить между разными типами систем. И никаких многогигабайтных LLM для этого не требовалось. Требовалось хорошее знание ассемблера и аппаратуры от разработчика (что и сейчас не помешает).

Естественно, в новости про саморасползающиеся через захват пылесосов LLM указано важное отличие: якобы, такой LLM-агент сможет атаковывать и заражать аппаратные архитектуры, с которыми раньше не сталкивался (но в качестве примера приводят Android почему-то). Не ясно, только, откуда же такой агент возьмёт описание этой новой аппаратной архитектуры и как сможет определить, что за архитектура в очередном пылесосе используется. Мог ли древний компьютерный вирус, разработанный под MS-DOS на x86 заразить SPARCstation под SunOS? Почему нет? Тут даже не нужен полноценный кросс-ассемблер – достаточно одного из аспектов реализации “полиморфности”: этот аспект сможет переводить машинный код с одной платформы на другую. Такие решения даже существовали, но, понятно, массовыми они быть не могли по другим причинам.

Почему-то свежую (относительно) уязвимость в ядре FreeBSD (CVE-2026-101302), которая требует TLS 1.3 и находится в функциях KTLS (то есть, “выгрузки” обработки TLS-данных на сторону ядра), во внешних описаниях регулярно называют “сетевой уязвимостью”, просто позволяющей “обвалить ядро FreeBSD при помощи специального сетевого пакета, отправленного по TCP”. Это не совсем верно, и тут требуется небольшое поясение. Как сейчас модно говорить: “важен контекст”. И здесь “контекст” – в самом техническом смысле, а именно – TLS-контекст в ядре.

Данная уязвимость касается обработки именно TLS-записей в версии TLS 1.3, да ещё и после аутентификации и расшифрования полезной нагрузки. Другими словами, чтобы “проэксплуатировать” ветку кода с ошибкой (а там некорректная расчётная длина дополнения), атакующему требуется установленный в ядре TLS-контекст соединения и общие с атакуемым TLS-стеком секретные ключи. То есть, успешная атака требует, чтобы прошла аутентификация принятой TLS-записи. В TLS 1.3 здесь сначала проверяется целостность, а только потом данные расшифровываются.

Таким образом, штатная схема подразумевает, что стороны установили соединение и получили общий секрет, а потом можно отправлять “панические пакеты”. Просто так “налить панических пакетов” – не получится. Но это штатная схема. Естественно, для успешной атаки требуется подходящий TLS-контекст в атакуемом ядре, а не сам процесс установления соединения. Это понятно, забывать про это нельзя тоже. Да, подходящий TLS-контекст в ядре может быть установлен со стороны приложения без фактического выполнения полноценного TLS-соединения и отправки пакетов вообще, и вот тогда, да, специальный пакет с подходящей TLS-записью уже вызовет “панику” ядра. Что, конечно, тоже немало.

Давно и неоднократно писал о том, что при спуфинге спутникового навигационного сигнала может, – отчасти, – помочь аутентификация сигнала. И вот, как пишут, такую систему аутентификации постепенно внедряют в гражданский сигнал GNSS Galileo. Возможно, что уже в ближайшие год-два заработает.

Строго говоря, базовая аутентификация там уже есть (называется OSNMA), но она не позволяет проверить сам подлежащий навигационный код. И вот именно эту дополнительную проверку обещают ввести. Вообще, смысл затеи базируется на двух элементах: первый элемент – нужно дать приёмнику криптографический механизм проверки подлинности принимаемого опорного сигнала; второй элемент – нужно, чтобы этот механизм охватывал и содержательную часть, то есть, сам код, по которому вычисляется разность времени (или расстояние до спутника, что то же самое). Реализация второго элемента добавляет сложности.

Естественно, если навигационный сигнал подписан, а приёмник может проверить подписи и аутентифицировать принятый код, это вовсе не означает, что подписано (аутентифицировано) и вычисленное положение приёмника. То есть, даже при наличии принимаемого подлинного сигнала, нет полной гарантии, что этот сигнал соответствует положению приёмника. Но криптографическая защита тут очень сильно увеличивает устойчивость: например, появляется более строгая привязка ко времени, которая может позволить отличить ретранслируемый сигнал, исходник которого записан в другой точке координатного пространства. Так как предсказать защищённый сигнал, не зная секретных ключей, практически невозможно, то спуфинговая система должна где-то записывать реальный, подлинный сигнал и ретранслировать его.

В идеале, конечно, удостоверяться должны сами координаты, вычисленные “на приёмнике”, но для этого, к сожалению, протребуется активная система с двухсторонней связью. То есть, вычисленные координаты нужно передавать обратно на проверяющий спутник, который сможет подтвердить их верность. Такое возможно в системах типа Starlink.

Ну и понятно, конечно, что ни определение подлинности источника, ни определение подлинности сигнала вычисленных координат, не добавляют какой-то волшебной устойчивости в случае, если сигнал просто не принимается. Но вот понять, что принимаемый сигнал – подлинный, а не “подспуфлен” с опережением, – приёмник сможет.

Кстати, что касается выгруженной OpenAI огромной пачки (больше 700 статей!) сгенерированных ИИ/LLM “решений важных математических задач”, которую уже называют “математическим” “помойкалипсисом” (Slopocalypse). В. И. Арнольд в статье “Что такое математика”, – которая выходила в виде книги, например, в 2002 году, – в подразделе, который называется “Математическое мракобесие против Абеля и Пуанкаре”, пересказывает определение математики “по Ю. И. Манину” (и Арнольд, и Манин – среди крупнейших математиков 20-го века). Пара цитат из статьи Арнольда:

“Математика, согласно Манину, – это отрасль лингвистики или филологии, занимающаяся преобразованием конечных цепочек символов некоторого конечного алфавита в другие такие цепочки при помощи конечного числа “грамматических” правил. Отличие от естественных языков, вроде китайского, английского или русского, состоит лишь в том, что в грамматике этого специального языка есть отсутствующие в живых языках правила (например, набор символов “1+2” можно заменить на символ “3”).”

“[…]ведь если в результате игры с символами и получается что-либо полезное, то это просто означает, что оно содержалось уже в исходных предпосылках”.

Дальше там речь про искусство “претендовать на открытия, которых не совершал” и т.д. Понятно, в этом есть существенная доля специального юмора и сарказма. И, понятно, в той статье и речи не идёт про ИИ-генерирование. Но всё же – удивительно, как хорошо подходит к текущей ситуации, заведённой OpenAI. Многие надеялись использовать новый мощный инструмент для того, чтобы с его помощью выпускать пачки собственных статей. Но сейчас всё выглядит так, что беспилотный бульдозер OpenAI запустили в самостоятельное приключение, и вот он уже едет сносить домики в университетских кампусах.