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

В DNS есть несколько штатных способов создать циклы, которые сделают обычный рекурсивный опрос невозможным. Самый привычный способ – использование субординатных NS. То есть, пусть зона example.com делегирована на два авторитативных NS – ns1.example.com, ns2.example.com. Оба имени находятся в исходной зоне example.com, откуда и название “субординатные”. Чтобы найти A-запись в зоне example.com – резолверу нужно опросить хотя бы один из авторитативных NS-ов, а чтобы опросить NS, нужно знать его IP-адрес (A- или AAAA-запись), а чтобы узнать IP-адрес – нужно опросить авторитативный NS зоны example.com, ну и так далее.

Если бы не glue-записи с IP-адресами, то разрешить такой цикл было бы невозможно. Glue-записи – это специальный способ предоставить резолверу IP-адреса узлов, которые, из-за циклов в адресации, невозможно найти обычным рекурсивным опросом. Эти записи передаются авторитативными серверами в специальной секции DNS-ответа и, в случае примера выше, сразу содержат IP-адреса для имён ns1.example.com, ns2.example.com. Без glue-записей практическая DNS работать не будет. И не только по причине наличия только что описанного элементарного цикла: есть случаи и посложнее.

Один из таких случаев – “кросс-делегирование”. Предположим, что зона example.net делегирована на ns1.example.com, ns2.example.com. Обратите внимание: из зоны .net – делегируется на имена в .com. При этом зона example.com – делегирована на ns1.example.net, ns2.example.net.

Теперь предположим, что резолвер ищет A-запись для example.com. Как резолвер мог бы действовать:

(0) для обнаружения нужной A-записи резолверу необходимо найти авторитативные серверы зоны example.com;

(1) на авторитативных серверах делегирующей зоны .com резолвер узнаёт, что NS для example.com – ns1.example.net, ns2.example.net;

(2) теперь резолвер должен определить A-записи для этих имён серверов (ns1.example.net, ns2.example.net);

(3) но для этого нужно найти авторитативные серверы зоны example.net;

(4) на серверах делегирующей зоны .net резолвер узнаёт, что имена этих серверов – ns1.example.com, ns2.example.com;

(5) теперь, чтобы узнать A-записи ns1.example.com, ns2.example.com, резолверу нужно определить авторитативные серверы зоны example.com, но это – шаг (1); получился цикл.

Естественно, настраивать так зоны, мягко говоря, не очень хорошо, даже несмотря на то, что данный цикл разрешается с использованием glue-записей. В случае использования glue-записей, их должна предоставлять каждая делегирующая зона, но в составе этих записей уже будут имена из другой зоны. То есть, в случае простого примера с субординатными NS для example.com – glue-записи содержат адреса серверов внутри example.com (ns1, ns2); в случае “кросс-делегирования” – адреса уже будут для имён в example.net.

Это далеко не все варианты создания циклов. Есть и ещё более сложное “петлевое” делегирование, и постоянно неверно используемая запись CNAME. Что касается CNAME, то это самая проблемная запись в DNS. CNAME предназначена для перезапуска процесса рекурсивного опроса. Вдумайтесь: в DNS изначально заложен сигнал, который, при штатном использовании, заставляет резолвер “начать заново”. Можно ли предложить лучшую основу для DoS? Вряд ли. Потому что если резолвер, отправив запрос про test.ru, получил CNAME с указанием на example.com, то он должен “забыть” исходное test.ru и начать опрос DNS для example.com. И так далее. CNAME можно указать для любого имени. Стоит ли говорить, что нетрудно построить цикл из нескольких CNAME? Нет, не стоит – это очевидно, а такой цикл может быть сколь угодно сложным.

Естественно, DNS-резолверы вынуждены отслеживать все эти особенности, чтобы не зависнуть.

Из серии “Кто бы сомневался!”: в Project Zero публикуют описание того, как, проэксплуатировав две уязвимости (CVE-2025-54957, CVE-2025-36934), им удалось выполнить на android-устройстве произвольный код с правами ядра ОС. Тут самое интересное не уязвимости, а то, что данную атаку на уровень 0-click (то есть, без участия пользователя) переводит наличие в смартфоне ИИ-агента, читающего входящие сообщения.

Вектор атаки требует, чтобы библиотека кодека прочитала специально подготовленный звуковой файл. Для этого нужно открыть и почитать вложение к входящему сообщению SMS/RCS. Раньше для этого пользователь должен был кликнуть на сообщение и попытаться открыть его. Но теперь за пользователя всё удачно делает ИИ-агент, встроенный в гугловый сервис и выполняющий транскрибирование всех голосовых сообщений.

Вот поэтому попадает в серию “Кто бы сомневался!”. Как говорится: эти ИИ-агенты – они и эксплоиты будут вместо пользователя на его устройстве запускать. Максимальная автоматизация.

(Описание на OpenNET.)

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

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

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

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

Рассмотрим практические особенности схемы с выделенной файлообменной машиной.

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

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

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

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

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

Почему-то часто считают, что SSH-доступ всегда эквивалентен локальному шелл-доступу к основной системе. Но это не так. Понятно, что, – по нынешним-то временам, – путь от локального аккаунта до суперпользователя не так долог, как хотелось бы (возможно, теоретически, это не так под чем-нибудь вроде хорошо настроенной FreeBSD, но речь про практическую ситуацию). Однако, никто ведь не сказал, что и SSH-сервер, и шелл, предназначенные исключительно для реализации обмена файлами, нельзя изолировать локально, выкинув всё лишнее, и не только под FreeBSD. Нет, вовсе не обязательно использовать тот же сервер и тот же шелл, которые нужны DevOps для управления. Напротив – подключаемся, заходим, а там изолированная директория и, вместо полноценного шелла, только урезанный набор из ls, mkdir, cat, (s)cp и mv (rename), предположим. То есть, для атакующего – опять дополнительные шаги и локальные хопы (loopback какой-нибудь использовать и пр.), а каждый хоп, не забывайте, тоже повышает шансы обнаружения вторжения.

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

Сравним теперь нашу схему с вариантом, когда файлообменной машины нет, а экспортирующая информационная система (“Система А”) загружает данные непосредственно в импортирующую (“Система Б”), через специальный высокоуровневый прикладной интерфейс (API), поднятый именно с этой целью. Это может быть rsync, но может быть и HTTP-сервер. Тогда, если принимающая система скомпрометирована, то получается, что экспортирующая система уже прямо подключается к контролируемому атакующей стороной серверу. В случае файлообменной машины это не так: там требовалось сперва захватить саму файлообменную машину. Но, естественно, остаётся необходимость ожидать момента подключения.

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

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

Регулярно теперь попадаются упоминания про то, что нужно и разрешить использование, и немедленно реализовать, внедрить “ИИ-агентов/LLM” там, где раньше допускалось лишь строго “детерминированное” программное обеспечение, например, в бортовые системы боевых самолётов. Типа, такое внедрение ИИ даст “невиданные преимущества”, “качественный скачок” и т.д., и т.п. – следует набор типичных для “ИИ-хайпа” журналистских штампов.

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

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

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

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

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

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

Но, если возможность всё же есть, то что же это получается – это тогда никакой не “интеллект”? Получается так, да.

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

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

С одной стороны, схему, когда “не всё известно точно”, можно обозначить как то, что допускается использование “недетерминированных систем”. Типа, условный ИИ-агент может действовать различными способами, а человек-инженер не имеет возможности предсказать точно, какие именно действия совершит этот ИИ-агент, как не знает и деталей работы той или иной аппаратуры. Вот и вся диспозиция. Если допуск таких ИИ-агентов разрешается, предположим, в бортовые системы управления самолётом, то вот и самолёт теперь с “недетерминированной системой”. С другой стороны, в реальности, за этими ИИ-агентами всё равно стоит детерминированная аппаратура. Просто – теперь понимание устройства системы перешло к каким-то другим инженерам.

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

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

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

Сейчас тема развилась так хорошо, что на сторону провайдера ИИ/LLM-сервиса в онлайн-режиме передаётся исходный код программых продуктов, в том числе, внутренних корпоративных программных продуктов и экспериментальных версий. Да не просто код, а сведения о процессе подготовки этого кода. Заметьте, что провайдер обязательно использует этот новый код для “обучения” своих систем. А это прямо означает, что этот же код может быть передан другим пользователям сервиса. То есть, не просто провайдер получит код (тут можно вспомнить “социальную сеть” Github и пр.), но провайдер передаст этот код другим. (Тут вовсе не нужно вспоминать “копирайт” и прочие “бумажные соглашения”: как показала практика, поставщики ИИ/LLM на это внимания не обращают, списывая всё на добросовестное использование “в обучении” LLM.)

Казалось бы, какая разница, что исходный код уходит наружу? Код должен быть так написан, чтобы его утечка не приводила к проблемам с безопасностью самого ПО. Это верно. Но не нужно упускать такой момент: по коду нетрудно сказать, что за ПО разрабатывает компания, соответственно, нетрудно надёжно выявить список коммерческих проектов и текущий статус их разработки – а это уже весьма ценные сведения для конкурентной разведки.

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

Вот свежий пример от беспилотных такси Waymo: пишут (англ.), что эти машины остановились – как попало, заблокировав проезд! – почти по всему Сан-Франциско, как только там отключились светофоры. Светофоры отключились потому, что отключили электричество. Один эффект – вызвал другой, не менее неприятный.

Вообще, автомобиль всегда был достаточно автономным средством передвижения, которое средство может двигаться вне зависимости от внешних условий: у автомобиля локальный запас топлива, есть фары для тёмного времени суток, практически любой автомобиль способен передвигаться по плохой дороге или без дороги вовсе, есть немало автомобилей, которые, как раз, легко передвигаются без дорог, и т.д., и т.п. Но, как ни странно, не в случае беспилотных такси Waymo: оказывается, эти такси запрограммированы останавливаться совсем, если на перекрёстке не работает светофор. Заметьте, что правила дорожного движения, обычно, разрешают движение через перекрёсток при отключенном светофоре. Ну и уже тем более, просто из здравого смысла, можно продолжить движение в критической ситуации городского блэкаута. Но роботы-такси остановились. И не просто – они ещё и движение для других заблокировали.

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

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

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

Пишут, что в Microsoft запускают исследовательский проект по созданию ИИ-инструмента для “автоматизированного переписывания” программного кода с C/C++ на Rust. Зачем? А затем, “чтобы избавиться от C-кода” (что само по себе очень и очень забавно, особенно, если вспомнить, что уже и компилятор – это автоматизированный инструмент для перевода кода с того же Rust в машинные команды целевой платформы).

Вообще, исходное сообщение из Microsoft – оно про найм главного инженера-программиста, который мог бы этим (созданием проекта) заняться. Так что это далеко ещё не проект. Тем не менее, если исключить buzzwords, то занимательно звучит главная цель: миллион строк кода в месяц усилиями одного инженера. Это, на минуточку, получается около 6000 строк кода в час. Учитывайте, что это на каждом из языков, то есть, фактически, в два раза больше. Как инженер может читать, понимать и исправлять непрерывно (в рабочее время, конечно) по 6000 строк кода в час параллельно на каждом из языков (C/C++ – Rust) – этот момент, к сожалению, не объясняется. Но, скорее всего, понимать код и не требуется, раз его генерирует ИИ – достаточно уметь нажимать на кнопку Approve в “мёрдж-реквесте”.

Кругом buzzwords про ИИ. Некоторых эти самые buzzwords уже пугают. Вот и до Firefox добрались: в новом “стратегическом сообщении” пишут, что переделают Firefox в “современный ИИ-браузер” (“It will evolve into a modern AI browser and support a portfolio of new and trusted software additions”).

С одной стороны, понятно, что это просто дежурная штамп-фраза, без которой сейчас никуда в области корпоративных пресс-релизов. С другой стороны, для Firefox, конкретно, звучит оно пугающе. ИИ-хайп настолько уже велик, что подкладывают его везде. Нормального ПО нынче всё меньше. Почему? Потому что – ну, как же! – “ИИ полностью трансформировал разработку!”. Тут того и гляди линуксовое ядро начнут превращать в “ИИ-агента”, а там и до FreeBSD доберутся. Так что браузеров-то и подавно, считай, не осталось уже.

В продолжение предыдущей записки. Ещё один занятный момент про сверхкороткие TLS-сертификаты.

Понятно, что если сертификаты действуют недолго, то на заданном интервале времени сертификатов будет больше. Например, больше сертификатов будут попадать в логи Certificate Transparency (CT-логи). Возникнет дополнительное зашумление: если для домена example.com за месяц выпущено десять сертификатов вместо двух, как раньше, то запутаться с обработкой и мониторингом проще.

Если вы вдруг посчитали, что этот эффект надуман, да и вообще – быть такого не может, чтобы мониторы CT-логов что-то потеряли, то вспомните недавнюю весьма странную историю с сервисом 1.1.1.1 и Cloudflare. В той истории CT-логи непосредственно самой корпорации Cloudflare получили от внешнего удостоверяющего центра (УЦ) информацию о том, что – без санкции Cloudflare! – этим УЦ выпущены TLS-сертификаты для 1.1.1.1 (а это важнейший сервис Cloudflare), но даже корпорация Cloudflare, – без всякого сраказма: технологический лидер направления, – целый год ничего подозрительного в тех самых своих CT-логах каким-то образом не замечала. А теперь представьте, что сертификатов стали выпускать в десятки раз больше.

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

Сейчас тут обычно приводят в качестве препятствия всё ту же технологию Certificate Transparency. И действительно, если клиент проверяет метки CT (SCT) в сертификатах, то эти метки должны быть и в подменном сертификате. Вот только получение меток не требует размещения сертификата в публичных логах. Это, как раз, очень распространённая ошибка – считать, что SCT-метки гарантируют размещение в логах. Нет. Для вычисления валидной метки нужен только сам сертификат и секретный ключ оператора CT-лога. Так что, для подменного сертификата, могут генерироваться только метки, без размещения в логах. Это будет нарушением соглашений с браузерами. Но, как бы, в CT-логах, как мы только что выяснили, и так много “коротких” сертификатов для разных имён, и за ними никто особо не следит.

В IETF и вокруг сейчас происходит небольшой технический скандал, непосредственно связанный с внедрением рекомендаций по использванию негибридных криптосистем ML-KEM в TLS.

Если очень кратко, то переход на постквантовую криптосистему ML-KEM, как единственный механизм получения сеансового секрета, может восприниматься как попытка протолкнуть в TLS некий бэкдор, который отсутствует в X25519 (сейчас X25519 используется вместе с ML-KEM, в составе гибридной криптосистемы, поэтому бэкдор в ML-KEM, для гибрида, только лишь снизит стойкость в два раза).

На днях появилась весьма занятная публикация, непосредственно касающаяся технической части этого скандала: ML-KEM Mythbusting (“Разрушение мифов об ML-KEM”, англ.). Самый удивительный аспект этой публикации в том, что автор прямо утверждает: “в ML-KEM нет бэкдора, это можно доказать”. Вообще, доказать отсутствие бэкдора в криптосистеме не просто сложно, а, часто, невозможно. Особенно, если речь идёт об асимметричных схемах инкапсуляции ключа. Видимо поэтому в публикации по ссылке утверждение заметно более размытое: делается попытка доказать, что это в параметрах ML-KEM недостаточно энтропии для того, чтобы встроить качественный бекдор. (“Качественный” тут – это доступный только держателю секретного ключа от бэкдора, как в DUAL EC DRBG.)

Что имеется в виду? Вот что: якобы, если множество вариантов параметров криптосистемы достаточно маленькое, чтобы перебрать его за обозримое время, то бэкдор там негде прятать – его можно будет обнаружить простым перебором. И вот в ML-KEM, как бы, это множество – всего 34 бита. Как бы, утверждение верное, вот только оно сильно слабее, чем предположение о бэкдоре: бэкдор может находиться непосредственно в алгоритмах, поэтому, для его обнаружения прямым перебором, нужно будет мощность множества параметров возвести в некоторую большую степень (это, примерно, как идея моделирования квантовых вычислений, когда у вас все 2^34 варианта участвуют в расчётах на каждом шаге).

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

Вообще, конечно, история, в которой ML-KEM почему-то начинают тщательно “обелять”, доказывая, что там нет бэкдора – несколько подозрительная.