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

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

(Source: Wikimedia)

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

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

Вообще, “коммутативность” тут именно в кавычках, поскольку математическая структура несколько сложнее. Запишем операцию в виде формулы, где “*” соответствует смешиванию красок и действует слева: α * G – означает, что секретная краска α смешана с краской G (чтобы как-то обосновать “левое и правое” действие – считаем, что колер α добавлен в банку к краске G). Тогда: β * (α * G) == α * (β * G) – это то, что происходит в протоколе с красками. То есть, сторона A получает результат смешивания (β * G) и замешивает свою краску α: α * (β * G). Сторона B – наоборот. Казалось бы, должно выполняться (α * β) == (β * α), тогда работает схема. Именно так устроено в классическом DH, но с показателями степенй: (G^β)^α == (G^α)^β. Однако для протокола на красках, вообще говоря, (α * β) == (β * α) хоть и очевидно работает в “локальном” случае, но не применимо в иллюстрируемой схеме – ведь ни у стороны A, ни у стороны B нет готового состава (α * β) – они не могут его приготовить по условию “неразделимости” красок. Вариант (α * β) * G провернуть не получится, по условиям задачи: краски – это не натуральные числа. Поэтому-то “коммутативность” тут – это не настоящая коммутативность (без кавычек). Требуется именно “одинаковость” действия и краски α, и краски β на уже смешанные и подходящие краски. Это можно переписать в других обозначениях: A := α * G (подмешали α в G); B := β * G (подмешали β в G); α * B == β * A – потребовали выполнения базового свойства, необходимого для работы протокола DH на красках: β переводит A в тот же цвет, в который α переводит B.

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

Дело не только в химии: именно обобщение структурной особенности, которая переводит две разных “краски” строго в одну при действии разными элементами (другими “красками”) как раз и позволяет максимально обобщить и сам протокол DH, переписав его в терминах того, что в математике называется “действием группы”. Это, впрочем, отдельная история.

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

Классический вариант DH требует возведения в степень. Показатель степени является секретным ключом. Чтобы атакующая сторона не могла перебрать все показатели за обозримое время, значение должно быть большим. Но как быть стороне протокола, вычисляющей открытый параметр при помощи того же возведения в степень? Последовательно умножать генератор столько же раз, сколько и атакующий – выглядит несколько абсурдно. Хорошо, что знание показателя степени позволяет использовать быстрые методы, построенные на возведении генератора в квадрат и домножении на генератор в “нечётных” случаях: например, чтобы возвести 2 в пятую степень нужно дважды возвести 2 в квадрат и домножить на 2 – (2^2)^2 * 2, это три умножения, а не четыре, как для 2*2*2*2*2. В красках этого нет, но для любого практического воплощения протокола DH данное свойство “удвоения со сложением” необходимо – иначе легитимные стороны протокола оказываются в том же положении, что и атакующая сторона.

Недавно публиковал заметку о том, как перейти с ECDH на ML-KEM в проекте на Go: там на схемах показано, что DH можно уложить в схему KEM, что делает переход почти прозрачным. С этим связан интересный момент, касающийся свойств криптографической схемы, который в англоязычной традиции называется interactive и non-interactive (“интерактивная” и “не интерактивная”).

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

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

Но главное отличие – DH можно переписать в KEM (не конкретно ML-KEM, а именно в схему), а вот произвольную схему KEM в DH – не выйдет.

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

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

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

Всё же, более эффективен какой-то гибридный метод, учитывающий и GNSS, и сетевые задержки, и, скажем, локальную электромагнитную обстановку: кто сказал, что не стоит добавить сюда WiFi и базовые станции GSM?

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

Google сообщает, что после 30 мая 2025 года “системы, использующие шифр 3DES для SMTP-соединений, не смогут доставлять электронную почту на аккаунты Gmail”. Про 3DES и SMTP-соединения – это буквально так и написано в исходном сообщении (“systems using 3DES for SMTP connections”). Но, насколько можно судить по прочим деталям, имеется в виду всё же TLS, а не непосредственно SMTP.

3DES – это схема использования очень старого симметричного шифра DES с подмешиванием дополнительных ключей, что повышает общую оценку стойкости до 112 бит (оригинальный DES – это 56 бит максимум; практически ничего, по современным меркам). Естественно, схема эта устаревшая, и безальтернативное её использование в 2025 году выглядит странно. Каких-то суперэффективных атак, полностью убивающих 3DES, пока не публиковалось, но 112 бит – это всего лишь 112 бит. И тем не менее, в почтовой системе может быть применена реализация TLS на уровне “хоть какой-то”, это всё равно лучше, чем передача в открытом виде.

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

Есть и иной аспект. Если посмотреть на опубликованный список шифров, которые поддерживаются в конфигурации TLS на почтовых серверах Gmail, то станет ясно, что там, за вычетом 3DES, остаётся только AES и ChaCha20. При этом, если не использовать TLS 1.3, то остаётся единственный вариант – AES.

Разработчик утилиты curl Даниэль Стенберг снова указывает на то, что сообщения об “уязвимостях”, сгенерированные при помощи ИИ/LLM – это очередной вариант DDoS: сообщения выглядят как настоящие, хорошо оформлены, однако не несут никакого полезного смысла и только отнимают существенное время у разработчиков, вынужденных эти сообщения проверять и вести по ним переписку, опять же, с LLM/ИИ в качестве корреспондента; при этом отмечается, что разработчики curl пока не видели ни одного достоверного сообщения об уязвимости, подготовленного с помощью ИИ, при этом поток мусора (“ИИ-помоев”) – увеличивается.

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

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

Речь тут вот о чём. Любое минимально содержательное утверждение можно переписать в виде набора усложнений, описывающих всё то же утверждение. Тавтологическое переписывание является традиционным источником околоматематических шуток: “возьмём формулу 1 == 1, перепишем единицу справа как определённый интеграл exp(-x) от нуля до бесконечности, а левую – как π/π” и т.д. – в итоге можно получить сколь угодно сложное, многоэтажное сочетание загадочных символов, которое, тем не менее, будет верным. При этом, что удобно именно в учебных задачах уровня ЕГЭ, так это то, что исходное утверждение можно вообще не приводить – оно считается известным.

Сумма углов треугольника равна 180°. Запишем это так: дан треугольник ABC, в котором сумма углов при стороне AC равна сумме двух прямых углов минус третий угол треугольника. Это, очевидно, верно для всякого треугольника в “школьной” геометрии на плоскости, прежде всего потому, что это всего лишь перфразированная аксиома (да, которая делает геометрию евклидовой, но эти детали сейчас не рассматриваем). Однако, во-первых, для записи используется достаточно много слов, что имеет ключевое значение для LLM; во-вторых, выглядит как формулировка свойства, применимого только к данному треугольнику данной задачи; в-третьих, в основе лежит верный геометрический факт, широко используемый в задачах.

Может присутствовать возможность тривиального решения. А может быть – тривиальное решение только подразумевается, то есть, приводится лишь запись как бы задачи, решить которую невозможно, поскольку не хватает данных. Получается своего рода капча – LLM в любом случае будет генерировать “ответ” или вывод “противоречий”, учитывая слова формулировки.

Пример первый – это просто набор утверждений, который подразумевает тривиальные соотношения, постоянно используемые в задачах по планиметрии:

В равностороннем треугольнике ABC углы обозначены α, β, γ, а из вершины B проведена медиана BP. Сумма углов α и β при стороне AC равна сумме двух прямых углов минус угол γ. Найдите высоту треугольника ABC.

Когда я задал эту “задачу” ChatGPT-4o, LLM верно перечислила все фундаментальные свойства равностороннего треугольника (углы – 60° и т.д.), верно распознала углы при стороне AC (в тексте, не на чертеже – см. ниже), но дальше – принялась “рассуждать” о том, что сумма двух прямых углов это (внимание!) 360°, а поэтому сумма углов α и β даст 300°, но должно быть 120°.

“120° ≠ 300°. Противоречие. […] Очевидно, что если треугольник равносторонний, то углы не могут давать такую сумму” – написала данная языковая модель свой вывод, перепутав прямые и прямые углы.

То есть, капча сработала. Если бы капча не сработала, если бы ответ был “интеллектуальным”, то LLM должна была бы написать что-то типа такого: “в задаче не хватает данных – найти высоту треугольника невозможно, но можно, например, утверждать, что высота равна медиане”.

Второй пример – в ту же формулировку дописываем длину медианы:

В равностороннем треугольнике ABC углы обозначены α, β, γ, а из вершины B проведена медиана BP длиной 5. Сумма углов α и β при стороне AC равна сумме двух прямых углов минус угол γ. Найти высоту треугольника ABC.

Казалось бы, тут рассказы про углы можно отбросить: из того, что треугольник равносторонний – сразу же следует, что высота равна медиане, то есть ответ – 5. Но если эту же, “уточнённую”, задачу задать ChatGPT в том же потоке, где была задана предыдущая, то выясняется, что данная LLM не только не может отбросить тавтологическую часть условия, но ещё и продолжает считать, что сумма углов – 360° == 180° + 180°. Я не привожу весьма объёмные и подробные “рассуждения” ChatGPT, чтобы не перегружать текст. Если кратко, то LLM предположила, что имеются в виду углы, “образованные при построении медианы BP”, сложила углы уже в двух получившихся треугольниках, и объявила, что “Всё сходится!” (ну конечно, “сходится” – ведь сумма углов двух треугольников это 360°, как и сумма “двух прямых”, в представлении LLM; заметьте, что это, без сомнения, одна из лучших систем в мире, но почему-то предполагается, что данная LLM, якобы, может успешно решать не только ЕГЭ, но и задачи “олимпиадного уровня”).

Далее ChatGPT продолжает “решать” задачу и, используя формулу для длины медианы в равностороннем треугольнике, вычисляет, – в лучших традициях, по формуле! – высоту, подставив найденное значение стороны в формулу высоты. Ответ верный – 5.

Сработала ли и тут “тавтологическая капча”? Да, сработала. Смысла в вычислении по формулам не было: то, что высота равна медиане – этой свойство треугольника ABC. Можно ли трактовать этот момент как желание LLM действовать в парадигме “подставляем числа в формулы так, чтобы получилась хорошая оценка”? Нет. Этому противоречат подробные и точные рассуждения о свойствах треугольника и данная рядом глубоко неверная трактовка суммы двух прямых углов. Естественно, если ChatGPT подсказать, что с прямыми углами тут что-то не то получилось, и что практический смысл интерпретации дополнительных слов условия – тёмен, система тут же исправляется – и сумма углов становится равной 180°, и признаётся, что можно сразу определить, чему равна высота.

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

И посмотрите на чертёж, нарисованный к данной задаче ChatGPT. Казалось бы, система “умеет выводить” формулы и “решать задачи ЕГЭ”, но почему-то не может верно обозначить углы и провести медиану в соответствии с условием.

Можно ли “смешать” 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 – редкая технология.

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

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

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

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

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

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

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

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

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

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

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.