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

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

К сожалению, в домене ru DNSSEC появится неизвестно когда, но точно нескоро. Другой российский (по факту) домен – su, – хоть и заявлен недавно на конференции ICANN как поддерживающий DNSSEC, на практике, насколько я смог выяснить, не позволяет воспользоваться защитными механизмами. Записи об su в корне DNS подписаны, но в самой этой зоне мне не удалось найти ни одного подписанного домена второго уровня. Более того, не подписан даже домен администратора SU – fid.su. Для рядового же пользователя проблема в том, что, на практике, отсутствует механизм “привязки” подписанной зоны второго уровня к ключам домена SU.

(Addon (17/11/11): как пишут из ТЦИ, реестр SU поддерживает работу с DNSSEC, но регистраторы пока не реализовали свою часть. Ждём.)

Вообще, подписать саму зону можно не прибегая к услугам администратора домена верхнего уровня (см., например, nox.su, который я подписал в порядке эксперимента – сами записи в зоне подписаны, но цепочка рвётся в .su, разместить там нужные данные сейчас не представляется возможным). “Привязка” доменов к единой цепочке выполняется с помощью специальных DS-записей (Delegation signer), вносимых в зону, уровнем выше удостоверяемой, для построения иерархии, ведущей к корневому ключу (кстати, опубликованному на сайте IANA). Если делать всё добротно, то данные DS-записей для подписывания должны передаваться минуя DNS, по другим каналам, подразумевающим некоторую аутентификацию отправителя – иначе теряется большая часть смысла в развёртывании DNSSEC. Стандартный путь проходит через регистраторов доменов.

Итак, для получения работающей конфигурации пришлось dxdt.ru и nox.su предпочесть домен tooktook.org, так как зона .org корректно подписана и размещение DS-записей в ней поддерживается крупными регистраторами (я воспользовался GoDaddy).

Функционирование каждого домена обеспечивают серверы имён (NS). Для tooktook.org я взял пару серверов с BIND 9.7.3 (это известная реализация DNS-сервера), который полностью поддерживает DNSSEC. На сайте ISC есть подборка инструкций по настройке DNSSEC в BIND-е. Я не стану приводить подробных деталей, потому что это будет офтопик, на мой взгляд (если что, то пишите вопросы в комментарии). Сам процесс создания подписанной зоны DNS несложен, и сводится к генерации нескольких ключей (закрытых и открытых), с последующим удостоверением с их помощью записей в файле зоны. В пакете с BIND есть все утилиты: dnssec-keygen, dnssec-signzone и т.п. То есть, на входе у вас текстовый файл зоны без подписей, на выходе – текстовый файл зоны, но уже с дополнительными записями (RRSIG, DNSKEY), содержащими подписи и открытые ключи для их проверки.

После того, как зона подписана, генерируем DS-запись (записи), содержащую значение хеш-функции от открытой части ключа (KSK), с помощью которого подписан ключ (ZSK), удостоверяющий записи в зоне. (Пара ключей используется для удобства их ротации и оптимизации процедуры подписывания зоны. И, да, можно сгенерировать DS-запись до подписывания зоны.) В случае с доменом tooktook.org я без каких-то трудностей разместил DS-запись при помощи клиентского веб-интерфейса GoDaddy. На удивление, весь процесс – генерация подписанной зоны, размещение записей, – занял примерно 20 минут, включая ожидание обновления информации в DNS.

Теперь tooktook.org подписан (проверить можно с помощью веб-интерфейса от VeriSign). Зачем? Следующий шаг – проверка на практике технологии, дополняющей, с помощью DNSSEC, механизмы использования SSL-сертификатов в браузерах и уже поддерживаемой в Chrome. Нужно же посмотреть, что нас ждёт в ближайшем будущем.

Не так давно я писал про удостоверение SSL-сертификатов с помощью DNSSEC. Оказывается, как мне подсказывают, подобная функциональность уже включена в рабочий Chrome 14, примерно пару недель назад. В общем, процесс движется быстро. Интересно, кто успеет запрыгнуть в вагон?

История с чередой “поломок” удостоверяющих центров, выдающих SSL-сертификаты, наводит на довольно логичный вывод: коммерческую систему “управления доверием” могут очень сильно перекроить. Потому что момент подходящий.

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

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

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

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

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

И вот тут появляется DNS и DNSSEC. В DNS единый корень. Как раз доменное имя (читай – инфраструктура DNS) позволяет типичному пользователю установить “первый контакт” с неизвестным ему ранее сайтом. DNSSEC, понятно, также содержит единый корень и подписать “что попало” – не выйдет, так как доменные имена должны быть уникальны. С чисто технической точки зрения с помощью DNSSEC можно удостоверить не только адресную информацию, но и дополнительные сведения, например, указать, какие именно сертификаты – или, что конкретнее, криптографические ключи, – может использовать сайт под данным доменом. Заметьте, существующая иерархия УЦ здесь уже не нужна!

Но главное, что криптографическая часть от DNSSEC уже неплохо популяризована, корневые ключи сгенерированы, а у руля уже стоит бренд VeriSign, который хорошо узнаваем и в отношении SSL-сертификатов.

Так что шумиха раскручена не просто так. Наверняка готовятся очень интересные перемены.

Дополнение: да, понятно, что при условии изменения порядка и появления у DNSSEC новой роли, корректирующей судьбу SSL, к бизнесу по “управлению доверием” прямо подключаются регистраторы доменов.

В ночь с 15 на 16 июля корневую зону DNS подписали настоящим ключом и опубликовали открытые ключи для проверки подписей DNSSEC. Таким образом, Минторг США, компания VeriSign и ICANN завершили развёртывание DNSSEC в корневой зоне. Собственно, теперь DNSSEC можно использовать в глобальной DNS. Ключи каждый может взять на сайте IANA.

Теперь поддержку DNSSEC начнут массово вводить в доменах первого уровня.

Напомню, что следующие шаги на пути к новому Интернету – внедрение IPv6 и модернизация принципов маршрутизации (через внедрение криптографических механизмов).

На фоне озвучиваемых в СМИ планов по созданию новых государственных сервисов в национальном кириллическом домене интересно взглянуть на адресацию в Интернете с точки зрения “главных рубильников”.

Понятно, что всякий интернет-сервис намертво привязан к двум фундаментальным штукам: DNS (то есть, имена доменов) и IP (то есть, сами адреса, по которым доставляются пакеты данных). В этом кроется принципиальное отличие интернет-среды от, скажем, радиоэфира.

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

Совсем другое дело – системы интернет-адресации. Здесь есть главные рубильники, и главные кнопки, которые позволяют очень быстро отключить частоту. Самый простой пример – удаление домена из файла зоны. Удалить можно не только домен второго уровня, но и домен первого уровня. В результате все сайты из него станут недоступны. Так как опрос DNS всегда начинается с корневых серверов, то внесение изменений в корневую зону позволяет не только отключить любой домен первого уровня, но и, например, перенаправить трафик внутри этого домена на другие адреса. Конечно, требуется административный доступ к корневой зоне DNS.

Посмотрим на сценарий с DNS чуть более детально. Предположим, что кому-то требуется перехватить управление некоторым национальным доменом. Адресация в национальном домене глобально определяется серверами имён, которые указаны для него в корневой зоне. Первый путь для перехвата: изменяется запись в корне, новая версия указывает на другие сервера имён. Часто можно услышать, что корневую зону поддерживает большое число корневых серверов (их – 13), узлы которых распределены по всему миру и находятся под управлением разных компаний. Это так. Но файл корневой зоны все эти серверы получают из одного источника, со скрытого сервера, управляемого компанией VeriSign. Соответственно, если изменить адреса в исходном файле, то при очередном обновлении изменения распространятся на все экземпляры корневой зоны.

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

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

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

Заметьте, что изменение DNS коснётся и электронной почты в домене. Она начнёт ходить “не туда”.

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

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

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

Да, конечно, всё это теоретические сценарии. Но интересные. Так что, думаю, в следующих записках разбор темы можно продолжить. Тем более, что актуальность Интернета у нас растёт семимильными шагами.

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

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

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

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

Между тем, корневые серверы DNS начинают отдавать подписанные зоны – то есть, разворачивается DNSSEC (это технология удостоверения адресной информации в DNS с помощью цифровой подписи). 27 января ввели поддержку DNSSEC на L-Root (проверить может каждый, но пока что там ключи “подставные” используются).

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

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

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

О чём идёт речь: сейчас на типичной клиентской машине (персональном компьютере, подключенном к Интернету, работающем под управлением ОС Windows), для получения информации из DNS используется так называемый stub resolver – это такая весьма простая программа (или, скажем, системная служба – не важно), которая лишь отправляет запросы о получении IP-адреса для того или иного домена на внешний DNS-сервер. Основная особенность тут в том, что stub resolver не выполняет “рекурсивного поиска” в глобальной DNS, а поручает всю работу по такому поиску известному DNS-серверу (обычно, это сервер, принадлежащий интернет-провайдеру).

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

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

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

Корневую доменную зону раздаёт по глобальной DNS скрытый сервер, контролируемый штатовской компанией VeriSign. Подписывать зону в DNSSEC также будет VeriSign своим секретным ключом (хотя, да, ключ ей “делегирует” ICANN). Операционные системы, работающие на большинстве пользовательских компьютеров, выпускает другая штатовская корпорация – Microsoft. Понятно, что новые резолверы устанавливаются с помощью глобального обновления ОС: это стандартная процедура. Надеюсь, пытливый читатель способен самостоятельно сопоставить эти два “технологически-административных” момента и сделать вывод о свойствах пространства, в котором существует “независимость” современного Интернета, и, соответственно, трезво оценить рычаги управления, вводимые с помощью DNSSEC (на фоне объявления о “независимости ICANN”).

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

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

Свежее продолжение истории с “независимостью” Интернета и ICANN (из-за “техничности” повода, СМИ широкого профиля тенденцию из вида упустили):

Пишут, что с 1 июля 2010 года в корневой зоне системы DNS вводится полная поддержка технологии DNSSEC.

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

То есть, “логическое” доменное пространство (в представлении рядовых пользователей) как бы отпускают “на свободу” под эгидой ICANN и GAC (обсуждайте правила в доменах, обдумывайте введение новых – пожалуйста). Как и ожидалось, параллельно, уровнем ниже вводится новый мощный технологический рычаг, сохраняющий иерархию управления – DNSSEC. Следующий логичный шаг: подписывание анонсов в BGP, подписывание блоков IP (ускоренная миграция в IPv6 – в помощь). Там также будет корневой ключ и, думаю, мудрые Штаты его так же оставят у себя в кармане.

Вот, кстати, первым источником уязвимостей в реализациях DNSSEC (это “безопасное” расширение DNS) будут рационализаторские решения. Технические центры крупных доменов захотят экономить ресурсы и поправят технологии так, как удобнее с точки зрения экономии. Поправки породят уязвимости.

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

Так что с DNSSEC будет то же самое – дыры подготовят рационализаторы.