Новинки безопасности, практикум: настройка DANE и dane.nox.su

Технология под названием 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 выдаёт предупреждение о “плохом” сертификате. Надеюсь, что по мере развития технологии, всё нормализуется и будет один стандарт.

()

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 11

  • 1. 28th June 2012, 15:27 // Читатель sarin написал:

    что за три байта приписаны к отпечатку в конце?

    700EB2

  • 2. 28th June 2012, 15:50 // Александр Венедюхин ответил:

    Хм, вообще-то, это часть отпечатка.

  • 3. 28th June 2012, 17:53 // Читатель sarin написал:

    ага, посмотрел исходники страницы. это фаерфокс так отрисовал, что три байта не видны.

  • 4. 28th June 2012, 20:04 // Александр Венедюхин ответил:

    Я поправил: разбил на две подстроки число.

  • 5. 29th June 2012, 14:04 // Читатель jno написал:

    А вот чё-то невидать красной армии (ака “что я делаю не так?”(тм))!
    При запросе из примера всё пучком, но на обычный ANY приходит только это:

    ;; ANSWER SECTION:
    dane.nox.su. 900 IN A 50.16.193.159
    dane.nox.su. 900 IN RRSIG A 5 3 900 20120926080227 20120628080227 17166 nox.su. OSPXVaVny2zVxebPlyHcrKXgY3NswjiUe3CplPRqRevAgYPhOC3JcgE9 b45JEcU2M7RK6B5WUesMsJebGDNbz05sisyiM6znFZu5YA4mKFHRUg2r aylA0nwk4cbQ9UJof4MQj/HocZZNZc2Jt26TtcES4sVWGilbuTtAVx+v ctg=
    dane.nox.su. 900 IN MX 10 mx.yandex.ru.
    dane.nox.su. 900 IN RRSIG MX 5 3 900 20120926080227 20120628080227 17166 nox.su. PXwKhyVHayoZQvH0AjmzeaPgky+LiSbypARUt05x/6vfghkNQ0EHIhnb 7IyS61BTEN5kQOqjGky4JRblJ9pOU1CYU6LiotWwklZ+xj4ihmzgCMXH cXcehIl7Apz8BwfW05FNP2DNWQuHZOUM+nugJGrhd6proE0oJkh61tOn vUE=
    dane.nox.su. 900 IN TXT “2357111317192329”
    dane.nox.su. 900 IN RRSIG TXT 5 3 900 20120926080227 20120628080227 17166 nox.su. DDFAjkd9xdUPIwpJqicK5HkQhhlMI89Xo/yiG3aIqfJvxTmkxx4vOGEW cqCZHgVW//ByXMp8kwNJY/s5DiYmvjmM7Ema3yzH5/RTYt6bMnOCmm2+ g1ZR6roEbYDQDFdy15vbgVXtrFii+vEdre6Y4TKCRVyVNjF2pC2EbHmB srM=
    dane.nox.su. 900 IN NSEC _443._tcp.dane.nox.su. A MX TXT RRSIG NSEC SPF
    dane.nox.su. 900 IN RRSIG NSEC 5 3 900 20120926080227 20120628080227 17166 nox.su. q56l1cHXJq97DXIONzqGieiSKwrdHER6DBA1DJwlrAXGCHhSpH/DURkK Ck4nr65c2wEG1SbP9JGK7bAIuWX4WfyzXeGxw51LdOZM8/zO3xUJpWWs vlFAW2Mg7GTiB9bp933spfQFwxnQ0cvNK+cB3p+5gF+qtrXcyZoo7psA t4A=
    dane.nox.su. 900 IN SPF “v=spf1 redirect=_spf.yandex.ru”
    dane.nox.su. 900 IN RRSIG SPF 5 3 900 20120926080227 20120628080227 17166 nox.su. uKmXnG0lCwlpAq5AjQMlFYKNMtBKlg7o44th34wA1oaiDJs02Qc40r3X y8MysUYYj04KucNJa8hKwAdSLaqYYd7S4LnZipCEQy368Z23tYCu43IS ltjeurWQDciT+p4aR5we+hnsdmxstgPYxjtcqhhjEYuJxDkqhEs/ZmiN lMQ=

    ;; AUTHORITY SECTION:
    nox.su. 900 IN NS ns1.8191.ru.
    nox.su. 900 IN NS ns2.8191.ru.
    nox.su. 900 IN RRSIG NS 5 2 900 20120926080227 20120628080227 17166 nox.su. mW24zzrZxDEfhP1hV5fzZWH+klT9bugHoT2t0Xh2s8a7HwlgQFp7Db3X tNb96CvCUtfiZaL4DigZ6YWPQHCxQQgxZGBg7HGfcGGvhLsXq2Qo7osy twQmEltKVL6kv4OeDvFV4SceUM2Axz3WP+09yX6e8Z+//aeO2SawqACs rBQ=

  • 6. 30th June 2012, 12:13 // Александр Венедюхин ответил:

    Ну так это правильно. Для DANE-овских записей, если с ANY, нужно спросить:

    $ dig ANY _443._tcp.dane.nox.su

    А вообще, ANY – не самый верный вариант, работает с переменным успехом: ответы длинные.

  • 7. 30th June 2012, 12:17 // Александр Венедюхин ответил:

    И там я случайно перенёс лишние записи в .dane.nox.su. (MX и пр.) – сейчас поправил, теперь цивильно.

  • 8. 9th January 2013, 00:30 // Читатель Pavel Zhovner написал:

    Странное дело. Адам Лэнгли, автор чернового rfc DANE и разработчик внедрявший его поддержку в хром, говорит что поддержка его хромом не будет полностью реализована, а та что имеется сейчас будет удалена в новых версиях. Объясняя это низки интересом к технологии.

    Обсуждение тут https://github.com/agl/dnssec-tls-tools/issues/4

    Как-то совсем нелогично, вроде только припихнули стандарт, и уже сворачивают.

  • 9. 9th January 2013, 11:12 // Александр Венедюхин ответил:

    > Странное дело. Адам Лэнгли,

    Да уж. Сомневаюсь, конечно, что ему не понравилось, как в итоге переделали DANE (а вышла очень логичная технология, если сравнить с тем, что предлагалось в начале). Но обидно.

  • 10. 9th January 2013, 14:54 // Читатель jno написал:

    Не, криво всё это.
    Так, попытки на верхних этажах поправить дырку в фундаменте…

    Вот переход, скажем, на IPv6-маршрутизацию даёт интересный результат на фоне зоопарка рутинговых приблуд IPv4, а тут – паллиативы.

  • 11. 10th January 2013, 00:38 // Читатель Pavel Zhovner написал:

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

    Появление DANE убивает этот бизнес. Может просто надавили?