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

Кстати, в продолжение предыдущей записки про новые санкционные правила 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 стремились бы сами что-то такое применять, то вписали бы раньше. Но раз вписали сейчас, то, очевидно, с целью прямого применения, потому что были какие-то внутри возражения, сомнения, зацепки. Посмотрим. (Есть небольшой шанс, что откатят, но реально небольшой.)

Если кто-то ещё сомневается насчёт очень быстрого перехода в вебе на TLS-сертификаты, выпускаемые с помощью хеш-деревьев (деревья Меркла), то есть, на MT-сертификаты (или просто – MTC), то обратите внимание на свежую публикацию от Let’s Encrypt: там уже в планах стоит 2027 год – это год, когда планируется запуск готового к штатному использованию ACME-сервиса для MTC, а проще говоря – с новыми сертификатами. Да, нужно ещё реализовать поддержку на стороне TLS-серверов и разнообразных библиотек, но это дело наживное – в Go, например, процесс уже идёт.

Так что, особенно сомневаться насчёт направления развития не нужно, а поскольку Let’s Encrypt, Cloudflare и Google тут, – вполне правомочные, – законодатели технологической моды, то нужно ожидать, что вообще через пару лет кардинально изменится технологическая база для Удостоверяющих Центров (УЦ), работающих с вебом и браузерами. На всякий случай напомню, что схема выпуска MT-сертификатов совсем другая, она несовместима с имеющейся и гораздо сложнее в реализации: например, логи Certificate Transparency уходят, как бы, внутрь УЦ, а вместо обычных, локальных подписей – нужно строить доказательства включения в хеш-дерево и получать на специальных промежуточных отметках “распределённые” подписи от нескольких держателей доверенных ключей. Ну а самое главное – будут и TLS-сертификаты вообще без подписи, а только с доказательством из дерева, и будет соответствующая этим сертификатам схема обновления зон доверия, работающая в режиме, близком к “онлайн” (через серверы Google, скорее всего).

В Калифорнии (США) продвигают местный закон (статья в The Register, англ.), который, если его примут, обяжет встроить в процесс подготовки моделей для 3D-печати некий “детектор моделей огнестрельного оружия” – то есть, чтобы автоматически запрещалась печать на 3D-принтере, если пользователь “что-то не то” пробует распечатать. Естественно, речь пока про огнестрельное оружие идёт из-за того, что, мол, можно напечатать условный “призрачный револьвер”. Но логика запрета построена на совсем другом моменте: предлагается вести некий центральный реестр запрещённых к печати моделей; а программное обеспечение (ПО), подготавливающее модель к печати, должно с базой сверяться, получать разрешение на подготовку.

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

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

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

1.

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

2.

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

3.

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

4.

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

5.

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

Нужно ли использовать DNSSEC? Хотелось бы просто написать: да. Но, к сожалению, многолетняя история данной технологии уже обставлена особенностями, которые не позволяют написать просто “да”.

Напомню, кратко, что такое DNSSEC: это технология, позволяющая удостоверять адресную информацию в DNS при помощи механизмов цифровой подписи. Основная особенность DNSSEC в том, что она пристраивает к “классической DNS” схему делегирования по криптографическим ключам, которая позволяет транслировать доверие между зонами, по иерархии. То есть, в “классической DNS” используется делегирование по именам авторитативных серверов: зона уровнем выше содержит имена серверов, которые отвечают за зону уровнем ниже. Например, если у нас есть example.com., то в зоне com. указывается перечень имён серверов (NS), которые администрация зоны com. уполномочила отвечать за example.com.

В DNSSEC нет делегирования по серверам имён (делегирующие ответы со списком NS даже не подписываются), но есть делегирование по криптографическим ключам, которые служат для проверки подписей: зона уровнем выше содержит отпечаток ключа для зоны уровнем ниже; в примере с example.com – в зоне .com размещается отпечаток целевого ключа к зоне example.com, при этом сам целевой ключ – находится только на серверах зоны example.com. Такое размещение ключа – важная особенность DNSSEC, которая несколько меняет логическое отношение зон разного уровня. Отпечаток ключа – это DS-запись, находящаяся в зоне уровнем выше, а сам ключ – это DNSKEY-запись, находящаяся в делегируемой зоне. Отпечаток должен сойтись со значением ключа. Связь “DS –> DNSKEY” – это и есть (безопасное) делегирование в DNSSEC. Это делегирование работает параллельно классическому делегированию по именам NS. (Кстати, с DS-записями связаны самые распространённые ошибки настройки DNSSEC в DNS-зонах.)

Нередко приходится слышать, что, мол, “у нас зона не подписана”, и поэтому “нас DNSSEC не касается”. Это не совсем так. В большинстве случаев, DNSSEC – касается “неподписанных” зон. Дело в том, что в DNSSEC подписывается и отсутствие делегирующих DNSSEC-записей – DS-записей. Иначе смысл данной технологии был бы полностью утрачен, так как можно было бы просто удалить из DNS-ответов DNSSEC-данные и – всё выглядело бы как “неподписанная” зона. Поэтому, если у вас зона example.com, но сама она не подписана, то DNSSEC на вашу зону всё равно распространяется, поскольку подписана зона уровнем выше – .com. То есть, в зоне .com криптографически удостоверен факт того, что в вашей зоне – нет доверенной DNSKEY-записи, а поэтому для вашей зоны удостоверен факт отсуствия DS-записи.

Что это означает? Это означает, что если для example.com радикально сломается DNSSEC в зоне com., то и ваша зона example.com окажется недоступна для валидирующих резолверов (“валидирующий” – это DNS-резолвер, проверяющий DNSSEC-записи). Сейчас очень многие используют валидирующие резолверы, поскольку DNSSEC валидируют крупнейшие провайдеры: Google Public DNS, Cloudflare 1.1.1.1 и др. Штатный опрос DNS начинается с корневого домена и обязательно проходит через зоны первого уровня. Поэтому, к сожалению, даже если у вас домен пятого (условно говоря) уровня внутри небезопасной зоны, для которой DNSSEC нет даже в зоне на два уровня выше, рекурсивный опрос всё равно где-то будет касаться зон с DNSSEC. (Пример, как говорится, “на символах”: 5.4.www.example.com – предположим, что DNSSEC тут нет уже в example.com, но это не помогает, если подписи сломались в .com). Поэтому DNSSEC влияет на вашу зону, даже если у вас в зоне нет DNSSEC-подписей, поскольку на каком-то уровне путь к вашей зоне – подписан, как небезопасный. Естественно, это не распространяется на невалидирующие резолверы: вот им – всё равно.

К сожалению, практическая “ломкость” DNSSEC, регулярно приводящая к авариям больших зон первого уровня, привела и к тому, что складывается нехорошая практика отключения DNSSEC на стороне валидирующих резолверов, если обнаружилась какая-то масштабная проблема. Есть соответствующий документ RFC 7646, который прямо предписывает так делать (кто бы мог подумать? представьте, что для TLS была бы спецификация, предписывающая “всё равно продолжить”, если ошибка “ожидаемая”; да; зато вот в DNSSEC – есть). Формально, речь там идёт о том, что оператор DNS-резолвера должен убедиться, что “эта нога – у кого надо нога!” (то есть, что сломалось там, где положено ломаться), и только потом отключать валидацию для конкретного поддерева (подмножества) DNS-зон. И, судя по сообщениям Cloudflare, именно так этот провайдер и поступил, когда поломались подписи в зоне первого уровня .de (крупнейший национальный домен).

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

Что касается TLS и DNSSEC. Да, эти технологии задают совсем разные поверхности атаки: если DNSSEC работает, и работает верно, то, при обнаружении подмены адресной информации, до применения TLS даже не дойдёт дело. Но это только если DNSSEC работает. А если эту технологию отключают крупнейшие провайдеры, чтобы “пользователи могли заходить на сайты” в сломанной зоне, то, как бы, рассуждать про поверхности атаки становится сильно сложнее. Заметьте, что при этом нет спецификаций, предписывающих “отключать валидацию TLS-сертификатов по команде с сервера обновлений браузера”, если вдруг у крупного удостоверяющего центра “сломались ключи”. Естественно, у TLS другая архитектура и поломка “корневого оператора” пока что не может так повлиять на доступность, как в случае с DNS. Хотя, тут слова “пока что” я использовал неспроста: как только глобальная инфраструктура TLS для HTTPS перейдёт на сертификаты с хеш-деревьями, без подписей, то сразу возникнет похожая на DNS ситуация с раздачей промежуточных “аретфактов доверия”. Пойдёт ли тогда та же корпорация Google, как поставщик наиболее распространённых веб-браузеров, по схеме под условным названием “исправленному верить”? Не факт, но, как говорится, посмотрим: времена сейчас новые, так что всякое может приключиться, поди как и аутентификацию узлов в TLS избирательно отключат.

Вернёмся к DNSSEC в доменной зоне. Распространено ещё такое мнение, что наличие DNSSEC ухудшает работу электронной почты, если домен является почтовым. В отличие от мнения про “независимость от DNSSEC”, это мнение гораздо более обосновано и граздо ближе к реальности. Действительно, такое возможно. Это, буквально, ещё один “неожиданный эффект” DNS. Может показаться, что хотя бы при отправке почты DNSSEC не влияет: ну, какая разница, что там в DNS-зоне, если при отправке почты наш почтовик идёт на внешний сервер напрямую? А имена и адреса внешнего сервера – они в другой зоне. Это так, но вот только сейчас принимающий сервер, в подавляющем большинстве случаев, будет запрашивать записи из зоны отправителя. Например, SPF-записи, или TXT-записи с ключами DKIM, или ещё что-то. Если в зоне DNSSEC не работает, а принимающий почту сервер валидирует DNS-ответы, то он не сможет все эти записи получить. Ну а с доставкой почты в подписанный домен – должно быть очевидно: уже извлечение MX-записи затрагивает DNSSEC. Так что, да, на почту DNSSEC влияет. И в качестве бонуса тут идёт описанный выше момент: от DNSSEC всё равно не отделаться полностью, а отсутствие DNSSEC в собственной зоне лишь уменьшает шансы эту DNSSEC собственноручно же сломать, и “почётная” обязанность отламывания подписей – передаётся выше, по делегированию.

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

Итак, нужно ли использовать DNSSEC? Нужно. Однако прежде необходимо определить – можно ли.

Часто попадаются фразы, что, например, алгоритм ML-KEM – это алгоритм, “стойкий к подбору на квантовом компьютере”. Вопрос, конечно, терминологический, но попробуем разобраться, почему такая формулировка (“стойкий к подбору”) – не верная, и почему так писать нежелательно.

Более или менее строгое определение: “ML-KEM, теоретически, обладает стойкостью к взлому при помощи алгоритма Шора”.

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

Однако здесь “эффективно реализующего алгоритм Шора” – это просто характеристика компьютера, который, вообще говоря, полагается универсальным (в текущей, так сказать, степени понимания “универсальности”). Впрочем, заметьте, что основной исходный посыл тут – это именно “неприменимость” алгоритма Шора. Так что определение про “стойкость к алгоритму Шора” – тоже верное. Потому что те криптосистемы, на замену которым предложен алгоритм ML-KEM, – разновидности ECDH, RSA и др., – уязвимы именно к алгоритму Шора.

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

Во-вторых, никто не доказал, что невозможны другие “квантовые алгоритмы”, которые, – на подходящем, но гипотетически реализуемом, квантовом компьютере, – будут успешно и быстро взламывать ML-KEM. А если учитывать, что модели квантовых вычислений легко оперируют континуумом (синусы/косинусы и действительные числа), то, вообще говоря, не стоит делать ставку на то, что теоретический “квантовый алгоритм подбора ML-KEM” не придумают в обозримом будущем. Более того, сейчас распространено мнение, что в том самом обозримом будущем гораздо более вероятно появление практической классической атаки на ML-KEM, чем появление квантовых компьютеров, способных сломать ту же X25519 (разновидность ECDH) алгоритмом Шора. То есть, криптосистема ML-KEM может оказаться уязвима для обычных компьютеров, а X25519 и другие современные варианты ECDH – сохранят классическую стойкость.

Как же вообще нужно именовать эти криптосистемы, типа ML-KEM? Например, я и сам регулярно использую термин “криптосистемы с постквантовой стойкостью”, но это тоже не слишком-то хороший вариант, поскольку, откровенно говоря, он не так далеко ушёл от стойкости “к подбору на квантовом компьютере”, как хотелось бы. Конечно, “постквантовая стойкость” здесь – это стойкость к алгоритму Шора. Но это лишь подразумевается, а сам термин – чрезмерно широкий. Видимо, наилучший вариант, который уже сложился исторически, это просто “постквантовые криптосистемы”. То есть, такие криптосистемы, которые предлагается использовать после появления доступных универсальных квантовых компьютеров, и акцент тут – на слове “универсальных”.

Хроники разваливающихся интернетов. Я, в силу ряда причин, использую DNS-резолвер, который установлен за пределами Рунета. С некоторых пор я заметил, что ряд вспомогательных сервисов для аккаунта Google – недоступны из браузера, из моей локальной сети. А я всё ещё использую для ряда задач почту Google – так исторически сложилось, тем более, что, в отличие от того же “Яндекса”, Google мне пока что эту историческую почту и кучу прочих сервисов под моим доменом (из Рунета, заметьте) предоставляет бесплатно, как ни странно; не знаю, долго ли ещё так будет, но пока что – так; недостатки там тоже есть, кто бы сомневался, но это другая история: а сервис, как минимум, никто за эти десятилетия у меня не отобрал – очень существенный плюс Google, по нынешним временам-то.

Вернёмся, впрочем, к доступности.

Итак, я заметил, что какие-то сервисы через HTTPS недоступны, а они необходимы для нормальной работы веб-интерфейса (там всё управление – через веб). Логичное предположение: так как мой резолвер приходит на авторитативные серверы Google из “иностранной сети”, ему DNS Google отдаёт другие IP-адреса, а именно – адреса, предназначенные для соответствующего региона; и узлы под этими IP-адресами – недоступны из российских сетей. Почему это влияет? Потому что браузером-то я подключаюсь из российской IP-сети. Где именно соответствующий трафик забанен – я уже не стал разбираться: сейчас подобное разбирательство – легко превращается в длительное исследование, так как понять, “что-как-где-почему”, довольно сложно: сети окончательно стали мутными на прикладном уровне. Да, я делал бы ставку на то, что забанено на российском транзите; но, к сожалению, тут нельзя полностью исключать и сторону CDN Google – вообще говоря, агрессивная геобалансировка на стороне крупнейших провайдеров была известна и раньше, иногда, скажем, такая блокировка может быть побочным эффектом маршрутизации для anycast-адресов (отдельная история).

В общем, я просто добавил на сторне своего DNS-резолвера функцию отправки подсети-источника DNS-запроса в ECS, но только для доменов внутри зоны google.com, чтобы авторитативные DNS-серверы на той стороне видели целевой IP-префикс запроса. В Unbound (весьма рекомендую, кстати) избирательная поддержка ECS легко включается. После того, как в запросы добавились ECS – IP-адреса в ответных A-записях стали приходить другие, а сервис Google – тут же заработал из локальной сети. Да, откровенно говоря, не могу исключить, что это совпадение, но посмотрим: в других, – более прозрачных, но аналогичных, – случаях, с которыми я сталкивался, подход с перенастройкой резолвера срабатывал эффективно.

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

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

Кстати, насчёт “быстрых” TLS-сертификатов для IP-адресов, которые подходят для веб-сайтов без доменных имён. Я уже некоторое время тестирую схему с таким сертификатом на сайте под IP-адресом https://185.39.19.199/.

Напишу, как там что настроено (это виртуальная машина, понятно). ОС Debian 13, веб-сервер – nginx 1.26.3, из пакетов Debian; я установил актуальную версию 5.6.0 утилиты certbot из snap (предварительно поставив snap, конечно) и настроил профиль аккаунта с использованием директории web-root, которую обслуживает nginx для хоста по умолчанию. Поскольку нужно принимать и обрабатывать HTTP по IP-адресу, в nginx я настроил единственный блок server для произвольных имён (default_server на 80 и 443, кроме того, на всякий случай, заведомо недоступный “_” в server_name). Пути к сертификату и ключу – указывают туда, где ссылки на них выкладывает certbot: /etc/letsencrypt/live/185.39.19.199/fullchain.pem.

Сама утлита certbot запускается по таймеру Systemd, а чтобы nginx подхватывал новый сертификат после его выпуска, я добавил в /etc/letsencrypt/renewal/185.39.19.199.conf строку “renew_hook = systemctl restart nginx”, блок “[renewalparams]”.

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

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

DNS Name: 185.39.19.199.zone
IP Address: 185.39.19.199 

Схема та же, как и с IP-адресом, но первоначально нужно указать при вызове certbot доменное имя при помощи опции -d (дополнительно к IP-адресу). Проверка DCV будет выполнена и для IP-адреса, и для доменного имени, а сертификат выпустится с двумя именами в блоке SAN.

DNSSEC строится на механизмах цифровой подписи и на иерархии криптографических ключей. Открытые ключи публикуются в DNSKEY-записях. Подписи вычисляются для адресной информации, опубликованной в зоне. Значения подписей публикуются в RRSIG-записях. Ключей и, соответственно, DNSKEY-записей в DNS-зоне может быть несколько. Чтобы доверенным образом проверить подпись, резолвер должен выбрать подходящий ключ. Чтобы упростить поиск подходящего ключа – в RRSIG-записях указывается 16-битный тег, соответствующий ключу. Это и есть тег ключа DNSSEC. (Тег ключа используется также в DS-записи, которая обеспечивает другой важнейший аспект: делегирование в DNSSEC, но ниже речь пойдёт только про RRSIG.)

Значение тега представляет собой простейшую “контрольную сумму” – то есть, сумму октетов DNSKEY-записи, выполненную в определённом порядке (чётные/нечетные и т.д.). Очевидно, что используемый алгоритм вычисления тега тут вообще не имеет особого значения – в теге всего 16 битов, а в ключе, как минимум, 256 битов: коллизии тут всегда будут достигаться легко.

Практический смысл добавления некоего “алгоритма суммирования” несколько тёмен. Понятно, что сумма позволяет побороть варианты, когда в каких-то криптосистемах некоторые части в записи ключей принципиально одинаковые. Но это, обычно, не так. Поэтому можно было бы с почти тем же успехом, например, брать два байта на нечётных средних позициях записи непосредственно ключа (примерно так и было сделано для тегов алгоритма подписи RSA/MD5); да, ещё нужно учитывать флаги ключа, но и это не сильно влияет на практику. В общем, как бы там ни было, но DNSSEC сейчас использует теги, вычисляемые как сумма.

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

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

Естественно, штатный способ выбора ключа состоит в сравнении тегов: если в зоне единственный ключ с совпавшим значением тега, и этот ключ не даёт доверенной подписи для заданной RRSIG-записи, то, понятно, другие ключи можно не проверять. Почему? Потому что спецификация требует, чтобы тег, указанный в RRSIG, совпадал с тегом ключа. Заметьте, что нигде не сказано, что соответствие должно быть один к одному – тег-ключ. Но даже в случае такого совпадения, это всё равно будет пробная проверка подписи – просто, в штатной конфигурации, используется единственная итерация. Всё потому, что тег не обязательно соответствует одному ключу.

Из обратной ситуации, то есть, из того, что ключи должны соответствовать тегам, но разные ключи могут иметь одинаковый тег, и выводится DoS-атака: в зоне может быть несколько ключей с одинаковыми значениями тега и резолвер должен перебирать эти ключи для проверки RRSIG, которая теперь ссылается единственным тегом на множество ключей. При этом, RRSIG-записей может быть много. И криптосистем тоже может быть несколько. Это известная DoS-атака под названием KeyTrap (CVE-2023-50387).

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