Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Протоколы интернет-безопасности
Ключевой менеджмент
Уровень приложения
система доменных имен
Интернет-уровень

Аутентификация именованных объектов на основе DNS ( DANE ) - это протокол безопасности в Интернете , позволяющий привязать цифровые сертификаты X.509 , обычно используемые для безопасности транспортного уровня (TLS), к доменным именам с помощью расширений безопасности системы доменных имен (DNSSEC). [1]

Он предлагается в RFC  6698 как способ аутентификации объектов клиента и сервера TLS без центра сертификации ( CA ). Он дополнен руководством по эксплуатации и развертыванию в RFC 7671 . Использование DANE в конкретных приложениях определено в RFC 7672 для SMTP и RFC 7673 для использования DANE с записями службы (SRV) .   

Обоснование [ править ]

В настоящее время шифрование TLS / SSL основано на сертификатах, выданных центрами сертификации (ЦС). В течение последних нескольких лет ряд провайдеров ЦС пострадали от серьезных нарушений безопасности , что позволило выдавать сертификаты для хорошо известных доменов тем, кто не владеет этими доменами. Доверие к большому количеству центров сертификации может быть проблемой, потому что любой взломанный центр сертификации может выдать сертификат для любого доменного имени. DANE позволяет администратору доменного имени сертифицировать ключи, используемые в клиентах или серверах TLS этого домена, сохраняя их в системе доменных имен (DNS). Для работы модели безопасности DANE требуется, чтобы записи DNS были подписаны с помощью DNSSEC.

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

DANE решает аналогичные проблемы:

Сертификат прозрачности
Обеспечение того, чтобы мошеннические центры сертификации не могли выдавать сертификаты без разрешения владельца домена, не будучи обнаруженными
Авторизация центра сертификации DNS
Ограничение того, какие центры сертификации могут выдавать сертификаты для данного домена

Однако, в отличие от DANE, эти технологии широко поддерживаются браузерами.

Шифрование электронной почты [ править ]

До недавнего времени не существовало широко применяемого стандарта для зашифрованной передачи электронной почты . [2] Отправка электронной почты не зависит от безопасности; нет схемы URI для обозначения безопасного SMTP. [3] Следовательно, большая часть электронной почты, которая доставляется по TLS, использует только гибкое шифрование . [4] Поскольку DNSSEC обеспечивает аутентифицированный отказ в существовании (позволяет преобразователю проверять, что определенное доменное имя не существует), DANE обеспечивает постепенный переход к проверенному зашифрованному SMTP без каких-либо других внешних механизмов, как описано в RFC 7672 . Запись DANE указывает, что отправитель должен использовать TLS. [3] 

Кроме того, проект существует для применения к DANE S / MIME , [5] и RFC 7929 стандартизирует привязки для OpenPGP . [6] 

Поддержка [ править ]

Приложения [ править ]

  • Google Chrome не поддерживает DANE, поскольку Google Chrome хочет исключить использование 1024-битного RSA в браузере [7] (DNSSEC ранее использовал 1024-битный RSA-подписанный корень, [8] и многие зоны все еще подписаны 1024-битным RSA бит RSA). По словам Адама Лэнгли, код был написан [9] и, хотя сегодня его нет в Chrome [10], он остается доступным в виде надстройки. [11]
  • Mozilla Firefox (до версии 57) имеет поддержку через надстройку. [12]
  • GNU Privacy Guard Позволяет получать ключи через OpenPGP DANE (--auto-key-locate). Новая опция - печать датских записей. (версия 2.1.9) [13]

Серверы [ править ]

  • Постфикс [14]
  • PowerMTA [15]
  • Галон [16] [17]
  • Exim [18]

Услуги [ править ]

  • Posteo [19]
  • Тутанота [20]

Библиотеки [ править ]

  • OpenSSL [21]
  • GnuTLS [22]

TLSA RR [ править ]

TLSA RR (запись ресурса) для службы находится в DNS-имени, которое указывает, что ограничения сертификата должны применяться к службам на определенном порту TCP или UDP. По крайней мере, одна из записей TLSA RR должна обеспечивать проверку (путь) для сертификата, предлагаемого службой по указанному адресу.

Не все протоколы одинаково обрабатывают сопоставление общих имен. HTTP требует, чтобы общее имя в сертификате X.509, предоставляемом службой, совпадало, независимо от того, насколько TLSA подтверждает его действительность. SMTP не требует совпадения общего имени, если значение использования сертификата равно 3 (DANE-EE), но в противном случае требует совпадения общего имени. Важно проверить, есть ли конкретные инструкции для используемого протокола.

Поля данных RR [ править ]

Сам RR имеет 4 поля данных, описывающих, какой уровень проверки предоставляет владелец домена.

  • поле использования сертификата
  • поле селектора
  • поле типа соответствия
  • данные ассоциации сертификатов

Например _25._tcp.somehost.example.com. TLSA 3 1 1 0123456789ABCDEF

Использование сертификата [ править ]

Стоимость использования сертификата

Проверка пути PKIX		Цель RR
Якорь доверияКонечная сущность
Необходимый01
Не требуется23

Первое поле после текста TLSA в DNS RR указывает, как проверить сертификат.

  • Значение 0 соответствует тому, что обычно называется ограничением CA (и PKIX-TA). Сертификат, предоставленный при установке TLS, должен быть выдан указанным корневым ЦС или одним из его промежуточных ЦС с действительным путем сертификации к корневому ЦС, которому уже доверяет приложение, выполняющее проверку. Запись может просто указывать на промежуточный ЦС, и в этом случае сертификат для этой службы должен поступать через этот ЦС, но вся цепочка до доверенного корневого ЦС должна оставаться действительной. [а]
  • Значение 1 соответствует тому, что обычно называется ограничением сертификата службы (и PKIX-EE). Используемый сертификат должен точно соответствовать записи TLSA, а также должен пройти проверку пути сертификации PKIX в доверенный корневой центр сертификации.
  • Значение 2 соответствует так называемому утверждению якоря доверия (и DANE-TA). Используемый сертификат имеет действительный путь сертификации, указывающий обратно на сертификат, упомянутый в этой записи, но ему нет необходимости передавать проверку пути сертификации PKIX доверенному корневому ЦС.
  • Значение 3 соответствует так называемому сертификату, выданному доменом (и DANE-EE). Сервисы используют самозаверяющий сертификат. Он не подписан кем-либо еще, и это именно эта запись.

Селектор [ править ]

При подключении к сервису и получении сертификата в поле селектора указывается, какие его части следует проверить.

  • Значение 0 означает выбор всего сертификата для сопоставления.
  • Значение 1 означает выбор только открытого ключа для сопоставления сертификата. Часто бывает достаточно сопоставления открытого ключа, поскольку он может быть уникальным.

Тип соответствия [ править ]

  • Тип 0 означает, что вся выбранная информация присутствует в данных ассоциации сертификатов .
  • Тип 1 означает выполнение хеширования выбранных данных SHA-256.
  • Тип 2 означает выполнение хеширования выбранных данных SHA-512.

Данные ассоциации сертификата [ править ]

Фактические данные, которые необходимо сопоставить с учетом настроек других полей. Это длинная «текстовая строка» шестнадцатеричных данных.

Примеры [ править ]

Сертификат HTTPS для www.ietf.org указывает, что необходимо проверять хэш SHA-256 открытого ключа предоставленного сертификата, игнорируя любые CA.

_443._tcp.www.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

Их почтовый сервис имеет такой же сертификат и TLSA.

ietf.org. MX 0 mail.ietf.org._25._tcp.mail.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

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

_25._tcp.mail.alice .example . TLSA 3 0 1 AB9BEB9919729F3239AF08214C1EF6CCA52D2DBAE788BB5BE834C13911292ED9

Стандарты [ править ]

  • RFC  6394 Примеры использования и требования для аутентификации именованных объектов на основе DNS (DANE)
  • RFC  6698 Аутентификация именованных объектов на основе DNS (DANE) Протокол безопасности транспортного уровня (TLS): TLSA
  • RFC  7218 Добавление сокращений для упрощения разговоров об аутентификации именованных объектов на основе DNS (DANE)
  • RFC  7671 Протокол аутентификации именованных объектов на основе DNS (DANE): обновления и руководство по эксплуатации
  • RFC  7672 Безопасность SMTP через альтернативную аутентификацию именованных объектов на основе DNS (DANE) Безопасность транспортного уровня (TLS)
  • RFC  7673 Использование аутентификации именованных объектов на основе DNS (DANE) Записи TLSA с записями SRV
  • RFC  7929 Привязки аутентификации именованных объектов (DANE) на основе DNS для OpenPGP

См. Также [ править ]

  • Авторизация центра сертификации DNS

Примечания [ править ]

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

Ссылки [ править ]

  1. ↑ Барнс, Ричард (6 октября 2011 г.). «DANE: переход TLS-аутентификации на новый уровень с помощью DNSSEC» . Журнал IETF . Проверено 5 августа 2018 года .
  2. ^ «Поддержка Postfix TLS - Безопасная проверка сертификата сервера» . Postfix.org . Проверено 30 декабря 2015 .
  3. ^ а б Духовные; Хардейкер (28.07.2013). DANE для SMTP (PDF) . Протоколы IETF 87. IETF.
  4. ^ Filippo Valsorda (2015-03-31). «Печальное состояние SMTP-шифрования» . Проверено 30 декабря 2015 .
  5. ^ Использование безопасного DNS для связывания сертификатов с доменными именами для S / MIME . IETF . 2015-08-27. ID draft-ietf-dane-smime-09.
  6. Перейти ↑ Wouters, P. (август 2016). Аутентификация на основе DNS привязок именованных объектов (DANE) для OpenPGP . IETF . DOI : 10,17487 / RFC7929 . RFC 7929 . Проверено 14 сентября 2016 .
  7. ^ Лэнгли, Адам (2015-01-17). «ImperialViolet - Почему не DANE в браузерах» . www.imperialviolet.org . Проверено 24 марта 2017 .[ самостоятельно опубликованный источник ]
  8. ^ Duane Wessels, Verisign (2016-05-16). «Увеличение ключа подписи сильной зоны для корневой зоны» . Verisign.com . Проверено 29 декабря 2016 .
  9. ^ Адам Лэнгли (2012-10-20). "Сертификаты сшитые DANE" . ImperialViolet . Проверено 16 апреля 2014 .[ самостоятельно опубликованный источник ]
  10. ^ Адам Лэнгли (2011-06-16). «HTTPS с проверкой подлинности DNSSEC в Chrome» . ImperialViolet . Проверено 16 апреля 2014 .[ самостоятельно опубликованный источник ]
  11. ^ Как добавить поддержку DNSSEC в Google Chrome
  12. ^ "Валидатор DNSSEC / TLSA" . Архивировано из оригинала на 2018-06-02 . Проверено 30 апреля 2014 .
  13. ^ "Выпущен GnuPG 2.1.9" . gnupg.org . Проверено 10 октября 2015 .[ самостоятельно опубликованный источник ]
  14. ^ "Поддержка Postfix TLS - DANE" . Postfix.org . Проверено 16 апреля 2014 .
  15. ^ "Версия PowerMTA 5.0" . SparkPost.com . Проверено 26 апреля 2020 .
  16. ^ Якоб Шлайтер, Кирей AB. "ДАНЕ" (PDF) . РТР-ГмбХ . Проверено 17 декабря 2015 .
  17. ^ "Поддержка Halon DANE" . Halon Security AB . Проверено 17 декабря 2015 .[ самостоятельно опубликованный источник ]
  18. ^ "Спецификация Exim 4.91: Зашифрованные соединения SMTP с использованием TLS / SSL / 15. DANE" . exim.org . Проверено 5 июля 2018 .
  19. ^ Скатурро, Майкл (2014-08-24). «Защитите свою электронную почту по-немецки» . Хранитель . Проверено 29 апреля 2018 . ... В мае прошлого года [Posteo] стал первым в мире провайдером электронной почты, внедрившим аутентификацию именованных сущностей на основе DNS (датчанин) на своих серверах. ...
  20. ^ ДЭЙН Везде ?! Давайте снова сделаем Интернет частным местом , tutanota.de , получено 17 декабря 2015 г.[ самостоятельно опубликованный источник ]
  21. ^ Ричард Левитт (07.01.2016). «ДАННЫЕ ИЗМЕНЕНИЯ» . Проверено 13 января 2016 .[ самостоятельно опубликованный источник ]
  22. ^ «Проверка сертификата с помощью DANE (DNSSEC)» . Gnu.org.[ самостоятельно опубликованный источник ]

Внешние ссылки [ править ]

  • DNSSEC не нужен - против DNSSEC
  • Для DNSSEC - опровержение пунктов «Против DNSSEC»
  • Список тестовых сайтов DANE
  • Онлайн-инструмент для проверки почтовых серверов на поддержку DNSSEC и DANE
  • Иллюстрированная пропаганда DANE со ссылками на инструкции и инструменты