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

Технология под названием DANE (DNS-Based Authentication of Named Entities) позволяет размещать в DNS информацию, идентифицирующую заданные элементы криптосистем, используемых различными сервисами в Интернете. DANE распространяет удостоверяющие свойства DNSSEC на другие протоколы, тем самым сильно расширяя возможности и область применения DNSSEC.

Например, используя DANE можно разместить в DNS специальные записи, привязывающие определённый SSL-сертификат к веб-серверу, отвечающему под соответствующим доменом. Программы-клиенты (браузеры), обращающиеся к веб-серсверу, смогут проверить валидность сертификата средствами DNSSEC. Что, потенциально, приводит имеющуюся инфраструктуру к схеме с единым корнем. Или, по крайней мере, позволяет владельцу домена как-то бороться с “левыми” сертификатами, которые могут быть выпущены для его домена: запись в DNS точно указывает на то, какие именно сертификаты браузер должен принимать для данного веб-сайта. Естественно, DANE касается не только HTTPS (TLS), пример работы с которым я приведу ниже, но и распространяется на другие протоколы.

Пока что DANE находится в разработке, которая, надо заметить, идёт неплохо: примерно за год активной деятельности рабочей группы соответствующий RFC уже добрался до завершающей стадии подготовки. Тем не менее, говорить о какой-то поддержке приложениями пока что рано, протокол всё ещё экспериментальный, его ключевые особенности могут измениться. Кроме того, требуется продвижение идеи в пользовательские браузеры.

В качестве тестовой площадки я сделал https://dane.nox.su/ – понятно, что заходить туда имеет смысл только по https. Более того, приготовьтесь увидеть предупреждение системы безопасности браузера. Подробности – ниже.

Как это работает? Основной момент в том, что информация об открытом ключе SSL-сертификата вносится в подписанную зону DNS. В случае с dane.nox.su – с этим проблем нет, так как зона nox.su поддерживает DNSSEC. Веб-сервер dane.nox.su использует самоподписанный SSL-сертификат. Это сделано специально, так как одной из интересных особенностей DANE является то, что этот новый инструмент, благодаря DNSSEC, позволяет превратить самоподписанный (бесплатный, заметьте) сертификат во вполне сносный механизм аутентификации веб-сайта. Хотя, на практике лучше использовать не самоподписанный, а полноценный сертификат – с ним DANE, понятно, также совместим.

Процедура настройки DANE для TLS довольно проста. Я опущу описание процесса генерации SSL-сертификата, предположим, что он уже есть и установлен. Требуется добавить в зону DNS запись особого вида, содержащую отпечаток (хеш) открытого ключа сертификата. Используем SHA-256 (один из вариантов, указанных в RFC). Прежде всего, отпечаток нужно получить:

$ openssl x509 -noout -fingerprint -sha256 -in yourcert.crt

– здесь yourcert.crt – файл с вашим сертификатом.

Вообще, для использования в DNS, значение SHA-256 потребуется в записи без двоеточий, так что лучше сразу сказать как-то так:

$ openssl x509 -noout -fingerprint -sha256 -in nox.su.self.crt | perl -ne ‘s/://g; print $_’

Результат примерно такой (для сертификата dane.nox.su):

SHA256 Fingerprint =
12B1BC2AF0D87C6E0E259CE364CE6921
B74F0C748328C4A33A11F19467700EB2

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

Запись DNS выглядит, соответственно, так (для dane.nox.su):

_443._tcp.dane.nox.su. IN TYPE65468 \# 35
( 03000112B1BC2AF0D87C6E0E259CE364CE6921
B74F0C748328C4A33A11F19467700EB2 )

Думаю, нетрудно догадаться, что имя построено из номера порта, типа протокола и хоста: TCP и 443 – это стандартный транспорт HTTPS. Тип TYPE65468 – это временный тип записи, выделенный для тестирования DANE. Собcтвенно, сейчас IANA уже выделила “нормальный” тип – TLSA (52). Но с TLSA пока что удобства ещё меньше.

Значение: тут к отпечатку, в качестве префикса, добавлено три байта (октета), со значениями 03,01,01. Это, в порядке следования:

* метод использования сертификата – 3 – обозначает, что сертификат не должен проверяться по цепочке доверия (PKIX) браузера, а только сверятся с отпечатком в DNS; подходит для самоподписанного сертификата; другие варианты предусматривают проверку цепочки внутри иерархии подписей;

* проверяемая часть сертификата – 1 – проверятся отпечаток открытого ключа; 0 – проверяется отпечаток всего сертификата;

* тип хеш-функции – 1 – SHA-256; тут всё понятно.

То есть, значение записи строится так: {метод}{часть}{тип-хеша}{значение-хеша} – просто и прозрачно. Извлечь тестовую запись, вместе с подписью, из DNS можно попробовать такой командой:

$ dig +dnssec -t TYPE65468 _443._tcp.dane.nox.su

После того, как запись успешно размещена в зоне и зона подписана – всё готово для использования DANE.

Тут и кроется основная практическая трудность (или, скажем так, засада): поддержки DANE пока нет. Из того, что мне удалось обнаружить: плагин для Firefox Extended DNSSEC Validator, альфа-версия. В принципе, Chrome должен поддерживать DANE, но, на правах первопроходца, он делает это в манере, отличающейся от описанной в текущем RFC (который, напомню, черновик). Для того, чтобы заработал Chrome, требуется другая запись в DNS и специальное поле в сертификате. Поэтому, в случае с dane.nox.su, Chrome выдаёт предупреждение о “плохом” сертификате. Надеюсь, что по мере развития технологии, всё нормализуется и будет один стандарт.

Адрес записки: https://dxdt.ru/2012/06/28/4958/