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

В начале апреля, в записке про ненадёжное электропитание дата-центров, в которых работают “вычислительные облака”, я написал на dxdt.ru буквально следующее:

Не ровён час, окажется в подобном “облаке” и система управления всем прочим энергоснабжением.

Не прошло и месяца, как в Испании электрическая сеть практически полностью, по всей стране, отключилась. Очень похоже, что как раз из-за проблем с управлением самой сетью.

То ли ещё будет.

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

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

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

Хорошо известный удостоверяющий центр SSL.com выпускал TLS-сертификаты для доменов без проверки права управления. Как пишут, статус “подтверждённого имени” получал всякий домен, на произвольный почтовый адрес в котором пользователь смог получить код подтверждения для любого другого домена. То есть, можно было разместить заказ на TLS-сертификат для example.com, выбрать способ подтверждения с отправкой кода по адресу email, указанному в TXT-записи (и такое бывает), – например, akhmet@test.ru, – подтвердить получение кода, и доменное имя из состава адреса, – то есть, test.ru, – тоже получало статус прошедшего проверку права управления.

Очередное подтверждение того, что проверка права управления (DCV) должна проводиться перед выпуском каждого сертификата, для всех имён, указываемых позже в сертификате, и только для этих имён, но строго после получения соответствующего заказа (и процесс подтверждения должен быть привязан к конкретному заказу и к конкретному ключу из заказа). И, конечно, никаких проверок по email для TLS-сертификатов.

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

На днях опубликовал на “Хабре” небольшую статью про парадокс Ньюкома в применении к ИИ, как к программе. Так как статья небольшая, туда много что не вошло – см. ниже. (Но зато есть расшифровка диалога с ChatGPT по теме.)

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

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

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

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

(Возможно, если вдруг будут ресурсы на это – напишу продолжение. А так-то из разбора парадокса Ньюкома для современного ИИ может выйти и книга.)

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

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

Вообще, по сравнению с радиотелефоном, такая схема заметно лучше защищена от утечек, поскольку световой луч сконцентрирован. Это тем более касается лазера. Лучше ли защита от помех – это вопрос посложнее. Если используется солнечный свет, то в пасмурный день телефон вообще не работает. Кстати, можно взять специальные свечи, в качестве источника яркого света, попутно получив “Гиперболоид” им. инженера Гарина.

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

Конечно, нельзя сказать, что и учтеки исключены, и помехи не сработают. Что касается утечек, то принимать можно какие-нибудь блики, возникающие при работе передатчика. Впрочем, для 1880 года это довольно сложно – слишком высокая чувствительность потребуется.

Регистрацию домена 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, после чего – переходить уже к прослушиванию штатного цифрового канала, расшифровывая данные из него. Одни и те же ключи используются подолгу, и не одной радиостанцией, так что улов, обеспеченный утечкой ключа шифра, будет намного больше, чем в случае аналоговой речевой наводки, которая вот сейчас ещё прослушивается, а через минуту – уже нет, потому что мешает какое-нибудь отражение.

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

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