Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
В домене .DE на некоторое время сломались подписи DNSSEC. Сейчас уже пишут, что починили. Возможно, тоже перепутали ключ из-за совпадающих тегов. (Лирическое отступление: в DNSSEC выбрана неудачная система тегирования ключей при помощи 16-битных номеров, которые, понятно, то и дело совпадают для разных ключей; данные теги нельзя использовать в качестве индекса при выборе ключей для подписи, об этом написано в RFC, об этом много писал и говорил я, и не только я, но теги всё равно регулярно используют с такой целью; однако насчёт данного случая с DE – не факт, что в этом была проблема.)
Интересна тут реакция Cloudflare, как оператора одного из самых распространённых в этих интернетах сервиса DNS-резолвинга – 1.1.1.1: в Cloudflare, после локализации ошибки на стороне DE, валидацию DNSSEC для этой зоны просто отключили. Ну, то есть, очередной пример реальной ценности DNSSEC в современой глобальной DNS: если что не так, то систему валидации принято отключать; но, конечно, не просто так отключать, а информированно отключать.
Есть даже RFC 7646, который, кто бы мог подумать, прямо предписывает так делать. Естественно, речь тут идёт об операторах DNS-сервисов, которые могут убедиться, что, мол, “это не атака подмены”, а это DNSSEC сломали сами администраторы ключей, очередной раз. Хотя, строго говоря, достоверно определить, что подписи стали расходиться не из-за атаки, а из-за ошибки – весьма и весьма сложно: атака могла быть на уровне оператора реестра, например. Может ли тут что-то с уверенностью – и, главное, быстро, – сказать внешний наблюдатель, даже если он оператор резолвера? Ну, это вряд ли. Остаётся полагаться на ответы оператора реестра и, что называется, кликать виртуальную универсальную кнопку “Всё равно продолжить” для всех пользователей своего “валидирующего” резолвера. Такая вот нынче стала на практике эта технология – DNSSEC. Ничего не поделать.
Комментировать »
Одним из важных преимуществ современной сотовой связи является то, что это радиосвязь с высокой степенью распределённой автономности. То есть, и базовая станция с автономным питанием, и у всех абонентов тоже – терминалы с автономным питанием: провода не нужны, а в случае критической ситуации все абоненты, находящиеся в зоне доступа данной базовой станции, получают возможность связи, как минимум, между собой (оставим сейчас за скобками всякие контроллеры и авторизацию – здесь речь о критической ситуации и о теории вопроса). Получается, что достаточно поднять базовую станцию, с автономным питанием, а автономные терминалы у абонентов уже есть (это телефонные аппараты с аккумуляторным питанием).
Для старой проводной связи, – которую зачем-то (см. ниже) едва ли не повсеместно изжили, – как минимум, отсутствует мобильность и по связи, и по питанию: нужны провода. Причём, понятно, электропитание-то может быть автономным и на стороне каждого абонента с проводами (“покрутил ручку/поставил батарейку”), но штатная массовая схема, например, в городах, подразумевала независимое питание аппарата со стороны сети связи (со станции или с ближайшего подходящего узла – не важно). То есть, в штатной схеме – “гудок в трубке был и при отключении электричества”. Но привязки к проводам это не отменяет, а восстановление связи – требует восстановления проводов и напряжения в этих проводах, потому что рассчитывать на то, что у абонентов есть автономные аппараты – не приходилось.
Совсем другая история, в теории, с современной мобильной, сотовой связью: достаточно поднять одну точку, – базовую станцию, – чтобы сразу на большой территории вокруг абоненты получили связь (ещё раз: радиотерминалы у них уже есть и работают автономно). Существенное преимущество.
И поэтому всегда удивительно наблюдать, как, – в текущих реалиях, – на базовых станциях систем резервного питания явно не хватает, и всякая мало-мальски масштабная авария сетей обычного электроснабжения (аварии – уже не редкость) тут же приводит к тому, что не только пропадает свет в оптоволокне интернет-канала, заведённого в дом, но в округе и моментально тухнут только что доступные базовые станции GSM/LTE. Хотя – казалось бы. Но нет, это уже практика: времена поменялись – подходы скорректировали.
Comments Off on Радиосвязь GSM и надёжность электроснабжения
Хроники разваливающихся интернетов и проблем с диагностикой разваливания. Понадобилось тут проверить один технологический артефакт в связке 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-записей может и открытый рекурсивный резолвер, не обязательно держать авторитативный сервер: фильтруется оно одинаково.
Комментарии (2) »
Пока что сайт продолжает выходить (под новым именем: dxdt.blog). Отмечу отдельно пять записок, из опубликованных в апреле 2026:
Комментировать »
Кстати, занятно, что TLS-сертификаты и удостоверяющие центры в вебе уже скоро могут перейти на вариант с хеш-деревьями и криптосистемами с постквантовой стойкостью, а в DNSSEC всё ещё будут планировать переход на ECDSA. Я про эту замену в корне DNSSEC писал недавно.
При этом, в прочих областях, – например, в TLS, – переход на постквантовые криптосистемы (ключи и подписи которых в DNS не очень-то хорошо влезают) мотивируется возможностью запуска квантового алгоритма Шора на гипотетическом квантовом компьютере. Однако, если с этой точки зрения, то имеющаяся в корне DNSSEC криптосистема RSA, с практической разрядностью, – заметно более стойкая к квантовому взлому, чем ECDSA, на которую планируют в корне DNS перейти.
Вот тут и возникает “странная дилемма DNSSEC”: ECDSA, без сомнения, вариант прогрессивный, по сравнению с RSA, но против алгоритма Шора – стойкость имеющейся RSA выше (2048 бит против 256), а криптосистемы с постквантовой стойкостью – тут пока и не рассматриваются.
Комментарии (2) »
Сейчас много околотехнических обсуждений по теме методов определения того, пришёл ли веб-клиент на некий крупный веб-сервис “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, например, не видны многие и многие внутренние каналы между операторами, более того, административная принадлежность префикса не позволяет судить о реальных характеристиках сетевой связности вообще никак; однако разные пути доставки тут всё равно образуются, и разное время доставки, наблюдаемое внутри, вполне себе может служить признаком для классификации.
Комментарии (11) »
На dxdt.blog продолжают сыпаться десятки тысяч HTTP-хитов в сутки от ИИ-ботов, в том числе, повторные GET-запросы в течение одних суток на одни и те же URL.
Для особо надоедливых ботов я сделал отдельный HTTP-редирект (302), ведущий на специальную страницу, где с кодом статуса 503 возвращается краткая HTML-заглушка. В некоторых случаях это помогает – бот, во-первых, не идёт по редиректу (ну, это предположительно, судя, так сказать, по косвенным признакам), во-вторых – на какое-то время бот, наткнувшийся на редирект в сторону 503, перестаёт сканировать сайт. Но это именно что в некоторых случаях: многие боты так и продолжают тупо прыгать по редиректам, причём, при каждом соседнем запросе – превращая десятки тысяч GET-запросов в десятки тысяч последовательных редиректов. А если такого бота забанить уже на уровне сетевого стека, то он всё равно продолжает лить сетевые запросы. В целом, очень хорошо заметно, как распространение подобных ботов заливает веб – на dxdt.blog трафик ИИ-ботов, по HTTP-хитам с кодом 200, в десятки раз превысил всё остальное.
Ещё наблюдение по этой же теме: я некоторое время назад сделал на сайте специальную ссылку, которая, как я думаю, не должна использоваться при корректной работе с веб-сайтом, но если пройти по URL из неё, то это моментально приводит к блокированию IP-источника уже на уровне сетевого стека (netfilter в ОС, под которой крутится веб-сервер). Ссылку, по понятным причинам, здесь не указываю, но она есть в robots.txt – объявлена, как закрытая (Disallow), что, конечно, может и привлекать запросы. Однако по этой ссылке – совсем мало кто из ботов попадается: видимо, прямое указание в robots.txt – пока работает в сторону “отключения”.
Комментарии (3) »
На днях я писал о том, что сейчас нетрудно сделать веб-сайт без доменного имени, а прямо под 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-записей) в делегирующей зоне.
Комментарии (2) »
Продолжаю потихоньку закрывать то, что адресуется в .ru, .su: убрал A-запись из nox.su, планирую в ближайшие дни отключить там DNSSEC. (Под nox.su была страничка с описанием DNSSEC и примерами настройки.)
(Update, 24/04/2026: отключил для nox.su DNSSEC, удалил DS-запись из зоны .su.)
Комментировать »
Раньше самолёты (и не только самолёты, конечно) ориентировались по звёздам. Для автоматизации процесса использовались аналоговые вычислители, которые и сейчас-то иногда превосходят цифровые на некоторых задачах, а уж в 60-х годах прошлого века – только такие и могли бы вычислять координаты в режиме онлайн. Подробное и с картинками описание такой аналоговой системы астронавигации, использовавшейся на борту самолёта B-52, – по ссылке (англ. много букв).
На этой иллюстрации из статьи – аналоговый вычислитель, выполнявший преобразование углов.
(via)
Комментировать »
Новый 