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

(Меня попросили описать в более или менее подробных деталях, какие ключи и как сейчас используются в DNSSEC. Думаю, что описание заслуживает публикации на dxdt.ru – потому что до сих пор нередко путают ключи, зоны, цепочки делегирования и прочие важные моменты.)

Посмотрим на то, как используются ключи DNSSEC, взяв для примера зону .org. Предположим, что мы справшиваем SOA-запись для .org у корневого сервера. Тогда, вместе с адресами NS-ов домена org, если последний делегирован безопасно, то есть, с DNSSEC, мы получим от корневого сервера DS-запись (или несколько – сейчас, например, их для .org две) и RRSIG-запись для DS (важно – именно для DS). То есть, главная интересующая нас подпись содержится в корне, это RRSIG over DS (RRSIG от DS). Напомню, что DS-запись содержит значение хэш-функции ключа, относящегося к делегируемой зоне (то есть, в случае нашего примера, к .org). Подпись RRSIG сгенерирована при помощи корневого ZSK (Zone Signing Key, ключа подписи зоны), который опубликован в корневой зоне, и его нужно будет оттуда получить, чтобы проверить подпись на DS. (Ключ также может уже находиться в кэше резолвера, тогда запрашивать его у корневых серверов не нужно.)

В дальнейшем, информацию, полученную с сервера имён (NS) домена org, мы проверяем ключами, которые опубликованы в этой же зоне (в .org). То есть, RRSIG-и из данной зоны проверяются ключами, которые в той же зоне и расположены. Для связывания ключей из разных зон в цепочку доверия служат DS-записи, которые также подписываются.

Посмотрим чуть ближе на реальное устройство DNSSEC для .org, как всё выглядит сейчас:

1.

В корне (в корневой зоне) мы видим два ключа (я буду их обозначать реальными идентификаторами, которые я взял из DNS) – 22603 (ZSK) и 19036 (KSK – кстати, не менялся с 2010 года, потому что забыли придумать, как его поменять). Для ключа 22603 в корневой зоне есть RRSIG, сгенерированная от ключа 19036. 19036 – это и есть тот самый главный, корневой, рутовый KSK, открытая часть которого изначально находится у нас в резолвере (пусть ключ и опубликован в DNS, но в резолвер он должен попасть каким-нибудь другим доверенным путём, не черезе DNS). После того, как мы проверили RRSIG от ключа 22603 этой открытой частью ключа KSK (19036) и всё сошлось, мы добавляем ключ 22603 в доверенные ключи. И можем пойти дальше.

2.

В корне же мы видим DS-записи для ORG, а также RRSIG для них. Подпись (RRSIG over DS) сделана от ключа 22603 (то есть, от ZSK, см. выше). Ключ 22603 мы только что добавили в доверенные. Проверяем подпись на DS-записи, если всё сошлось, то можем пойти дальше, записав себе значение DS.

3.

На серверах, поддерживающих .org, мы видим четыре ключа – 9795, 21366 (эти два – KSK) и 60764, 11112 (а эти два – ZSK; KSK от ZSK отличаются значением одного бита в поле типа ключа). Хэш от ключа 21366 соответствует значению DS-записи, опубликованной в корне (см. выше). Эту запись мы только что (ну или некоторое время назад, см. TTL) получили от корневого сервера, вместе с подписью, которую проверили – значит, DS-у доверяем.

4.

На серверах .org мы также видим записи (их сейчас три) RRSIG для набора DNSKEY. Эти три записи RRSIG сгенерированы от трёх ключей: 9795, 21366 и 11112 – обратите внимание, каждая из этих RRSIG подписывает все ключи, опубликованные в зоне (ключи публикуются в записях DNSKEY). То есть, у нас четыре ключа подписаны при помощи трёх других. Один из этих подписывающих ключей – 21366 – соответствует DS-записи, полученной из корня, поэтому мы можем добавить его в список доверенных ключей. Теперь записям, подписанным этим ключом, мы тоже будем доверять. После того, как мы убедились, что подпись от ключа 21366, сделанная для RRSIG DNSKEY в зоне .org, – валидная, мы добавляем и три других ключа (9795, 11112, 60764) в список доверенных. Почему? Потому что RRSIG over DNSKEY удостоверяет и их тоже – она для всех ключей зоны общая.

5.

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

Обратите внимание, что мы не проверяли подписи на адресах NS-ов (серверов имён .org) – этого и не нужно делать, если только мы не хотим проверить именно значения NS-ов. Хитрость в том, что в DNSSEC не имеет значения, откуда были получены подписанные данные – с легитимных серверов или ещё откуда-нибудь: главное, чтобы подписи сходились.

Резюме: информацию, получаемую с серверов .org, мы проверяем ключами, полученными с тех же серверов, а вот убедиться, что это правильные ключи, нам позволяет подпись (RRSIG over DS) из корневой зоны.

Собственно, добавил в зону dxdt.ru TLSA-запись, содержание которой соответствует отпечатку (SHA-256) серверного сертификата – это означает, что для dxdt.ru теперь заработала поддержка DANE (технологии, позволяющей с помощью DNSSEC защитить домен от подмены SSL-сертификата). Вот бы ещё DANE, наконец-то, стали поддерживать браузеры.

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

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

Пишут, что турецкие провайдеры, в целях блокирования доступа к интернет-ресурсам, перехватывают трафик, идущий в сторону сервисов Google Public DNS. То есть, трафик пользователей, предназначенный для 8.8.8.8 и 8.8.4.4, заворачивается на локальные узлы провайдера, которые отдают поддельные ответы DNS (в частности, об адресах twitter.com). Перехват касается и других хорошо известных сервисов DNS-резолвинга.

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

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

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

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

Нельзя сказать, что за пару лет DNSSEC “шагнула в массы”, а сейчас является штатным средством защиты в Рунете: в .ru, потенциально, подписано лишь что-то около двух сотен доменов (в статистике по ссылке ведётся учёт только DS-записей). Тем не менее, популярность DNSSEC набирает, но, конечно, слишком медленно.

(Отмечу, что я за это время подготовил ещё несколько ресурсов и публикаций, касающихся DNSSEC. Среди них, например: браузерный инструмент проверки поддержки DNSSEC; справочная страничка dnssec.pw и демонстратор DNSSEC + TLS 1d.pw.)

Занятный момент есть в официальном FAQ по Google Public DNS – они пишут, что если адрес, который не проходит валидацию DNSSEC, является популярным и хорошо известным, то для него может быть сделано исключение: валидацию отключат.

Вообще говоря, учитывая ошибки в управлении безопасными зонами (с DNSSEC), решение выглядит разумно: невалидным может оказаться и какой-нибудь домен первого уровня, без всяких атак злоумышленников, такое уже случалось несколько раз (тут как бы в корне подписи не “обрушили”, что уж говорить о доменах уровнем ниже).

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

Цитата из FAQ:

How does Google Public DNS handle lookups which fail DNSSEC validation?

If a client requests a validated lookup for a signed domain, but Google Public DNS cannot validate the lookup (due to misconfiguration, missing or incorrect RRSIG records or DNSKEY records, etc.), it will return an error response (SERVFAIL). However, if the impact is significant (e.g. a very popular domain is failing validation), we may temporarily blacklist the zone from validation until the problem is fixed.

Сделал простой сервис, позволяющий проверить из браузера, есть ли поддержка DNSSEC у DNS-резолвера, которым вы пользуетесь. Скорее всего, это резолвер интернет-провайдера. Сервис здесь: dnssec.dxdt.ru.

Там, на странице сервиса, описано, как он работает. Механизм очень простой, но, во-первых, требует, чтобы был включен Javascript, и, во-вторых, определяет положение вещей с точностью до настроек браузера, а не операционной системы. Тем не менее, штука, на мой взгляд, полезная.

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

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

Многие знают, что у Google есть полезный DNS-сервис – открытый резолвер, воспользоваться которым может каждый, Google Publi. Буквально на днях, судя по ответам серверов, Google Public DNS стал проводить валидацию DNSSEC. То есть, подписанные домены теперь проверяются. Раньше такой функции не было.

Дальше немного технической части.

Убедиться в поддержке DNSSEC можно следующим образом (8.8.8.8 – один из адресов резолвера Google):

$ dig @8.8.8.8 -t A +dnssec dxdt.ru

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 -t A +dnssec dxdt.ru
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45823 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

– наблюдаем установленный бит AD в ответе (зона dxdt.ru – подписана, это факт).

$ dig @8.8.8.8 -t A +dnssec broken.nox.su

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 -t A +dnssec broken.nox.su
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52027

– наблюдаем SERVFAIL, это правильно, потому что broken.nox.su – специально сломана, чтобы можно было протестировать поддержку DNSSEC; если резолвер не проводит валидацию, то в ответе будет IP-адрес (для broken.nox.su это, обычно, 0.0.0.0).

Ещё пример, используем добротно сломанный dotsu.su:

$ dig @8.8.8.8 -t A +dnssec dotsu.su

– ответом должен быть SERVFAIL, и оно так и есть, по крайней мере, на моей стороне.

(Вообще, пока официального объявления нет, нужно полагать, что эта новая функция работает не для всех узлов, то есть, результаты могут отличаться.)

Этот шаг Google может неплохо помочь в продвижении DNSSEC, а заодно повысит популярность их DNS-резолверов.

Буквально вот только что в корневой зоне DNS появилась DS-запись для ключа зоны .ru. То есть, теперь DNSSEC в .ru есть и работает.

В зоне .ru вчера появились записи DNSKEY, в которых опубликованы ключи KSK и ZSK для зоны, с соответствующей подписью. Следующий шаг – появление DS-записей (тоже с подписями) в корневой зоне DNS. Что, как обещают, должно случиться до конца года.