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

Ещё в копилку реального использования LLM, но, в данном случае, “картиночных”.

Это ChatGPT современной версии (которая доступна через веб-интерфейс на бесплатном аккаунте, видимо, какая-то 5.x). Попробовал старинный запрос – нарисовать настенные часы. Но в этот раз – с 11-часовым циферблатом (такие картинки полезны, когда нужно объяснить арифметику остатков, например, сравнивая составное 12 и простое 11). Пишем достаточно подробный, на мой взгляд, промпт на русском (специально):

“Нарисуй настенные часы с 11-часовым циферблатом, которые показывают без двадцати десять”.

Казалось бы, прошло уже несколько лет “улучшений” и хайп только набирает обороты, но, к сожалению, результат, как обычно, не слишком-то полезный – см. ниже.

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

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

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

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

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

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

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

Кстати, что касается URL (URI), как носителя “секрета”, установленного в составе адреса документа или параметров URL: ещё в 2015 году, десять лет назад, “Яндекс.Браузер” собирал URL, которые посещает пользователь, и отправлял их поисковому роботу “Яндекса”, чтобы тот индексировал контент для всех пользователей поисковой системы (этот подход сильно напоминает теперешнее “обучение ИИ”, кстати). Так что, полагаясь на “секретность” URL (что само по себе очень плохо), браузеры-то как-то неправильно вычёркивать из перечня каналов утечки. Браузер исполняет веб-интерфейс, а не пользователь “на бумажке”, так что URL могут уходить куда угодно именно потому, что это URL.

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

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

Естественно, это возможно только потому, что основание двоичной системы – простое число два. Если взять любое другое простое основание, то 10 тоже будет простым, потому что это и есть запись основания: три – по основанию 3, пять – по основанию 5, семь – 7, и так далее. Но наиболее привычны, кроме десятичной (десятеричной), это двоичная, восьмеричная и шестнадцатеричная.

Возьмём запись 11. В двоичной – это простое число три (11₂ = 2 + 1 = 3). В восьмеричной – девять, составное, но квадрат простого: 3^2. Та же запись 11 означает одиннадцать в десятичной, простое. Шестнадцатеричное 11 – это семнадцать, тоже простое.

Использование в этом ряду двоичной системы ограничивает доступный набор цифр: только 0 и 1. Но можно взять, например, 101 – трёхзначное:
это пять в двоичной (простое);
шестьдесят пять – в восьмеричной, составное: пять на тринадцать;
сто один – в десятичной, простое;
двести пятьдесят семь – в шестнадцатеричной, простое.

Обратите внимание, что запись чисел словами – это инвариантная, относительно системы счисления, запись.

111₂ = семь (простое);
111₈ = семьдесят пять (составное);
111₁₀ = сто одиннадцать (простое);
111₁₆ = двести семьдесят три (составное: 3*7*D).

Не забывая о том, что все простые числа, кроме числа два и числа три, имеют вид 6*n +/- 1, на трёх цифрах можно и остановиться. Тем более, что шестеричная система счисления не является распространённой.

В продолжение записки о том, что появится новый тип УЦ (Удостоверяющих Центров) для выпуска TLS-сертификатов, базирующихся на хеш-деревьях (деревьях Меркла). Речь в этой заметке не про технические детали (про них, возможно, будет отдельно в другой заметке), а про изменение технологических и административных подходов в работе УЦ, которые с новым подходом связаны. Сейчас пока что всё существует в виде тестов и черновиков RFC, но можно ожидать быстрого перехода УЦ на описанную схему. Примерно так же, как было с внедрением обязательных SCT-меток (от логов Cetrificate Transparency) в сертификаты: браузеры начинают верить только в сертификаты с правильными SCT-метками – УЦ для веба вынуждены подстроиться.

Новая схема работы радикально переиначивает логику деятельности УЦ. Дело в том, что полностью меняется фундаментальный процесс: УЦ должны вести собственный лог сертификатов, который становится необходимым источником сертификатов. Да, именно так. Потому что сертификаты, в новой схеме, образуются в результате корректного ведения лога. Это весьма существенное изменение: фактически, то, что сейчас реализуется Certificate Transparency, заносится внутрь УЦ и становится строго первичным, фундаментальным процессом.

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

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

Да, сейчас УЦ должны получать SCT-метки с подписями логов Certificate Transparency (CT), чтобы внести эти метки в сертификат. То есть, процесс выпуска сертификата уже завязан на те или иные CT-логи, что, конечно, делает его похожим на предлагаемый новый вариант. Однако в новом варианте есть целых три существенных отличия:
1) УЦ обязательно ведёт свой лог, который необходим для формирования сертификатов (но это не отменяет других логов);
2) вводится два типа сертификатов, и даже в “полный” сертификат включаются сведения из лога, с подписями нескольких строн, а не просто подпись УЦ на конкретных данных (как сейчас);
3) основной метод оптимизации – сертификаты без подписи, которые содержат только доказательства включения в лог.

И вот главное из этих трёх нововведений – это сертификаты без подписи (“бесподписные”).

Почему весь смысл в сертификатах без подписи? Потому что только такие сертификаты позволяют отказаться от больших подписей криптосистем с постквантовой стойкостью. В этом смысл оптимизации. Да, тут нетрудно заметить ещё один занятный момент: речь про ML-DSA, а там, действительно, подпись занимает несколько килобайтов; казалось бы, и квантовые компьютеры выглядят теоретическим построением, и никто не доказал, что большой размер подписи является необходимым условием постквантовой стойкости – тем не менее, именно многокилобайтные подписи оказываются существенным фактором внедрения сертификатов без подписи и новой схемы работы УЦ. Впрочем, необходимо отметить и то, что схема с хеш-деревьями позволяет существенно экономить трафик уже и для RSA-подписей (с разрядностью 4096 бит и больше).

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

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

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

То есть, в схеме с хеш-деревом и “бесподписными” сертификатами нужно регулярно скачивать обновления хеш-дерева. Заметьте, кстати, что TLS-расширение с поддерживаемым списком – может использоваться для профилирования и распознавания клиентского ПО по составу трафика. Хуже того, если забанят доступ к точкам раздачи обновлений хеш-деревьев, то перестанут работать веб-сайты с “бесподписными” сертификатами, и обойтись отключением “онлайн-проверки” статуса, как в случае с OCSP, уже не выйдет.

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

• Обобщения и квантовая криптография
• Выбор параметров криптосистем и NUMS
• Комплексные числа, отношение порядка и квадратные корни
• Пустое: множество и коробка
• TLS-сертификаты и проверка “по IP-адресу”

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

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

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

В сообщении Google (по ссылке выше) есть ещё интересный момент: там пишут, что к концу этого года ожидают (возможно, в Chrome/Chromium) поддержку X.509-сертификатов с “обычными” “постквантовыми подписями” для непубличных PKI (для УЦ, которые не входят в “коробочный” список доверия браузера). То есть, в браузере может появиться поддержка криптосистем подписи с постквантовой стойкостью в сертификатах. Это довольно занятно, так как позволит использовать такие сертификаты хоть в каких-то браузерах. (Но это ещё нужно посмотреть, что там реально будет.)

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

Перебор – перебором, но LLM-перебор – это совсем не тот перебор, который вполне себе является методом математического доказательства. Например, как метод доказательства, перебор позволяет быстро находить контрпримеры к каким-то утверждениям. Элементарная иллюстрация: допустим, кто-то говорит, что нельзя “квадрат разложить на два квадрата”; это легко опровергнуть, просто “подобрав” самую известную пифагорову тройку: 3^2 + 4^2 = 5^2. Естественно, компьютеры существенно улучшили возможности по перебору: несравнимы возможности современного ПК и даже таких признанных вычислителей, каким был Эйлер. Однако всё это без учёта новомодных LLM, в которых, похоже, вычислительный ресурс в основном расходуется впустую.

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

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

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

“Шёл с косой косой косой”.

Что здесь написано? Например, это сказочный заяц (косой или Косой), который идёт, неся на плече ручной инструмент для покоса травы, но этот инструмент довольно кривой: “коса у зайца на плече косая”.

Теперь допишем ещё одно слово “косой”.

“Шёл с косой косой косой косой”.

Что получилось? Теперь заяц-косой ещё и реально косой – то есть, у него большие проблемы с глазами.

“Шёл с косой косой косой косой косой”.

Заяц, который несёт на плече косую косу, идёт вдоль песчаной косы: спустившись с холма, вышел заяц к реке, да закинул косу на плечо, шагая привычной дорогой – вдоль песчаной косы. Что ж, пока заяц идёт, продолжаем приписывать слово “косой”.

“Шёл с косой косой косой косой косой косой”.

Предположим, что и песчаная коса – тоже косая, на то она и коса. Продолжать всё труднее. Получится ли сделать следующий шаг?

“Шёл с косой косой косой косой косой косой косой”.

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

“Шёл с косой косой косой косой косой косой косой косой”.

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

(Заметьте, кстати, что эффект похож на эмбеддинг с навесом из другой записки.)

Добавил на страницу “Избранное” ещё пять записок:

• Секунды и физика их подсчёта
• Навязывание геолокации и сети приёмников
• Шумерские цифры и древняя система счисления с плавающей точкой
• Пути самурая и абстракция отсутствия цели
• Математика бэкдора в Dual EC DRBG

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

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

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

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

Естественно, нетрудно заметить, что при HTTP-проверке промежуточный узел точно так же может подтвердить право управления и для DNS-имени, перехватив HTTP. Запросы всё равно ведь отправляются по IP-сети. Так что, если промежуточный узел умеет перехватывать HTTP-трафик, адресованный IP-узлу под проверяемым DNS-именем, то схема подмены не будет отличаться. Более того, сертификат по такой схеме будет получен для доменного имени, а это означает, что перехватывать трафик в дальнейшем, используя подменный сертификат, можно уже с другими IP-адресами. Перехват же с “IP-адресным” сертификатом – потребует продолжения подмены/перехвата части IP-маршута. Другое дело, что так как для поиска IP-адреса в случае HTTP-проверки для DNS-имени УЦ должен использовать DNS, то есть слабая надежда на то, что можно воспользоваться дополнительными мерами защиты: например, CAA-записью.

А вот проверка через DNS, то есть, с размещением кода подтверждения в DNS, – отличается. Здесь перехватывать и подменять уже нужно DNS-ответы, а они, скорее всего, проходят через другие промежуточные узлы. В идеале, для доставки кодов подтверждения через DNS используется несколько совсем разных маршрутов. Более того, если используется DNSSEC, то такая подмена DNS вообще не сработает.

Поэтому “проверка по IP”, в каком-то смысле, играет по собственным правилам, иногда оказываясь довольно слабой.