DNSSEC: проверка подлинности
Кстати, про 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.
Адрес записки: https://dxdt.ru/2009/03/04/2163/
Похожие записки:
- Статья о технологии Encrypted Client Hello
- Десятилетие DNSSEC в российских доменах
- Реплика: теоретическая разборка карамелек
- Реплика: пропуск подписанного трафика и цифровые идентификаторы в будущем
- DNSSEC и DoS-атаки
- Публикация ТЦИ о постквантовых криптосистемах
- Обновление темы dxdt.ru
- Модули DH в приложении Telegram и исходный код
- Неравенство треугольника в Интернете и anycast
- "Внешний ИИ" масштаба Apple
- Метаинформация, мессенджеры и цепочки событий в трафике
Комментарии читателей блога: 2
1. 5th March 2009, 08:40 // Читатель gene написал:
вот-вот, очень интересно как это реализовать. фактически это основная проблема, которая не позволяет сделать надежную децентрализованную систему передачи сообщений (на основе DHT/Kad). да еще отсутствие такой возможности позволяет “нехорошим людям” подделывать файлы в торрентах и emule/kad.
Если решение найдется (желательно без центрального доверенного сервера), то обязательно напишите!
2. 5th March 2009, 10:40 // Читатель sarin написал:
Заметки про RSA были бы очень интересны!
как нынче оценивается криптостойкость RSA, какие существуют перспективные алгоритмы на замену и чем элептические кривые лучше? и что такое вообще эти элиптические кривые :)