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

Утечки по побочным каналам (ПЭМИН) возможны разные. Предположим, что есть некоторая портативная радиостанция (рация), которая штатно использует защищённый радиопротокол. Что-нибудь типа 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.

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

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

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

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

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

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

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

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

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

Кстати, вот пара сервисов, позволяющих просматривать информацию из российских логов Certificate Transparency через веб:

ct.tlscc.ru – экземпляр crt.sh, но с российскими логами (используется TLS-сертификат ТЦИ);
precert.ru – весьма удобный самостоятельный сервис, отличается от crt.sh веб-интерфейсом, форматом вывода и возможностями расширенного поиска.

Отмечу отдельно некоторые записки, вышедшие в марте 2025:

• Практикум: примеры с dig для DNSSEC и DNS
• Техническое: переходим с ECDH на ML-KEM в проекте на Go
• Проценты программного кода от ИИ
• Постквантовые криптосистемы до алгоритма Шора
• Площадь круга и Младший Герон из Византии

Certificate Transparency (CT) это технология публикации сведений о сертификатах, выпускаемых Удостоверяющими Центрами (УЦ). TLS-сертификатов для веба в Интернете выпускается очень много. Чтобы отдельные CT-логи не разрастались чрезмерно – придумали “таймшардинг” (от англ. time и sharding: “временно́е разбиение” (нередко также называют “сегментацией” в русскоязычных текстах)).

При “таймшардинге” отдельный лог заводится для определённого периода, например, на год. Как и везде в Certificate Transparency, тут алгоритм тоже не самый очевидный: подходящий лог выбирается по времени окончания действия сертификата (а не начала, как можно подумать). Если сертификат выпускается на 12 месяцев (365 дней) 05.03.2025 (пятого марта 2025 года), то публиковать (пре)сертификат нужно в тот лог, в интервал которого попадает дата окончания действия в марте 2026 года, например, интервал действия подходящего лога может начинаться 03.03.2026 и оканчиваться 03.10.2026.

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

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

В российском варианте Certificate Transparency, который используется для сертификатов собственных удостоверяющих центров (сейчас это НУЦ и ЦС ТЦИ), интервал действия для “свежих” логов установлен в один год. Раньше некоторые российские логи имели интервал в 13 месяцев, да ещё и с перекрывающимися датами, что облегчало тестирование при добавлении новых логов. Конечно, при том объёме сертификатов, которые сейчас попадают в российские логи CT, использование “таймшардинга” выглядит несколько странно: данный метод должен применяться там, где количество сертификатов, принимаемых ежемесячно, измеряется сотнями тысяч и более, а не сотнями. Возможно, при запуске учитывали риск “внезапного роста”.

Заметьте, кстати, что с целью предотвращения замусоривания публичные CT-логи обычно принимают только сертификаты, выпущенные от закрытого списка корневых ключей, то есть, только от некоторых УЦ. Поэтому разместить произвольный сертификат в произвольный лог – не получится: нужно, чтобы лог “верил” в соответствующий корень (промежуточные сертификаты можно подставить вместе с публикуемым оконечным). Поэтому, например, российские CT-логи “Яндекса” не содержат сертификатов от Let’s Encrypt.

Пишут (The Register, англ.), что “топ-менеджмент” администрации президента США обсуждал “секретные” военные планы через мессенджер Signal, да ещё и в групповом чате, в который был добавлен журналист (видимо, по ошибке). Журналист про это и рассказал.

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

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