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

Очередная новость “про блокировки” сообщает, что, якобы, Amazon запретил “использовать свои сети в качестве прокси” (варианты: использовать для “обхода блокировок” и др.). Сообщения сопровождаются ссылкой на публикацию AWS (Amazon Web Services), где, впрочем, рассказывается о другом.

О чём идет речь? Действительно, существует схема маскировки имени сервиса, под названием Domain Fronting. Схема построена на архитектурной особенности HTTPS: данный протокол использует TLS в качестве транспорта, соответственно, появляются два уровня – TLS и HTTP. С каждым из этих уровней связано некоторое имя сервера (имя хоста). В TLS это имя передаётся в поле SNI (Server Name Indication), в открытом виде, то есть, в виде, доступном для просмотра системой DPI. На уровне HTTP есть ещё одно имя сервера, оно входит в состав адреса документа (URI), который запрашивает клиент. Этот адрес, а следовательно и имя, входящее в его состав, передаётся уже в зашифрованном виде, поэтому недоступен для DPI.

Пример: пусть клиент, являющийся браузером, использует веб-сервер под именем “example.com” и пытается с помощью HTTPS извлечь документ по адресу “https://example.com/document.html”. Тогда при установлении TLS-соединения, которое происходит до отправки HTTP-запроса, браузером в поле SNI (TLS) будет передано имя “example.com” (обратите внимание: без полного адреса документа, только имя узла, домен). После того, как TLS-соединение установлено, браузер отправит GET-запрос HTTP, указав, согласно спецификации протокола HTTP, адрес документа “/document.html” и имя узла (в специальном поле заголовка HTTP-запроса, под названием Host) “example.com”. Это имя совпадает с именем на уровне TLS, в поле SNI, но вообще имена могут различаться, так как находятся на разных уровнях абстракции. Приложение, работающее по HTTP, вообще обычно не видит не только имени в SNI, но и самого протокола TLS.

Domain Fronting строится на подмене имён SNI и HTTP. В SNI указывается имя одного сервера, но после того, как TLS-соединение установлено, HTTP запросы отправляются с указанием другого имени. Поясню в терминах примера из предыдущего абзаца: в TLS SNI указывается имя “example.com”, однако GET-запрос уже отправляется с указанием “test.ru” в качестве имени хоста. Теперь на уровне HTTP указано совсем другое имя, но так как TLS и HTTP используют разный контекст, сервис, где размещён исходный узел (адресуемый example.com в нашем примере), может выполнять и HTTP-запросы к test.ru. Это будет являться побочным эффектом реализации HTTPS на стороне сервиса.

Теперь предположим, что из некоторого сегмента Глобальной сети доступ к test.ru по каким-то причинам невозможен. Используя Domain Fronting можно замаскировать запросы к test.ru под HTTPS-сессию с узлом example.com: так как HTTP-запросы передаются в зашифрованном виде, анализирующая трафик сторона видит только имя example.com в поле SNI TLS. Конечно, могут заблокировать и доступ к example.com, в том числе, по IP-адресу, но тут в игру вступает административная часть: представьте, что вместо example.com используется google.com (или какой-то другой массовый сервис) – мало кто готов блокировать условный Google. Конечно, чтобы всё сработало, требуется поддержка описанной схемы со стороны сервиса, используемого как прикрытие. Именно на этом этапе и возникает сервис “Амазон” CloudFront, который позволяет (или позволял, см. ниже) использовать такую схему для ресурсов, которые размещаются за CloudFront. При этом “заехать” за чей-то домен можно без ведома того клиента CloudFront, который этот домен использует штатно, что, конечно, не самая привлекательная особенность сервиса.

Метод маскировки с использованием Domain Fronting известен много лет. Наличие такой особенности объясняется тем, что для массового сервиса удобнее жёстко разделить TLS и HTTP – одни логические узлы обрабатывают TLS-соединение (выполняют “терминирование TLS”), а другие – работают с HTTP, уже в открытом виде. Поводом для новостей про “запрет обхода блокировок” как раз послужило то, что “Амазон” недавно обновил платформу CloudFront, исправив обработку контекстов и, тем самым, удалив возможность использования Domain Fronting. Думаю, понятно, что к “обходу блокировок” это если и имеет какое-то отношение, то весьма и весьма косвенное, и только со стороны тех нестандартных клиентов, которые данную особенность использовали. К ним, например, относится мессенджер Signal, который, впрочем, уже получил предупреждение о нарушении правил использования сервиса от Amazon.

Пишут, что шифры, предложенные АНБ, очередной раз не утвердили в качестве стандартов ISO (для “Интернета вещей”). Как следует из неофициальных публикаций, мотивируют решение против шифров АНБ тем, что агентство могло внести в них бэкдоры. Такая мотивировка сейчас популярна и привлекательна для СМИ, но каких-то внятных описаний бэкдоров, конечно, не предлагается. Шифры Speck и Simon – относятся к классу “лёгких” шифров, предназначенных для устройств, сильно ограниченных в вычислительных возможностях. Обычно, это микроконтроллеры, используемые для управления разным оборудованием, в том числе, бытовым. Я довольно подробно писал про Speck в прошлом году, рассматривая его реализацию для микроконтроллера AVR (точнее, для Arduino), в той записке есть схема шифра и соответствующий исходный код.

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

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

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

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

Что касается самих ключей: опять же, строго говоря, открытая часть протокола DH доступна для записи, а в открытой части содержится достаточно информации для получения секрета. Стойкость протокола основана только на том факте, что не известно универсальных практических (то есть, работающих на доступном классическом компьютере) алгоритмов быстрого вычисления секрета на основе только открытых параметров DH. Но это не означает, что “ключи есть только на клиенте”. Если центральный сервер записывает трафик, то ключи, вообще говоря, есть и у него, но в представлении, которое сложно обратить (получить из открытого ключа секретный, эта задача, в случае широко используемых сейчас вариантов DH, называется дискретным логарифмированием). Сложно, но вовсе не невозможно. Более того, считается, что для конкретных параметров DH, обладающих определёнными свойствами, можно провести предварительные вычисления на специализированном суперкомпьютере, а потом очень быстро вычислять секретные ключи. Именно по этой причине рекомендуется при использовании DH генерировать полностью собственные параметры, а не применять заранее известные, которые, например, выдаёт центральный сервер. В случае классического DH (не эллиптического), основным параметром является простое число (модуль), задающее группу, в которой проводятся операции протокола. Это, впрочем, технические детали – я писал о них раньше, применительно к TLS. Главное наблюдение состоит в том, что информация о секретных ключах содержится в параметрах, которыми стороны обмениваются в открытом виде.

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

Про DH и связанные с этим протоколом ограничения я неоднократно писал раньше, например – здесь и здесь.

Новая версия протокола TLS 1.3 в ближайшее время получит статус рекомендации (статус уже одобрен). Я написал статью с обзором этого нового протокола. Он действительно новый, потому что от TLS 1.2 отличается радикально. Статья – TLS 1.3: на пути к внедрению.

Немного теорий заговора. Сетевого уровня.

Маршрутизаторы – эффективное направление атак на сети, которые являются сегментами глобальной Сети. В подавляющем большинстве случаев, если “погасить” несколько умело выбранных маршрутизаторов, сеть падает полностью, несмотря на попытки резервирования, предпринятые при проектировании и построении сегмента. Хрестоматийная ситуация: резервные маршрутизаторы не справляются с изменившейся конфигурацией сети; причин может быть много разных – от возросшего трафика, до невозможности обмена управляющей информацией в результате возникших в сети “штормов”. Например, предполагается, что довольно давний случай с глобальной аварией сети в Сирии был вызван тем, что специалисты АНБ, во время операции по удалённому внедрению (обновлению?) программных закладок, случайно “уронили” ключевой маршрутизатор.

Интересно, как можно обнаруживать подобные действия?

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

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

IP или, например, UDP, оказываются универсальными в силу того, что работают на общем для всех узлов IP-сети логическом уровне. При этом другие протоколы спускаются на несколько уровней ниже. Так, есть инструменты VLAN (виртуальные сети) и другие логические элементы, невидимые для IP. Связанные с ними протоколы также можно было бы использовать для передачи недокументированных сигналов. Однако из-за того, что свойства даже соседствующих сетей на соответствующих уровнях очень сильно разнятся, тут встречаются трудности. С другой стороны, можно представить ситуацию, когда использование расширений стандарта Ethernet (например) позволяет скрывать от анализаторов трафика, работающих параллельно маршрутизаторам, целый пласт ходящих по физической линии связи данных. Элементарный пример, понятный каждому: представим, что для анализа трафика используется обычный компьютер и Wireshark, но продвинутая сетевая карта – игнорирует часть пакетов, например, обнаружив в заголовке Ethernet некоторый заранее зашитый в процессор карты индекс (заметьте, что такое поведение аналогично штатной функции, позволяющей разграничивать VLAN-ы). Понятно, что Wireshark в таком случае не будет видеть часть трафика, и обнаружить, что видны не все пакеты, вряд ли получится. Конечно, пакеты могло бы прятать и ядро ОС, но аппаратная фильтрация сетевой картой – куда как более эффективна: зафиксировать передачу данных теперь можно только при помощи логического анализатора, подключенного непосредственно к проводам. А вот уже представить себе логический анализатор, который прячет сигналы, гораздо сложнее, чем только что описанную конфигурацию с продвинутой сетевой картой. Но многие ли мониторят сети при помощи логических анализаторов? (Вопрос даже не риторический, а скорее похож на шутку.)

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

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

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

Смысл обнаружения спуфинга состоит в том, что приложение-навигатор сможет вывести предупреждение и перестать показывать пользователю заведомо неверные навигационные данные.

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

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

Простой поиск, опять же, легко реализуется штатными средствами нашего условного ПО. Однако нужно ожидать большого процента ложных срабатываний. Понятно, что если к интересным относить все файлы, содержащие слово missile, то даже при ограничении выборки на определённые ПК, в ответ приедет слишком много мусора, и не приедет слишком много интересного, потому что, например, действительно интересные файлы программный комплекс неправильно преобразовал, перепутав кодировку. Перепутать что-то довольно легко: предполагается, что программа работает на самых разных конфигурациях ОС и прикладных пакетов.

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

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

Естественно, схему можно сделать многоуровневой. Например, учитывать то, как данный файл используется: часто ли он оказывается в оперативной памяти, часто ли изменяется, если изменяется, то в результате каких действий: скажем, очень точно можно отделить документы, которые пользователь редактирует в текстовом редакторе, от тех, которые просто читает. Операционный подход, если его распространить на характеристики метрики, должен давать очень хороший результат.

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

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

Прошло три года с тех пор, как я сделал на dxdt.ru HTTPS основным протоколом. До сих пор на запросы по URL, начинающимся с http://, веб-сервер отвечает редиректом (301) на соответствующий HTTPS-адрес. То есть, HTTP всё ещё поддерживается в качестве “точки входа”. При этом в ответах сервера присутствуют заголовки HSTS, соответственно, браузер, однажды обратившись по HTTPS, уже не должен использовать HTTP для доступа к dxdt.ru (формально – в течение длительного времени, которое определено в заголовке HSTS). Обращения по http:// всё ещё видны в логах (всякие старые ссылки и пр.), поэтому отключать HTTP совсем – я пока не планирую. Идея такая, тем не менее, есть. Вообще, учитывая весьма небольшой трафик на dxdt.ru и тот факт, что те, кто сайт читает, очевидно, имеют возможность подключаться по HTTPS, отключение HTTP не выглядит абсурдным.

Кстати, за три года общее проникновение HTTPS выросло весьма и весьма заметно. Если взглянуть на статистику по зоне .RU, то даже с 2015 года число узлов с корректной настройкой TLS для HTTPS выросло в 12 раз (прописью: в двенадцать раз). Ни одна другая фундаментальная технология доставки контента не демонстрирует сейчас подобного роста.

Около года назад я кратко описывал возможную атаку на протокол биткойн, основанную на быстром вычислении дискретного логарифма при помощи квантового компьютера, что ломает подпись ECDSA. Вот, появилась весьма подробная научная публикация на эту же тему: Quantum attacks on Bitcoin, and how to protect against them – в работе рассматриваются и квантовые атака на алгоритм “доказательства проведённой работы” (PoW), они, впрочем, признаны неэффективными на практике.

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

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

ICANN отложила ротацию корневого ключа DNSSEC на неопределённое время. Первоначально, фактическую ротацию планировали провести 11 октября этого года. В качестве причины указаны данные о недостаточном распространении нового KSK (корневого ключа) по резолверам. Напомню, что корневой ключ (RSA, разрядностью в 2048 бит) в DNSSEC не менялся с момента внедрения технологии в глобальной DNS, то есть, с 2010 года. О механизме ротации при запуске просто забыли. За это время такой алгоритм ротации был предложен и утверждён согласно процессу IETF (RFC 5011), но теперь ICANN при помощи другого технологического механизма (RFC 8145) и косвенных данных обнаружила, что алгоритм ротации не работает.

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