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

Ещё немного о разных занятных исторических артефактах. В этом году исполнилось 55 лет с момента децимализации денежной системы Великобритании: 15 февраля 1971 года пенсы сменили новые пенсы, каждый из которых был в 2.4 раза дороже. Децимализация – это переход на десятеричную систему счёта денежных знаков: в фунте стало 100 новых пенсов. С этим процессом прямо связано исчезновение из обращения шиллингов – я публиковал об этом отдельную большую статью с картинками.

Но у нас есть ещё один артефакт по этой теме, который в ту статью не попал, однако фотографиями я поделюсь.

Это специальный набор монет Britain’s First Decimal Coins, официально выпущенный для ознакомления жителей Великобритании с новой системой – с десятеричными монетами. Это такая небольшая книжечка-раскладушка, в которой слева вложена картонная табличка с описанием того, что же именно происходит, а справа – картонная же вставка с набором подлинных монет – новых пенсов: в полпенни, один пенни, два пенса, пять пенсов и десять пенсов. Выглядит артефакт вот как.

Обложка:

Раскрытая книжечка:

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

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

Различные даты ввода в обращение, в том числе, планируемый 1971 год, – видны на самих монетах, см. увеличенный фрагмент ниже.

Надо заметить, что так как десятеричная система здесь относилась непосредственно к деньгам, в том числе, к наличным, она, так или иначе, прижилась, несмотря на различные конфликты и недовольство.

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

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

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

Только что описанная схема касается DV-сертификатов – сертификатов с проверкой права управления доменным именем (Domain Validation). Заметьте, тут даже не было важно, что заявитель является администратором доменной зоны с точки зрения соответствующего реестра: если проверка происходит при помощи размещения подтверждающего кода, то достаточно иметь возможность размещения кода, чтобы получить сертификат. То есть, для DNS-проверки, DV-сертификаты может выпускать оператор авторитативных серверов имён. Этот момент, исторически, практически никого не смущает: например, крупные провайдеры CDN спокойно себе выпускают TLS-сертификаты для доменов своих клиентов, а клиенты, являющиеся администраторами доменного имени, даже и знать-то об этом не хотят.

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

Формально, DV-сертификаты могли бы сохраняться. Однако вот уже и Let’s Encrypt, – который УЦ для DV-сертификатов, прежде всего, – вносит в правила пользования очень широкие запреты для подсанкционных территорий и организаций: там, как бы, нет запрета на прохождение валидации имени или адреса, но запрещено вообще пользоваться ACME-сервисами для заказа сертификатов, что, понятно, отменяет и валидацию – если она и прошла, то всё равно были нарушены правила предоставления сервиса.

Так что, похоже, имя – ещё не отбирают, а сертификат для имени – уже отбирают. Хотя, технически, DV-валидация – вообще никак не касается административной части. И УЦ, по старой наивной логике, должен бы проверять, что заявитель управляет DNS-зоной, но не более того.

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

Буквально. Насаждаемая наивная трактовка сильно замылила современную роль сертификата; в реальности, браузер спрашивает: “Можно ли подключиться к сайту под данным именем?”, а УЦ, при помощи подписи на сертификате, отвечает: “Да, пока что можно, но уточни ещё статус разрешения позже”. Или, если действующего сертификата с валидной подписью нет, то это означает, что УЦ ответил: “Нет, подключаться не следует”.

Да, использование криптографических механизмов позволяет тут передать ответ УЦ через сам веб-узел, к которому подключается браузер. Но это как раз технические детали. И если рассматривать процесс с точки зрения разрешений, то уже и “санкционная схема” начинает работать так, как планировалось.

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

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

Ну а уж стоп-листы есть сейчас самые разные: расставленные по ту и другую сторону, заметные и не очень, применяемые для IP-адресов и для сетевых имён, для протоколов, в разных сетях, на разных уровнях – это, думаю, уже все в интернетах замечают, особенно, когда почти ничего не работает. Что уж тут удивляться про “проверку организации” УЦ. Другое дело, что данный аспект, даже если его трактовать максимально строго, не относится к DV-сертификатам, в которых организаций, – кроме УЦ, – просто нет. Впрочем, эти наивные технические детали сейчас мало кого беспокоят.

Ещё занятный пример особенностей, связанных со “сверхкороткими” TLS-сертификатами. Я недавно перевёл dxdt.blog на такие сертификаты Let’s Encrypt – они имеют интервал валидности чуть больше шести с половиной суток (если более строго, то 160 часов). То есть, это “шестидневные сертификаты”. Обновляется сертификат автоматом, каждые двое суток – это разумно, потому что, если что-то пошло не так, хотелось бы иметь хотя бы пару дней в запасе, чтобы обнаружить и разобрать это “не так” (но заметьте, кстати, как сильно это всё раздувает логи Certificate Transparency – теперь за тот же период, за который раньше dxdt.blog расходовал максимум два сертификата, выпускается больше сорока сертификатов!).

Теперь вторая часть: на Timeweb недавно запустили простой мониторинг, который, в том числе, может мониторить “окончание действия” сертификата на сервере. Ну, допустим – и вот я включил этот мониторинг для dxdt.blog. В результате: после каждого обновления сертификата этот мониторинг присылает сообщение почтой: “SSL-сертификат истекает через 7 дней”. Как бы, это почти что формально верно (ну, кроме “семь дней” – не семь там дней; а для всего, что связано с прикладной криптографией, понимание сроков действия – очень важно).

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

Такой вот аспект применения “сверхкоротких” сертификатов. Мониторинг тот пришлось отключить.

Кстати, а вот попалась мне монета в один бермудский доллар, в форме треугольника Рёло – фигуры с постоянной шириной: получается Бермудский треугольник Рёло.
На аверсе – портрет королевы Елизаветы II:

На реверсе – крушение корабля Sea Venture (как раз в Бермудском треугольнике):

(Фоном тут служит купюра в сто советских рублей, не обращайте внимания – к доллару с королевой купюра отношения не имеет.)

Перевёл, в соответствии с современными тенденциями, dxdt.blog на “короткие” TLS-сертификаты Let’s Encrypt, со сроком действия шесть дней (плюс-минус). Но секретный ключ пока оставил специально подобранный. Посмотрим, как оно будет работать.

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

Удостоверяющий центр разрешает пользователям подключаться к “доверенным веб-сайтам” при помощи выдачи этим сайтам токенов доступа. И вот в качестве носителя этих токенов – служат TLS-сертификаты. Так исторически сложилось. Эти сертификаты, строго говоря, надо называть X.509-сертификатами, которые разработали для телеграфа, но тут и дальше – пусть уж будут TLS-сертификаты. Так что запрет доступа здесь – это не запрет доступа к сертификатам, как к артефакту, а запрет доступа к механизмам получения подписи. Это важный момент, понимание которого может позволить уловить и линию приложения блокировок.

TLS-сертификаты, сами по себе, не имеют никакого отношения к базовым механизмам работы Интернета. Да, TLS-сертификаты сейчас используются повсеместно, в том числе, в процессах обеспечения работы Интернета, как межсетевой структуры. Но не в самих базовых протоколах. Например, TLS-сертификаты служат для авторизации в системах VPN, для авторизации в различных панелях управления (не обязательно, что и через веб) и т.д. TLS-сертификат можно выпустить самостоятельно, для произвольного имени. Можно даже устроить аутентификацию по отпечаткам ключей из сертификатов, минуя вообще всякие УЦ. Другое дело, что это не будет работать в “коробочной” среде, для веб-браузера и веб-сайта.

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

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

Этот уровень приложений, как ни странно, очень технологичен. Но речь тут вовсе не про “используй фреймворк “Имярек”, чтобы лучше адаптировать агентов типа John Doe”. Нет. “Фреймворк и агенты” – это технологии, но не технологичность. Технологичность скрывается за процессом контроля над способом применения технологий. Если на примере инфраструктуры УЦ: сейчас кругом только и слышно, что про ACME и его использование – это про протокол автоматического заказа и получения TLS-сертификатов. Но реально ли речь всегда идёт о протоколе? Оказывается, нет. ACME – весьма заумный и развесистый протокол. Мало кто читал спецификацию, мало кто его понимает. Оказывается, что в большинстве случаев использовать хотят не протокол, а некий готовый продукт, популярную утилиту или библиотеку на основе ACME. Например, хотят не ACME, а чтобы работали certbot или acme.sh, а также и какой-нибудь ещё фреймворк. Вот эта зависимость – и есть технологичность, а не просто технологии.

Да, отдельные TLS-сертификаты для веб-сервера нетрудно выпускать самостоятельно, используя готовую библиотеку или утилиту. Гораздо сложнее сделать УЦ, который должен проверять, что заявленное имя сооотвествует предоставленному открытому ключу. И ещё сложнее сделать такой УЦ не на базе “готовых скриптов”. И тем более непросто реализовать валидацию сертификатов в веб-браузере, чтобы соблюсти все типовые условия. А ведь именно связка “браузер-УЦ” тут и работает в качестве линии приложения блокировок, вовсе не TLS-сертификат.

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

Использование хеш-деревьев в TLS-инфраструктуре веба, в TLS-сертификатах, обусловлено переходом на постквантовые криптосистемы цифровой подписи. Тоже хороший пример. Возможно, что в некоторый момент ведущие разработчики браузеров скажут, что браузеры больше не считают стойкими и надёжными сертификаты, выпущенные без постквантовой криптосистемы, а соответствующие веб-сайты – будут отображаться “как небезопасные”. Сложно ли такое представить? Конечно нет. Это вполне логично – устаревшие технологии в какой-то момент оказываются слабыми, браузер должен их блокировать тоже – какие могут быть возражения? Такое уже несколько раз происходило, и с DSA, и с SHA-1, и с длительностью действия сертификатов, и так далее, и тому подобное.

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

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

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

В продолжение предыдущей записки, про dns.1d.pw. Вот как серверы данной зоны видны со стороны сервиса проверки – есть DNS over TLS на всех узлах:

Сделал специальный сервис для DNS – dns.1d.pw. Не торопитесь кликать – там нет A-записи, это именно что DNS-сервис, но он полезен для отладки и поиска причин возникновения проблем. Смысл вот в чём: если спросить в DNS TXT-запись для dns.1d.pw, то в ответ вернётся информация о том, как виден со стороны авторитативного сервера DNS-резолвер, который выполнил DNS-запрос. Вот простейший пример (здесь и далее используется утилита dig из пакета BIND):

$ dig dns.1d.pw -t TXT +short
"ns: dns-b"
"transport: UDP"
"src: [2a04:e4c0:10::145]:63761"
"target [id]: dns.1d.pw. [34301]"

Спрашивать нужно именно TXT: с A-записью – не получится. Кроме TXT – поддерживается только минимум: SOA и NS.

Ответ состоит из нескольких TXT-записей. Выясним, – пока кратко, – что в них видно (по порядку сверху вниз, как в примере):
внутренне имя авторитативного сервера, который обработал запрос (dns-b);
транспорт (UDP), по которому сервер получил запрос и ответил резолверу (то есть, не вашему клиенту, а именно резолверу);
IP-адрес узла, приславшего запрос, и номер порта ([2a04:e4c0:10::145]:63761); Здесь IPv6-адрес – сервис, естественно, поддерживает IPv6 тоже;
целевое имя, как его было видно в DNS-запросе, и код ID DNS-сообщения (dns.1d.pw. [34301]); дальше я объясню, почему это важно, хотя, казалось бы, имя и так известно.

И это не все параметры, которые присылает данный сервис.

Подобные сервисы существуют, и достаточно давно. Например, есть “очки” от Google: o-o.myaddr.google.com – показывает адрес резолвера и состав ECS, есть “пробник” от Akamai: whoami.ds.akahelp.net, и другие. Понятно, что у этих сервисов – свои ограничения. Например, я разу добавил поддержку DNS over TLS, поскольку данную технологию можно использовать между резолвером и авторитативными серверами (естественно, поддержка авторитативными серверам – редкость, но тем не менее).

Итак, технический смысл затеи: DNS-зона dns.1d.pw делегирована на специально разработанные NS-серверы, которые собирают данные о запросе, упаковывают их в TXT-записи, и отправляют в ответ. Такой способ позволяет информации пройти по цепочке, через резолвер. То есть, при штатной схеме работы, рекурсивный опрос для клиента выполняет рекурсивный резолвер, и именно это резолвер, в конце DNS-поиска, пришлёт запрос на авторитативный сервер. Например, если воспользоваться Google Public DNS, то мы увидим IP-адрес из пула DNS-сервисов Google (пример для 8.8.8.8):

$ dig @8.8.8.8 dns.1d.pw -t TXT +short
"ECS: 185.39.19.0/24/0"
"ns: dns-b"
"src: 74.114.29.150:43267"
"target [id]: dns.1d.Pw. [2909]"
"transport: UDP"

Обратите внимание, здесь добавилась информация о подсети источника запроса – ECS: 185.39.19.0/24/0. Это именно источник того запроса, который поступил в систему Google, а сервис DNS-резолвинга Google пронёс эту адресную информацию до авторитативного сервера. То есть, если вы используете сервис 8.8.8.8, то, – при прочих равных, – авторитативные серверы видят номер вашей подсети (обычно, это подсеть интернет-провайдера). Авторитативные серверы DNS – это не серверы Google, а подсеть видна даже в том случае, если прочий трафик завёрнут в VPN.

Кроме сведений о префиксе ECS, этот второй пример содержит другой адрес источника: 74.114.29.150 – IPv4-адрес резолвера Google. Сервис Google может приходить за DNS-данными и по IPv6, и по IPv4.

Приглядитесь к записи целевого имени – dns.1d.pw: при вызове dig имя записано строчными буквами, но в TXT-записи вернулось dns.1d.Pw (заглавная P). Именно так имя увидел авторитативный сервер. Что это? Это называется “рандомизация регистра символов” – один из дополнительных факторов защиты от спуфинга ответов, который применяет Google. Если воспользоваться аналогичным сервисом Cloudflare (1.1.1.1), то “рандомизации регистра” не случится:

$ dig @1.1.1.1 dns.1d.pw -t TXT +short
"target [id]: dns.1d.pw. [33389]"
"ns: dns-a"
"src: [2400:cb00:78:1024::ac44:b97b]:24308"
"transport: UDP"

Чтобы наблюдать такие эффекты и требуется возврат исходного имени в TXT-ответе. Дело в том, что изменяет имя резолвер, поэтому, без подобных хитростей, на DNS-клиенте резолвера обнаружить изменения нельзя.

Второй фактор защиты от спуфинга тоже можно видеть на распечатке выше: это номер транзакции (id – 33389). Сервер должен ответить с тем же номером, который отправил DNS-клиент в запросе. Третий типовой фактор – номер порта-источника (особенно актуально в UDP). Запросы в DNS отправляются на номер порта 53 (udp, tcp) и 853 (DNS over TLS), а номер порта-источника, соответственно, рандомизируется (должно быть сложно его угадать).

Сервис можно использовать для того, чтобы увидеть собственный внешний IP и параметры собственных DNS-запросов. Для этого нужно выступить в роли резолвера, направив DNS-запрос непосредственно узлу данного сервиса. Имена можно узнать, запросив список NS:

$ dig @8.8.8.8 dns.1d.pw -t NS +short
ns-dns-a.1d.pw.
ns-dns-b.1d.pw.

Спрашиваем напрямую ns-dns-a.1d.pw:

$ dig @ns-dns-a.1d.pw dns.1d.pw -t TXT +short
"target [id]: dns.1d.pw. [31841]"
"ns: dns-a"
"src: 185.39.19.199:26283"
"transport: UDP"

Получили в “src” IP-адрес, с которого отправлен локальный запрос (точнее: тот адрес, который видит внешний сервис – потому что может быть NAT и тому подобные штуки).

Основной транспорт для DNS – это UDP. Однако необходима и поддержка TCP. Сервис dns.1d.pw умеет отвечать по TCP. Да, контролировать протокол, который использует внешний резолвер, так просто не выйдет, но при локальнй подготовке запроса можно выбрать TCP при помощи флага +tcp утилиты dig. Проверяем:

$ dig @ns-dns-a.1d.pw dns.1d.pw -t TXT +short +tcp
"target [id]: dns.1d.pw. [9376]"
"ns: dns-a"
"src: 185.39.19.199:50169"
"transport: TCP"

Теперь указан TCP в качестве транспорта. TLS – не является обязательным. Однако это современная и весьма популярная технология, которая тут тоже поддерживается. Более того, сервис возвращает “расширенную информацию” – данные о версии TLS, о шифронаборах, о выбранном имени узла (SNI). Утилита dig поддерживает TLS (+tls). Проверяем:

$ dig @ns-dns-a.1d.pw dns.1d.pw -t TXT +tls +short
"target [id]: dns.1d.pw. [22366]"
"ns: dns-a"
"src: 185.39.19.199:59527"
"transport: TLS (1.3/X25519MLKEM768/TLS_CHACHA20_POLY1305_SHA256)"
"SNI: ns-dns-a.1d.pw"

Обратите внимание: здесь в записи имени DNS-узла – ns-dns-a.1d.pw – нельзя указывать крайнюю справа точку (которая превратила бы запись в FQDN, и которая для специалистов в DNS является чем-то само собой разумеющимся). Дело в том, что бэкенд сервиса использует реализацию TLS из типовой библиотеки Go. А типовая, “коробочная”, реализация TLS в Go строго не допускает финальные точки в составе хостнейма внутри расширения SNI – TLS-соединение просто не устанавливается. Такое поведение библиотеки, вообще говоря, вопрос весьма дискуссионный, но к теме этой записки он не относится: просто – не указывайте точку в конце, или используйте IP-адрес узла напрямую (возможно, я как-нибудь этот момент переделаю самостоятельно, ну или разработчики Go одумаются).

Вообще, TLS-сертификаты для авторитативных серверов, используемых в данном проекте, я выпустил через Let’s Encrypt, и это сертификаты для IP-адресов (v4/v6), что неплохо подходит для случая TLS на авторитативном DNS-сервере. А раз это сертификаты для IP-адресов, то для хостнеймов они так и так не валидны, но по умолчанию – dig здесь сертификаты и не проверяет на соответствие имён.

В поведение авторитативного сервера заложены и некоторые другие особенности, так что он не полностью соответствует “лучшим практикам” DNS, и это сделано специально. Например, как отмечено выше, в ответ на запрос A-записи – придёт ответ с флагом REFUSED, а это позволяет посмотреть на расширенные статусы DNS-ошибок, если запросить А-запись через сервис Google.

Кстати, в продолжение предыдущей записки про новые санкционные правила Let’s Encrypt. Что и как этот УЦ мог бы сделать для того, чтобы соблюдение правил реализовать технически? Дело в том, что ACME – это автоматический протокол, у него есть особенности (отсутствие строгого подтверждения аккаунта, отсутствие подтверждения заявки пользователем-человеком и т.д.).

Во-первых, понятно, можно сортировать заявки на выпуск сертификатов по именам доменов, отсекая .RU и др. Но это не помагает в других доменных зонах, и не помогает с сертификатами на IP-адреса.

Во-вторых, можно отказывать в заказах, поступающих по ACME со стороны IP-адресов, которые принадлежат “подсанкционным блокам”, например, по автономной системе. Но автономная система для ACME-клиента легко может быть из совсем другой страны. Более того, точность подобной геопривязки вообще не так высока, как считается.

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

Самый эффективный вариант – использовать все три перечисленных способа сразу. Вот только автоматизируется это довольно плохо. А ACME – автоматический протокол. Хотя, строгая привязка регистраций .RU к ЕСИА тут как раз может быть интерпретирована УЦ так, что имена в зоне – подсанкционны все, поэтому для всех имён и нужно заблочить заказы сертификатов.

Пишут (id: 65656, между прочим), что Let’s Encrypt добавили в своё соглашение пользователя пункт о соблюдении санкционного режима США (и других “подходящих” стран). Из исходного документа очевидно, что ограничения распространяются так же просто на “рядовых жителей” (ordinarily resident) подсанкционных территорий. Это не то чтобы совсем “новелла”, но для Let’s Encrypt выглядит неожиданно. Но в соответствующем подпункте, который про жителей, речь пока только о территориях и странах, находящихся под полным “эмбарго” США – comprehensive U.S. sanctions. Занятно, что термин “ordinarily resident” – обозначает всякого, кто фактически проживает на заданной территории, то есть, это очень широкое понятие.

Кроме того, в правила добавлены явные и бесспорные упоминания подсанкционных “компаний и субъектов” – им нельзя сертификаты и нельзя “в их интересах действовать”. Санкции сейчас раздаются очень массово, так что, в принципе, с использованием сертификатов “свободного УЦ” Let’s Encrypt возникают большие трудности. Но не у всех, понятно – ибо сам-то этот УЦ позиционируется как “для всех”: “Encryption for Everybody” – написано на первой странице сайта очень большими буквами, но тут нужно понимать, что и кто именно составляют множество этих body. (Оговорка: на dxdt.blog используется TLS-сертификат от УЦ Let’s Encrypt, поскольку это пока что единственный вариант из “хорошо известных УЦ”, который мне всё ещё доступен; долго ли ещё будет доступен? что отберут раньше – домен или сертификаты? Пока что нет ответа.)

Занятно и то, что многие пересказывают версию, по которой, мол, Let’s Encrypt (LE) тут просто “закрепил в правилах уже действовавшую практику” – нет, это не так: раньше в LE отказывали в выпуске сертификатов для конкретных имён, прямо указанных в конкретных списках, поскольку в США установили специальное исключение из санкционного режима, касавшееся “этих ваших интернетов” – в узких кругах соответствующий юридический “казус” известен как “поправка имени Cisco”. Новое дополнение в правилах LE – позволяет применять расширенные основания для “ковровых” отказов и отзыва сертификатов. Естественно, просто так подобные изменения в правила не вносят. Если бы LE стремились бы сами что-то такое применять, то вписали бы раньше. Но раз вписали сейчас, то, очевидно, с целью прямого применения, потому что были какие-то внутри возражения, сомнения, зацепки. Посмотрим. (Есть небольшой шанс, что откатят, но реально небольшой.)

Очередное обновление сервиса ТЦИ audit.statdom.ru (САБИУ), который определяет разнообразные настройки DNS, TLS, HTTP и др., получив на вход DNS-имя узла.

В версии 1.4 появился вывод расширенной информации об SCT-метках в TLS-сертификатах, относящейся к так называемым “tiled-логам”. Tiled-логи – это разновидность логов Certificate Transparency, которые позволяют извлекать данные при помощи запроса отдельных “блоков”, а именно, через оптимизированное API мониторинга CT-логов: в рамках реализации этого API дерево лога разбивается на несколько уровней “соседних” узлов при помощи абстракции “замощения” (откуда название).

На скриншоте как раз выделены данные с индексом LeafIndex, который позволяет быстрее находить данные о нужном сертификате в tiled-логе. Такие SCT-метки сейчас добавляет в сертификаты Let’s Encrypt.