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

Регистрацию домена dxdt.ru продлили на очередной год, пока что без всяких нововведений (кроме, разве что, возросшей в несколько раз стоимости у регистратора). Это я пишу в продолжение прошлогоднего сообщения о том, что, возможно, не получится продлевать. Посмотрим, как будет дальше.

P.S. У меня есть страница статуса под резервным адресом dxdt.root-key.net и несколько дополнительных доменов для имени dxdt в .su, .pw, .blog. Но вот куда и как переносить сайт, если переносить – я пока не придумал.

Скопирую сюда своё сообщение с “Хабра”:

В связи с интенсивным сокращением максимального срока действия TLS-сертификатов (пока что обещают 47 дней, но для всех и к 2030 году), коллеги саркастически поинтересовались, можно ли сделать так, чтобы сертификат выписывался на каждый TLS-запрос. Шутки – шутками, но сделать-то можно. И даже не требуется переделывать протокол TLS – есть готовое решение.

Если внимательно посмотреть на алгоритм TLS-хендшейка, то окажется, что секретный ключ, соответствующий открытому ключу из серверного сертификата, требуется там только один раз – для формирования подписи в сообщении CertificateVerify. Соответственно, секретного ключа от сертификата вообще может не быть на сервере, а сервер будет обращаться к некоторому подписывающему узлу, у которого этот ключ есть и который подтвердит TLS-сессию, подписав значение для CertificateVerify. Это вовсе не теоретическое рассуждение, именно так делается на практике, когда входящие соединения принимает прокси-провайдер (CDN, обычно), но передавать этому провайдеру секретные ключи от сертификатов для своих доменов клиент не желает. Первыми в промышленных масштабах такую услугу сделали в Cloudflare, более десяти лет назад. Называется Keyless SSL.

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

Сертификат, таким образом, окончательно превратится в безотзывный тикет доступа, мгновенного действия, а сервер будет привязан к центральному провайдеру (можно совместить с крупными CDN, у которых и так есть собственные хорошо известные УЦ). Проверку совпадения подписей, серверной и на сертификате, будет всё так же проводить браузер (речь, напомню, про веб). В браузере ничего не нужно переделывать совсем: если сервер не смог предъявить корректную подпись в CertificateVerify – TLS-сессия браузером установлена не будет.

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

Опубликовал на “Хабре” небольшой разбор того, какую структуру имеют TLS-сертификаты, на примере “шестидневного” сертификата от Let’s Encrypt – какие хитрости есть в формате серийного номера, что будет с параметрами проверки статуса сертификата, как выглядят SCT-метки и пр.

Комапния “Яндекс” пишет, что “поиск Яндекса” научился объяснять “решение математических задач из старшей школы”. Конечно, при помощи нейросетей. Цитата:

Например, он [“Поиск”] может рассказать ход решения показательных и несложных тригонометрических уравнений, а также найти предел функции.
[…]
Яндекс обучил её [нейросеть] на одном миллионе примеров заданий для старшеклассников. Это позволило добиться точности ответов в решении задач в 90% случаев.

Какой ещё “точности” ответов в 90% случаев удалось добиться – в новости не объясняют. Вообще, рутинные “показательные и несложные тригонометрические уравнения” старшей школы, если они корректно составлены, можно точно, с объяснениями решать автоматически при помощи системы компьютерной алгебры (пример, как в иллюстрации к новости), без всяких этих “процентов случаев”.

Для условий задач, составленных с ненамеренными ошибками – часто можно точно обнаружить ошибку, тоже системой компьютерной алгебры (но, понятно, не всегда: если условие испортить специально, то можно построить неразрешимый для компьютера случай). И тем не менее, там все символьные операции алгоритмизируются точно, пусть и не самым тривиальным методом. Так что не требуется угадывание описания процесса поиска ответа при помощи синонимайзера, который не так давно утверждал, что “число делится на 2 и на 11, а значит, делится и на 3”. Да ещё и с какой-то точностью ответов – “в 90% случаев”. Конечно, можно сказать, что 10% случаев – это и есть некорректно составленные задачи, но это будет выдумка, потому что тогда система должна была бы сказать, что задача некорректная, а не выводить неверное решение.

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

Технически, в TLS-сертификате, вместе с именами хостов, можно указать и IP-адреса, форматом допускается. За примерами не нужно далеко ходить – сертификат на веб-сервере dns.google содержит и DNS-имена, и IP-адреса:

X509v3 Subject Alternative Name: 
 DNS:dns.google, DNS:dns.google.com, DNS:*.dns.google.com,
 DNS:8888.google, DNS:dns64.dns.google,
 IP Address:8.8.8.8, IP Address:8.8.4.4,
 IP Address:2001:4860:4860:0:0:0:0:8888,
 IP Address:2001:4860:4860:0:0:0:0:8844,
 IP Address:2001:4860:4860:0:0:0:0:6464,
 IP Address:2001:4860:4860:0:0:0:0:64

При этом dns.google показывает на те же IP-адреса, которые перечислены в сертификате. Это, конечно, не означает, что IP-адреса из сертификата должны быть связаны с именами в том же сертификате через DNS – просто, сертификат будет валиден и для любого из указанных IP-адресов отдельно (при совпадении подписей, конечно).

Однако в теории тот же браузер может потребовать, чтобы в сертификате и имя хоста совпадало, и IP-адрес, по которому установлено TCP-подключение. Двойная проверка.

Чем такая схема, если бы её реализовать, грозит? С одной стороны, схема неожиданным образом защищает от использования секретного ключа другим сервером, если таковой сервер использует другой IP-адрес. Подключение к подставному серверу можно реализовать подменой DNS, так что имя – совпадёт. Но не IP-адрес. Может ли атакующий, вооружённый секретным серверным ключом, соответствующим ключу в сертификате, подменить и IP-узел? То есть, сделать так, чтобы перехватывающий, подменный узел стал доступен для атакуемого клиента по тому же IP-адресу, который указан в сертификате? Как ни странно, не факт – владение секретным ключом от сертификата никак не помогает в решении сетевой задачи подмены IP-узлов. При этом, если в сертификате сверяется только имя хоста, то атака сработает уже и при подмене DNS. С другой стороны, тот, кто может подменить IP-узел и DNS, может попытаться выпустить сертификат для этих реквизитов. Однако такая подмена уже потребует атаки на системы УЦ, а не на обычного клиента веб-узла.

На одном IP-адресе может размещаться большое количество веб-узлов с разными именами. Но это не является препятствием для того, чтобы вписать для всех этих узлов один и тот же IP-адрес в сертификат. Сертификат может быть выпущен только для IP-адреса. Например, такие сертификаты обещает даже Let’s Encrypt. Но если обращение к узлу происходит в контексте, где нет DNS-имён, то можно использовать сертификат только с IP-адресом, и если бы был возможен контекст, в котором есть только DNS-имя, то сгодился бы сертификат только с именем, как сейчас. Так что тут проблемы нет. Тем более, если сертификаты начинают выпускаться всего на несколько дней.

Проблемы возникнут при попытке замены IP-адресов в DNS – нужно будет согласовывать такую замену с выпуском новых сертификатов. IP-адреса могут выбираться из большого пула и, конечно, строго привязывать их при помощи TLS-сертификата и к DNS-имени, и к серверу на уровне приложения не очень-то удобно. А соответствие адресов именам в DNS, вообще-то, подтверждает DNSSEC, тоже при помощи электронной подписи. Но DNSSEC – редкая технология.

Утечки по побочным каналам (ПЭМИН) возможны разные. Предположим, что есть некоторая портативная радиостанция (рация), которая штатно использует защищённый радиопротокол. Что-нибудь типа P25 – это тут не так важно, главное, чтобы использовался цифровой сигнал, а полезная информация передавалась в зашифрованном виде.

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

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

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

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

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

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

Сообщают, что CA/B-форум принял решение сократить к 2029 году максимальный срок действия TLS-сертификата до 47 дней. В принципе, это давно ожидалось. Скорее всего, могут даже сдвинуть срок раньше, да и максимальный интервал – сократить (дней до 14, скажем). Я в прошлом году писал в заметке о шестидневных сертификатах Let’s Encrypt:

Это нововведение Let’s Encrypt, не сомневайтесь, прямо означает, что браузеры, следом за Chrome/Chromium от Google, постараются оперативно перейти на короткие сертификаты, запретив срок действия дольше месяца (например).

Процесс, скорее всего, коснётся и сертификатов, которые выпускаются от собственных УЦ, не входящих в CA/B-форум.

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

Но необходимо учитывать и другую сторону решения. Сертификаты превращаются в квитанции, разрешающие доступ. Что-то вроде тикетов в каком-нибудь Kerberos. Короткие сертификаты означают, что веб-узлам придётся плотно привязаться к внешней централизованной системе. Те же 47 дней, это даже не три месяца от Let’s Encrypt. Всякий веб-узел должен будет постоянно и в автоматическом режиме отмечаться на центральном сервере, который станет выдавать (или не выдавать) подтверждение, что браузерам всё ещё разрешено к этому веб-узлу подключаться.

Недавно опубликовано очередное сочинение-опус про AI/ИИ и кардинальные изменения в статусе цивизизации к 2030 году: AI 2027 (англ., много букв). Пусть вас не обманывает 2027 в названии – самые радикальные прогнозы там, как сейчас принято, даны на 2030, а в 2027 году только ожидается деятельный суперинтеллект (это, впрочем, менее двух лет осталось ждать).

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

Конечно, в упомянутой публикации используются всё те же шкалы для измерения уровня “интеллектуальности” – способность “писать код” (какой код, зачем?) и способность “быть лучше лучшего из человеков в решении когнитивных задач” (каких именно задач, почему?). А сценарная концепция, кроме типового сейчас требования регулирования и вмешательства правительств, строится на понятии “автономных агентов”, которые, на начальном уровне, “получив инструкцию через Slack или Teams, вносят существенные изменения в код самостоятельно, иногда экономя часы или дни [разработки]”.

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

Впрочем, в тексте AI 2027 некоторые “оценочные суждения” сопровождаются определениями из серии “Что бы это значило?”. И это странные определения, вполне в духе выдачи условного ChatGPT. Например, объяснение того, что имеется в виду, когда пишут про 50-процентное ускорение разработки ИИ-алгоритмов при использовании ИИ, следующее: “50-процентное ускорение – это означает, что [компания] OpenBrain, используя ИИ, достигает за неделю такого же прогресса в исследовании, как она достигла бы за полторы недели без использования ИИ”. Содержательно, да.

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

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

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

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

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

Но самое показательное – это концовки данного произведения. Понятно, что под них и писалось всё остальное. AI 2027 предлагает две возможных концовки. Одна из них – уничтожение всех человеков мощным ИИ в 2030 году при помощи “биологического оружия”; ИИ далее модифицирует под свои нужды планету Земля, колонизирует прочее пространство Солнечной системы и далее, за её пределами, силами роботов.

Другая концовка – объединение всех государств мира под управлением США (да), происходящее в результате локальных переворотов, которые ИИ помогает реализовать (так написано); после чего наступает эра процветания (или милосердия?), человеки запускают ракеты, – для колонизации планет Солнечной системы, а не то что вы подумали, – и всё это с помощью хорошего ИИ.

Иных вариантов, кроме этих двух, сочинение-прогноз не предусматривает. С Днём Космонавтики, как говорится.

“Яндекс”, у которого недавно приключилась авария с полным обесточиванием одного из дата-центров, публикует разбор произошедшего. Пишут, что отключились сразу обе из имевшихся двух вводных линий, которые, как выясняется, шли от одной подстанции. Цитата:

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

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

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

Автономного питания, конечно, в дата-центре “Яндекса” тоже не хватило, потому что оно же не на случай полного отключения проектировалось. Цитата:

В 12:27 главный инженер обслуживающей организации связался с дата‑центром и сообщил, что на подстанции отключились обе линии 110 кВ, но причина пока неизвестна. А значит, у нас Проблема № 1: сразу две точки отказа по питанию с непонятным прогнозом, а дизель‑генераторы просто не рассчитаны на то, чтобы принять такую нагрузку.

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

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

Добавил в раздел избранных записок ещё пять:

• Хеш-функции для анонимизации
• Философский аспект конструирования электронных часов
• Метки в текстах LLM и целевое влияние на результат
• Обобщение “хендшейков” и сокращение этапов согласования
• Разноцветные шары и “анонимизация”

Опубликовал на “Хабре” статью про DNS-over-HTTPS.