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

Удивительно, что во многих проектах, оказывается, TLS с сертификатами “из коробки” используется для подтверждения не только источника, но и подлинности важных данных (например, кода обновления и т.д.). То есть, если узел-источник аутентифицирован в рамках коробочного TLS, относительно внешних УЦ, то и все данные, полученные с этого узла, подлинные – потому что источник, как бы, подлинный. Cейчас этот момент, – “неожиданно!”, – обсуждается. Естественно, в свете истории с тривальными ключами удостоверяющего центра (УЦ) eMudhra, которые, несмотря на свою тривиальность, упешно и без вопросов были включены во все распространённые программы доверия CA/B-форума, в том числе, в браузеры от Google и Mozilla (к большому сожалению), где и находились больше года.

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

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

Действительно, даже в начале моего собственного описания TLS написано, буквально, следующее:

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

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

Посудите сами. Во-первых, инфраструктура TLS-сертификатов находится за рамками TLS и имеет мало отношения именно к спецификации клиент-серверного TLS-соединения. Во-вторых, типичный “коробочный” процесс аутентификации узла использует некоторый внешний набор доверенных ключей. Обычно, этот набор является внешним даже для TLS-библиотеки! Аутентификация в TLS, на фундаментальном уровне, возможна только в отношении открытых ключей, а никак не IP-соединения. Соответственно, нужно понимать, что когда аутентификация выполняется библиотекой без должного внимания (без сравнения отпечатков), успех этой аутентификации означает не то, что “узел подлинный”, а, – внимание!, – то, что некоторый внешний игрок (УЦ) говорит, что узел с данным ключом и под данным именем контролирует тот же, кто подавал заявку на соответствующий сертификат. Это совсем другое! Почувствуйте, как говорится, разницу. Кому тут верит клиент? Конечно – УЦ, а не оконечному узлу.

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

Почему вообще возникает проблема? Потому что открытая схема использования TLS, – например, в вебе, для HTTPS, – предполагает, что клиент не может заранее узнать значения ключей. Это совершенно верное, логичное допущение. В нём и смысл – нужно сделать так, чтобы доверие можно было распространять на новые ключи ранее неизвестных узлов, автоматически. TLS это позволяет реализовать. Но нужно создать общий список доверенных ключей третьей стороны. Отсюда возникает инфраструктура УЦ.

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

Смотрел код библиотеки Go crypto/x509 на предмет того, как там разбираются конкретные поля сертификата. Сразу наткнулся в parser.go на опечатку в стиле copy-paste: текст ошибки при некорректном Subject взят из блока, где так же обрабатывается Issuer; соответственно, текст сообщения об ошибке вводит в заблуждение – при некорректном поле Subject будет выведено, что “x509: malformed issuer”, а должно быть: “x509: malformed subject”.

Ну, думаю, исправление одной строчки – отправлю коммит через социальную сеть GitHub, потому что у меня там есть аккаунт всё равно (что поделать). Внёс исправление, подготовил pull request (черновик). Однако в черновик pull request (PR) сразу бот от Go написал, что, мол, для рассмотрения PR мне нужно какую-то дополнительную лицензию Google CLA подтвердить (забавно, да – уже для рассмотрения). Закрыл PR тут же. Может, кто ещё исправит.

Немного элементарных математических подробностей о “коротких ключах” УЦ eMudhra. Секретный ключ в ECDSA – это натуральное число в некотором заранее известном интервале, от 2 до N. Арифметика там довольно простая. Обозначим ключ d. Этот ключ d на техническом языке называют “секретным скаляром”, но, вообще говоря, от этого он не перестаёт быть натуральным числом (натуральные числа, если кто вдруг забыл, это “обычный” счёт: 1, 2, 3, 4, 5 и так “до самого большого числа”).

Открытый ключ в ECDSA получается из секретного умножением точки-генератора G на секретный скаляр; на техническом языке: [d]G. Точка-генератор – это точка, принадлежащая эллиптической кривой, используемой в данном наборе параметров криптосистемы. Умножение здесь вводится как повторное сложение: [2]G = G + G. Задача вычисления d по известной точке [d]G в произвольной группе точек кривой считается вычислительно сложной.

Минимальное значение 2 – оно очевидно из соображений умножения; понятно, 2 – это угадываемое число (см. важные детали ниже). Максимальное значение N – про него обычно пишут, что это “порядок группы точек”. Это, опять же, технический термин, который обозначает количество точек, потенциально доступных при операциях данной криптосистемы. Математически, эта самая группа точек так устроена, что всё её элементы образуются сложением генератора G с самим собой (сложение здесь – обозначение групповой операции; на техническом языке такая группа называется “циклической”). Это всё может показаться сложным, из-за терминов, но на практике это просто закольцованная цепочка значений (точек): складываете один элемент с самим собой – идёте последовательно по другим элементам, которые получаются в результате; на определённом шаге – процесс зацикливается, попадаете “в начало”, в нейтральный элемент (следом за которым будет опять генератор G, потому что G = G + 0). На практике нельзя брать именно порядок группы M в качестве максимального значения, берут, например, M-2, но это технические детали.

Точек кривой в практических криптосистемах ECDSA очень много. Их количество близко к разрядности записи, то есть, например, около 2^256. Очень много. Это определяющий момент: если бы точек было мало, то их можно было бы перебрать за обозримое время все, определив секретный скаляр. Да, практически так же, как в рассматриваемом случае нестойких ключей, но только универсальным образом.

Опять же, в упомянутом случае – набор точек называется P-384 (обычно говорят, что это “кривая P-384”), базовая разрядность – 384 бита. Точка кривой – это тоже два натуральных числа, из определённого интервала, связанных определённой формулой в пару координат. Точка-генератор G – всем известна, это открытый параметр криптосистемы. Обычно, хотя бы одна из координат G – это “большое” натуральное число. Но данные аспекты не относятся к обсуждаемой теме прямо. (Кстати, “большое” тут в кавычках, потому что с порядком в группе точек кривой всё не так просто, как хотелось бы.)

Соответственно, умножаем известную точку G на подбираемое значение d (это быстрая операция), получаем точку Q, представленную парой координат (натуральных чисел), сравниваем получившиеся координаты с атакуемым открытым ключом, если совпало – мы нашли секретный ключ, он равен d.

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

Но если при выборе секретного ключа d заведомо берутся значения больше 255 (например), то что это означает? Ничего нового: теперь нужно перебирать 256, 257, 258 и т.д. То есть, тут важен не сам аспект, что “все старшие байты нулевые”, а наличие дополнительной информации о структуре распределения секретных ключей. Естественно, есть хорошо известные варианты, к которым и относится этот случай с последовательными нулевыми байтами. Это тривиальные ключи, подпадающие под универсальные ошибочные схемы. И эти случаи можно проверять без какой-то дополнительной информации. Но если, предположим, известно, что секретные ключи на сервере – это значение SHA-256 от текущего таймстемпа и IPv4-адреса сервера, то пространство перебора тоже не очень велико.

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

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

Однако утилиты, проверяющие нестойкие ключи, были и есть, но их, как мы видим, далеко не всегда используют (УЦ 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? Почему нет? Тут даже не нужен полноценный кросс-ассемблер – достаточно одного из аспектов реализации “полиморфности”: этот аспект сможет переводить машинный код с одной платформы на другую. Такие решения даже существовали, но, понятно, массовыми они быть не могли по другим причинам.