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

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

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

Кстати, по этой теме ещё модно говорить, что для LLM уровня Mythos (что бы это ни значило), типа, нет разницы, на каком языке подан код программы (а машинные коды – это тоже язык, не забывайте). Это, конечно, не так: подобные системы сами никаких уязвимостей не находят, но могут генерировать вывод, который совпадает с описанием уязвимости (или не совпадает). Это хорошо подтверждается тем, что уровень качества “исправлений”, сгенерированных той же LLM, ниже уровня “обнаружения” (должно быть наоборот, если уязвимость находит реальный интеллект). То же, кстати, видно и в “решении” математических задач LLM: генератор текста – он и есть генератор текста.

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

Хотя – хайп. Хайп не все хотят пропустить.

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

Интересна тут реакция Cloudflare, как оператора одного из самых распространённых в этих интернетах сервиса DNS-резолвинга – 1.1.1.1: в Cloudflare, после локализации ошибки на стороне DE, валидацию DNSSEC для этой зоны просто отключили. Ну, то есть, очередной пример реальной ценности DNSSEC в современой глобальной DNS: если что не так, то систему валидации принято отключать; но, конечно, не просто так отключать, а информированно отключать.

Есть даже RFC 7646, который, кто бы мог подумать, прямо предписывает так делать. Естественно, речь тут идёт об операторах DNS-сервисов, которые могут убедиться, что, мол, “это не атака подмены”, а это DNSSEC сломали сами администраторы ключей, очередной раз. Хотя, строго говоря, достоверно определить, что подписи стали расходиться не из-за атаки, а из-за ошибки – весьма и весьма сложно: атака могла быть на уровне оператора реестра, например. Может ли тут что-то с уверенностью – и, главное, быстро, – сказать внешний наблюдатель, даже если он оператор резолвера? Ну, это вряд ли. Остаётся полагаться на ответы оператора реестра и, что называется, кликать виртуальную универсальную кнопку “Всё равно продолжить” для всех пользователей своего “валидирующего” резолвера. Такая вот нынче стала на практике эта технология – DNSSEC. Ничего не поделать.

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

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

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

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

Хроники разваливающихся интернетов и проблем с диагностикой разваливания. Понадобилось тут проверить один технологический артефакт в связке DNS+TLS, для чего я поднял виртуальный сервер у одного из провайдеров (не буду назвать, это не важно) и установил там BIND в качестве авторитативного DNS-сервера для тестовой зоны. И вот – BIND работает, а TXT-записи, в ответ на DNS-запросы снаружи, не приходят. Локально, на том же хосте, – приходят ответы TXT. С другими запросами – SOA, NS – всё хорошо, ответы приходят и наружу. TXT – не приходит. Но не приходит – по UDP. А зато по TCP – приходит.

Собственно, тут-то и нетрудно было догадаться, что это, видимо, какой-то фильтр где-то на промежуточном узле. Просмотр дампов трафика гипотезу подтвердил: на машину с DNS-сервером внешние DNS-запросы в UDP приходят, а ответы – уходят. Но вот дальше – проходят только ответы не с TXT. Выяснение этого, конечно, заняло какое-то время – изначально выглядело так, как если бы что-то сломалось в BIND.

Видимо, так вот решили “гибко” (может, даже с новомодным ИИ) побороться с источниками DoS-атак: широко известно, что TXT-записи являются носителем трафика для DoS-атак, так как эти записи могут содержать большой объём данных, а если “подспуфить” UDP, подставив чужой адрес, то большие пакеты поедут в сторону этого, чужого, адреса. Другие типы записей – обычно не считаются носителями трафика для DoS.

Да, строго говоря, фильтровать-то нужно по “подспуфленным” UDP, а не по единственному признаку TXT – подобная грубая фильтрация DNS-ответов приводит к тому, что в такой сети невозможно держать авторитативный NS: без TXT сейчас никуда – и почта их использует, и валидация при выпуске TLS-сертификатов. Зато получилась очередная практическая демонстрация того, как эти интернеты становятся непрозрачными даже не только на уровне протоколов, но на уровне некоторой “внутрипротокольной” семантики. Да, конечно, такая вот, – типа, “гибкая и интеллектуальная”, – фильтрация была и раньше, в том числе, по DNS-ответам. Это просто свежий практический пример.

Кстати, хотя есть и другие варианты DNS-записей, которые могут содержать большие объёмы ответов – см. DNSSEC, например, – но с TXT – проблема более чем известная: в зонах бывает много TXT, скажем, в google.com сейчас 13 записей почти на килобайт, и это – ещё совсем не много; кроме того, что-то ещё и забывают почистить, так что записи накапливаются. Естественно, извлекать откуда-то из целевой зоны толстый набор TXT-записей может и открытый рекурсивный резолвер, не обязательно держать авторитативный сервер: фильтруется оно одинаково.

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

При этом, в прочих областях, – например, в TLS, – переход на постквантовые криптосистемы (ключи и подписи которых в DNS не очень-то хорошо влезают) мотивируется возможностью запуска квантового алгоритма Шора на гипотетическом квантовом компьютере. Однако, если с этой точки зрения, то имеющаяся в корне DNSSEC криптосистема RSA, с практической разрядностью, – заметно более стойкая к квантовому взлому, чем ECDSA, на которую планируют в корне DNS перейти.

Вот тут и возникает “странная дилемма DNSSEC”: ECDSA, без сомнения, вариант прогрессивный, по сравнению с RSA, но против алгоритма Шора – стойкость имеющейся RSA выше (2048 бит против 256), а криптосистемы с постквантовой стойкостью – тут пока и не рассматриваются.

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

Момент первый: измерение параметров времени для TCP-соединения. Например, к некоторому веб-сервису подключается клиент, скажем, браузер. При помощи выполнения некоторых скриптов не очень трудно померить время “сетевой задержки” между средой веб-страниц этого браузера и серверной средой. То есть, это будет время доставки запроса, измеренное от контекста DOM в браузере до веб-сервера. Предположим, это 50 ms. Но это всё по HTTP, а HTTP-соединение использует TCP.

TCP-соединение устанавливается не с браузером, а с логически ближайшим к серверному сетевому стеку узлом. Это может быть клиентский компьютер, то есть, ОС на этом компьютере. Но может быть и выходной узел, выполняющий трансляцию адресов, например. Обычно – именно так и есть: клиентский компьютер редко стоит прямо за маршрутизируемым IP-адресом. Тогда, если измерять и задержку в браузере, и задержку на серверном TCP, то получится, скажем, что, в рамках одной логической HTTP-сессии, TCP-задержка – 10 ms, а браузерная задержка, до DOM в HTTP-клиенте, – 50 ms. Большая разница – 40 ms. Это означает, что от клиента транслированные запросы ещё где-то там внутри долго ходят, пока доберутся до выходного узла, который к нам по TCP подключился.

Если же выходной TCP-узел примерно совпадает с логическим узлом, где работает клиентский браузер, то разница между двумя задержками будет минимальной, например: 10 ms TCP и 11 ms – браузерная задержка, читай – Javascript в DOM-контексте. Здесь под “примерно совпадает” имеется в виду, что между клиентским компьютером и выходным узлом нет большого сетевого плеча: компьютер и выходной узел стоят технически рядом (простейший случай: локальный пограничный “роутер” с NAT и подключенный к этому “роутеру” по локальному порту компьютер в локальной IP-сети над Ethernet-ом).

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

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

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

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

Сюда же попадает и повсеместная путаница, связанная с распределением блоков IP-адресов (префиксов). У всякого IP-префикса есть администратор – автономная система (AS). Это верно. Но ещё есть маршрутизация и BGP. И вот в рамках BGP, технически, быть источником (origin) для данного IP-префикса может любая (подчёркиваю: технически – любая, даже с тестовым номером) автономная система. То есть, административно, префикс принадлежит одной AS, но анонсирует его в Интернет – совсем другая. Или даже несколько других AS – в зависимости от того, какой оператор из какой точки сети смотрит на BGP. Да, для штатного анонсирования префикса должно быть разрешение от его администратора, сейчас это даже подтверждается в RPKI. Да, конкретная ситуация с приёмом IP-пакетов зависит от фильтров, настроенных оператором. Но это только подчёркивает то, что одно дело – административная принадлежность, другое – BGP и маршрутизация в реальности.

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

На днях я писал о том, что сейчас нетрудно сделать веб-сайт без доменного имени, а прямо под IP-адресом (v4), но с доверенным HTTPS для коробочного браузера. В качестве примера – сделал точно такой веб-сайт, с сертификатом от Let’s Encrypt: https://185.39.19.199/ – можно зайти браузером и убедиться, что всё работает. Надо заметить, что TLS-сертификаты для IP-адресов можно было получать в доверенных, хорошо известных УЦ и раньше, это, конечно, не в Let’s Encrypt придумали – но вот только раньше выпуск такого сертификата был сопряжён с существенными дополнительными административными трудностями, а Let’s Encrypt позволяет этих трудностей избежать совсем.

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

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            06:7e:8d:e7:b0:8a:13:8c:23:da:d4:f1:43:e6:de:24:02:f6
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = YE1
        Validity
            Not Before: Apr 26 13:18:14 2026 GMT
            Not After : May  3 05:18:13 2026 GMT
        Subject: 

Здесь указаны самые, наверное, очевидные поля: версия формата (3 – сейчас это типовой вариант); серийный номер; алгоритм подписи – ECDSA, см. ниже; название подписавшего сертификат УЦ (Issuer); период валидности.

Обратите внимание – в сертификате отсутствует поле Subject. Это весьма важный момент, довольно свежий. Сейчас в TLS-сертификатах (для веба) в качестве носителя имён и адресов TLS-узла выступает другое поле – SAN (Subject Alternative Name). Поле Subject может присутствовать в сертификате, но, например, браузеры имена из этого поля игнорируют, если нет соотвествующего имени в SAN. В случае же этого сертификата от Let’s Encrypt, как мы видим, нет самого содержимого поля Subject. Это, в частности, означает, что если в каких-то скриптах (скажем, для мониторинга) это поле используется для определения принадлежности сертификата, то с современными TLS-сертификатами (для веба) скрипт правильно работать не будет. Такие скрипты нужно обновлять – см. ниже.

Вот типичный пример вызова OpenSSL в shell-скрипте, который пытается проверить имя в сертификате по Subject:

openssl x509 -in 185-39-19-199.pem -subject -noout -nameopt multiline \
| awk -F' = ' '/commonName/ {print $2}'

Для старого формата сертификатов (например, как сейчас установлен на dxdt.blog) – этот вызов выведет имя из поля “commonName” в Subject, то есть, для dxdt.blog – напечатает dxdt.blog. Однако в случае с новыми сертификатами – фрагмент не напечатает ничего, но, при этом, обработанный сертификат будет валидным и вполне себе корректным. То есть, полагаться на Subject больше нельзя – нужно заменять вызовы утилит на обработку поля SAN. Это несколько сложнее, но вполне реализуемо.

Для извлечения имён из SAN при помощи OpenSSL (утилита x509) нужно указать опцию -ext subjectAltName. Выдача openssl x509 в этом случае состоит из списка, где тип элемента обозначен префиксом. DNS-имена OpenSSL выводит с префиксом “DNS”, а IP-адреса – “IP address” (это будет полезно для нашего сертификата). Пример:

openssl x509 -in 185-39-19-199.pem -noout -ext subjectAltName

Результат:

X509v3 Subject Alternative Name: critical
    DNS:185.39.19.199.zone, IP Address:185.39.19.199

Скрипт, понятно, усложняется – нужно парсить префиксы полей. Пример скриптового вызова с awk, для извлечения DNS-имени:

openssl x509 -in 185-39-19-199.pem -noout -ext subjectAltName \
| awk 'NR>1{split($0,A,",");for(k in A){split(A[k],B,":"); \
if(B[1]~/DNS/){print B[2]}}}'

Результат:

185.39.19.199.zone

Обратите внимание: 185.39.19.199.zone – это хостнейм, доменное имя, пусть оно и похоже на IP-адрес. Да, в данном сертификате присутствует и DNS-имя, и IP-адрес – это делает сертификат хорошим примером. В принципе, сервер доступен и под доменным адресом 185.39.19.199.zone, но основным мы тут считаем IP-адрес. Для выпуска сертификата на IP-адрес не требуется указание доменного имени. Но если имя нужно включить в сертификат, то это нетрдуно сделать при помощи того же certbot – просто указываем при вызове и доменное имя, и IP-адрес:

certbot certonly --preferred-profile shortlived \
-d 185.39.19.199.zone \
--ip-address 185.39.19.199 \
--webroot --webroot-path /var/www/html/

Вернёмся к распечатке исходного сертификата. Предыдущий блок закончился на пустом Subject. Смотрим дальше:

        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:ea:98:84:aa:0e:d5:2b:0f:5a:00:6b:bc:17:df:
                    33:91:86:e5:f8:b6:cb:e8:f0:7b:48:f0:5f:bf:8c:
                    04:57:9e:7f:ee:66:a8:09:7a:31:f3:11:d5:2f:90:
                    67:01:af:04:cc:45:52:56:5d:18:73:bf:1c:d5:6d:
                    f9:f7:44:6e:5d
                ASN1 OID: prime256v1
                NIST CURVE: P-256

Это открытый ключ. В сертификате указан открытый ключ для ECDSA на кривой P-256. Это, опять же, типовой сейчас вариант, ничего необычного.

        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier: 
                BB:20:CA:47:0B:FE:D7:E5:9C:F9:8F:09:2A:A3:8C:37:45:B1:BC:D8
            Authority Information Access: 
                CA Issuers - URI:http://ye1.i.lencr.org/

Далее идут так называемые “расширения” (extensions). Key Usage и Extended Key Usage – обозначают допустимое использование открытого ключа из сертификата. Сейчас, в случае TLS-сертификатов для веба, перечень флагов, указываемых в этих полях Удостоверяющим Центром (УЦ), сильно сократили: здесь есть только Digital Signature (цифровая подпись) в основном поле Key Usage и TLS Web Server Authentication (аутентификация TLS-сервера для веба) – в дополнительном Extended Key Usage. И всё – это, опять же, нововведение: тут нт ни клиентской аутентификации, ни “шифрования ключа” или “ключевого обмена”, ни чего-то ещё подобного.

CA:FALSE в Basic Constraints – ключ из сертификата не может быть использован в качестве доверенного для проверки подписи на других сертификатах (это если строго; простыми словами говорят, что “это не сертификат ключа УЦ”).

Authority Key Identifier – идентификатор ключа для проверки подписи; это, вообще говоря, историческое поле, которое предназначено для “быстрого поиска” ключа проверки подписи на сертификате, но, понятно, без самого ключа не имеет смысла.

Authority Information Access – указание на точки раздачи файлов с информацией об удостоверяющем центре. В данном случае, указана только точка раздачи по HTTP сертификата ключа УЦ – CA Issuers.

Далее идёт поле SAN, с именами и адресами, которое мы упоминали выше:

            X509v3 Subject Alternative Name: critical
                DNS:185.39.19.199.zone, IP Address:185.39.19.199

Указано одно доменное имя (DNS) и один IP-адрес (IP Address). Ещё раз напомню, что могли быть и только IP-адреса, причём, разных версий – v4, v6. Современные барузеры в процессе валидации сопоставляют имена или адреса из поля SAN, не из Subject. Например, при подключении по IP-адресу 185.39.19.199, браузер проверит, что в TLS-сертификате указан именно этот адрес в поле SAN.

Интересен вопрос контекста: что использует браузер – IP-адрес или доменное имя? В сертификате могут быть указаны оба этих артефакта, но браузер при валидации использует тот, который пользователь ввёл при вызове. То есть, если обращение по имени хоста, то сранивается имя хоста, если по IP-адресу напрямую, то сравнивается IP-адрес. Понятно, что почти всякое HTTP-обращение, в стетевом смысле, производится по IP-адресу. Я как-то (https://dxdt.blog/2025/04/15/15391/) писал о том, что, в теории, для случая хостнейма, тоже можно использовать и IP-адреса из сертификата, в качестве дополнительного фактора – совпал и домен, и IP-адрес. Но в современной практике веба это, скорее, излишняя перестарховка, сопряжённая с техническими сложностями, к тому же.

            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://ye1.c.lencr.org/119.crl

Политики (Policies) – тут просто указан идентификатор политики УЦ, в рамках которой проводилась проверка права управления ресурсом (адресом, именем) и выпускался сертификат. Политики – это больше административный момент. Но, например, именно идентификатором политики определяются так называемые EV-сертификаты (Extended Validation), которые сейчас почти что утратили актуальность.

X509v3 CRL Distribution Points – точка раздачи CRL – списка отозванных сертификатов. В данном сертификате есть механизм проверки отзыва – это CRL. В принципе, для короткоживущих сертификатов от механизма отзыва собираются вообще отказаться, но тут адрес CRL все же указан (отчасти, потому что это сертификат для IP-адреса).

Хвост сертификата, с сокращениями:

            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : E3:23:8D:F2:8D:A2:88:E0:AA:E0:AC:F0:FA:90:C9:85:
                                F0:B6:BF:F5:D2:A5:27:B0:01:FC:1C:44:58:C4:B6:E8
                    Timestamp : Apr 26 14:16:45.523 2026 GMT
                    Extensions: 00:00:05:00:36:66:ED:17
                    Signature : ecdsa-with-SHA256
[...]
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : D1:6E:A9:A5:68:07:7E:66:35:A0:3F:37:A5:DD:BC:03:
                                A5:3C:41:12:14:D4:88:18:F5:E9:31:B3:23:CB:95:04
                    Timestamp : Apr 26 14:16:45.489 2026 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
[...]
    Signature Algorithm: ecdsa-with-SHA384
    Signature Value:
[...]

CT Precertificate SCTs – это подписанные метки времени, полученные для этого сертификата от операторов логов Certificate Transparency.

Далее – повторное указание на тип подписи в сертификате (ecdsa-with-SHA384). Это тип криптосистемы цифровой подписи, использованной УЦ. Тот же идентификатор уже встречался в начале сертификата – так сложилось исторически: идентификатор указывается в двух местах, хотя точно хватило бы и одного, в конце, где приводится сама подпись – Signature Value.

Кстати, в продолжение предыдущей записки: в какой последовательности нужно отключать DNSSEC-записи? Прежде всего – нужно удалять DS-записи из вышестоящей зоны. Дело в том, что именно DS-запись, которая содержит отпечаток ключа, говорит валидирующим резолверам о том, что данная зона “делегирована безопасно”.

Это самый важный момент: делегирующие ответы, с NS-записями, в DNSSEC не подписываются – в этом нет никакого смысла, потому что доверие в DNSSEC формируется по цепочке ключей, а не по адресам/именам серверов. (Собственно, как и во всякой подобной криптографической схеме.) Поэтому подписываются в DNSSEC записи, указывающие на ключи. В случае делегирующего ответа – это DS-запись. Более того, так как необходимо обеспечить криптографическое удостоверение факта отсутствия DS-записи для заданного имени, удостоверяется и то, что конкретной, по имени, DS-записи нет.

Теперь перейдём к процессу отключения DNSSEC. Речь, естественно, о полноценной поддержке, когда DS-записи присутствуют по всей цепочке до корня DNS. Так вот, самая распространённая ошибка – удаление DNSSEC-записей в самой, целевой зоне, без удаления DS-записей в делегирующей зоне. Так делать нельзя потому, что, с точки зрения валидирующего резолвера, тут же развалится доверенное делегирование. Возникает вот какая конфигурация: в ходе рекурсивного опроса резолвер получает DS-запись из делегирующей зоны, и параметры этой записи удостоверены DNSSEC-подписями из делегирующей зоны (по всей цепочке делегирования); однако из целевой зоны резолвер не может получить соответствующего ключа DNSSEC (в DNSKEY-записи), поэтому резолвер определяет, что DNSSEC-цепочка нарушена и возвращает ошибку валидации адресной информации – зона перестаёт работать. При этом, для невалидирующего резолвера, всё “работает” – ведь такой резолвер ничего не знает ни про DS-записи, ни про DNSKEY, ни про подписи (RRSIG). Поскольку сейчас распространённые сервисы DNS-резолвинга валидируют DNSSEC, – например, так делают 1.1.1.1 и Google Public DNS, – то и зона, для которой “повисла DS-запись”, отваливается для многих и многих пользователей.

Поэтому, прежде чем удалять поддержку DNSSEC непосредственно в зоне, нужно удалить DS-запись из делегирующей зоны. Например, в случае example.net – это будет DS-запись в зоне .net. После успешного удаления – нужно подождать какой-то разумно-максимальный срок TTL. Скажем, сутки.

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

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

Благодаря влиянию ACME и Let’s Encrypt, сейчас стала очень популярной схема подтверждения права управления доменом (DCV) через DNS, но при помощи размещения CNAME-записей. Речь про запрос TLS-сертификатов средствами автоматизации – скриптами (acme.sh, certbot и др.). Напомню, что DCV здесь состоит в проверке размещения TXT-записи с кодом подтверждения под заданным именем в DNS-зоне (это метод DNS-01). ACME использует специальный префикс: _acme-challenge.

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

Момент первый: постоянно путают синоним (алиас) и основное имя в CNAME. Дело в том, что CNAME – это Canonical NAME (каноническое имя), и каноническим является именно значение записи, а не имя-носитель. Имя-носитель – это и есть алиас, что бы там ни писали в инструкциях к средствам автоматизации ACME. Если для example.com в CNAME-записи указано 1.2.3mega-blah-blah.example.net, то вот это вот 1.2.3mega-blah-blah.example.net и есть основное имя. При использовании в ACME предлагается настроить CNAME для префикса _acme-challenge. Например, _acme-challenge.example.com в 1.2.3mega-blah-blah.example.net. Но и тут алиасом, в терминах DNS, будет _acme-challenge.example.com, префикс не влияет на отношение значений записей. Такова семантика CNAME.

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

Естественно, можно рассуждать иначе: если утрачено каноническое имя, то нужно удалить CNAME-запись в алиасе; тем более, что так как сертификаты сейчас “короткие”, утрата канонического имени обнаружится быстро. Это верно. Более того, имея контроль над исходной зоной (в которой CNAME) – можно будет попробовать отозвать сертификаты для этой зоны, если такие были выпущены при помощи подхвата CNAME. (Один из штатных способов отзыва сертификата в ACME – прохождение DCV для имён из сертификата; но нужно предъявить сам сертификат, и должно всё сойтись по составу имён – то есть, если в подставном сертификате указана ещё какая-то зона, то могут быть проблемы с отзывом.) Однако это всё только теоретические рассуждения, в стиле “как должно быть”, а на практике, как говорится: ну, на практике-то – и про CNAME-зоны забывают, и про обновление имён, и про отзыв.

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

Кстати, тут полезно вспомнить, что есть и суперновая версия DNS-проверки в ACME – с “постоянной” привязкой ACME-аккаунта к имени: вот где совсем не место CNAME (но черновик RFC пока что их не запрещает явно).

CNAME-записи – одни из самых сложных по поведению в DNS, а их использование – источник неожиданных проблем. В случае DCV, семантика и принципы интерпретации CNAME вообще противоречат основной логике проверки права управления через DNS. Что касается других решений: во-первых, ACME-префикс можно делегировать на отдельные NS, без всяких CNAME; во-вторых, для размещения TXT-записей вовсе не обязательно передавать полные права управления DNS-зоной каким-то скриптам. Это всё решения на стороне, заказывающей DCV. Но самое правильное, конечно, это не следовать CNAME при проверке DCV на стороне систем УЦ.

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

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

Самое интересное в озвученных планах, что на середину 2027 года (следующий год) запланирована защита постквантовыми криптосистемами цепочки аутентификации для подключающихся клиентов – это, как указано, сертификаты на хеш-деревьях (с ML-DSA, скорее всего). (MID 2027: PQ authentication support for visitor → Cloudflare connections using Merkle Tree Certificates.)

В Google недавно намекали на то, что поддержка постквантовых криптосистем подписи для TLS и X.509-сертификатов появится в Chrome/Chromium уже к концу 2026 года. И в это можно поверить, потому что сами технические средства в виде программного кода и описаний структур – довольно давно готовы, а полная реализация имеющимися средствами конкретно для TLS-сертификатов неоднократно продемонстрирована на практике.

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

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

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

Да, нужна поддержка на стороне обычных серверов, в виде утилит для выпуска ключей и запросов на сертификаты всеми желающими. То есть, обычный сейчас вариант с ECDSA или RSA – не подходит: эти криптосистемы не обладают постквантовой стойкостью, теряется смысл даже в том случае, если УЦ подписывает постквантовой криптосистемой. Вручную же ключи генерировать могут не все, а тем более – использовать в веб-сервере. Нужны автоматические утилиты. Однако, распространение ACME-автоматизации – certbot и пр. – позволяет процесс автоматизировать и тут, сведя весь переход к обновлению версий системных библиотек и скриптов для заказа сертификатов через ACME. И веб-сервер придётся обновить, конечно.

В общем, не выглядит неральным, но посмотрим.

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

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

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

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