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

Кстати, про DNSSEC – технологию, которую сейчас будут бурно обсуждать. Для чего DNSSEC? Для того, чтобы ввести в интернетовский обиход механизм, позволяющий всем участникам обмена адресной информацией осуществлять более надёжное управление доверием. Доверие – это самое важное в DNSSEC. Тем не менее, сейчас про DNSSEC напридумывали много всякого, неверного.

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

Вот.

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

2. DNSSEC позволяет победить такие вполне себе фундаментальные уязвимости в DNS, как, например, отравление кеша. Эти уязвимости позволяют нехорошим злоумышленникам перенаправлять пользователей Интернета на свои серверы, подменяя соответствие имён доменов и IP-адресов. Набрал мойбанк.ru, а браузер попал вовсе не на сервер банка. Кому-то может показаться, что более старые, чем Веб, уязвимости вовсе не так уж и опасны, они протухли. Но вот, скажем, если недавно продемонстрированную на практике возможность создания поддельного SSL-сертификата, вообще не отличимого от настоящего, прикрепить к отравлению кеша, то получится, что достаточно продвинутые злоумышленники могут клонировать сайт банка, снабдив его, в том числе, и валидным SSL-сертификатом. Даже крайне недоверчивый пользователь будет введён в заблуждение. Хорошо построенная атака может дать массовый эффект: пользователи крупного провайдера все как один пойдут вместо реального сервера банка на подставной, при этом в адресной строке браузера будет значиться правильный адрес, и SSL-сертификат не вызовет в браузере окон с предупреждениями.

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

4. Вот с ключами как раз и возникают основные хитрости. Как известно, для проверки подписи нужен открытый ключ, принадлежащий тому, кто подписывал. В случае DNS – тому лицу, которое сгенерировало данные об адресации в доменной зоне. Можно рассматривать всякие технические особенности и хитрости криптосистем RSA (и если это интересно, то можно написать серию заметок по теме), но самый важный вопрос всё равно более системный: как узнать, что претендующее на владение той или иной доменной зоной лицо, размахивающее через DNS-запрос открытым ключом и соответствующей подписью, действительно владеет этой зоной и уполномочено ей управлять? И вправду, может, это самозванец? То есть, опять вопрос сводится к такому: можно ли конкретной подписи доверять, если раньше этой подписи не попадалось и о её владельце особой информации нет? Это общий вопрос для систем аутентификации. В офлайне он издревле решается так: приглашают третью сторону, которой доверяют оба “участника сделки”. Если решение обобщить, то возникает некая структура доверия, которая может быть “плоской” (как, например, в системах PGP), но чаще бывает иерархической, сходящейся к некоторому корневому центру, который, в итоге, удостоверяет подписи всех остальных “участников соглашения”.

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

Вот.

Вообще, несколько подробнее про DNSSEC в популярном изложении можно прочитать в недавнем выпуске журнала “Доменные имена”, который в электронном виде можно взять на сайте RU-CENTER. На 69-й странице там начинается моя статья про DNSSEC.

(Если есть какие-то вопросы – прошу в комментарии, я, возможно, сделаю отдельный раздел про DNSSEC.)

***

Дополнения (2012):

О DNSSEC, в течение нескольких лет, я написал много других публикаций и реализовал несколько технологических демонстраций, например, такой демонстрацией является первый подписанный домен в зоне .su – nox.su.

Корневую зону глобальной DNS (общепринятой) подписали в ночь с 15 на 16 июля 2010 года. Связанные с этой процедурой домыслы прессы, падкой на криптосенсации, привели к возникновению забавного “мема” о “шестёрке программистов, которых уполномочили перезагрузить Интернет, если он сломается”. Естественно, в реальности всё обстоит сильно иначе.

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

Кстати, внедрение DNSSEC приведёт к появлению новых типов атак на DNS, среди которых есть довольно интересные и неожиданные (впрочем, два упомянутых ниже типа специалистам давно известны и описаны в соответствующих RFC, но тем не менее).

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

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

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

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

Вот. Есть и другой важный момент.

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

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

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

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

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

А о том, что же такое DNSSEC – я как-нибудь напишу.

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

“Уязвимость […], которая могла бы затронуть значительную часть Интернета, исправлена общими усилиями специалистов по сетевой безопасности и крупных корпораций…” – это “Вебпланета“.

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