Войти
Аутентификация именованных объектов на основе DNS (DANE ) - это протокол Интернет-безопасности, разрешающий X.509 цифровые сертификаты, обычно используемые для Transport Layer Security (TLS), для привязки к доменным именам с использованием расширений безопасности системы доменных имен ( DNSSEC).
Предлагается в RFC 6698 как способ аутентификации объектов клиента и сервера TLS без центра сертификации (CA ). Он дополнен руководством по эксплуатации и развертыванию в RFC 7671. Применение DANE для конкретных приложений определено в RFC 7672 для SMTP и RFC 7673 для использования DANE с Служебные записи (SRV).
Шифрование TLS / SSL в настоящее время основано на сертификатах, выданных центрами сертификации (центры сертификации). В течение последних нескольких лет ряд провайдеров CA пострадали от серьезных нарушений безопасности, что позволило выдавать сертификаты для хорошо известных доменов тем, кто не владеет этими доменами. Доверие к большому количеству центров сертификации может быть проблемой, потому что любой взломанный центр сертификации может выдать сертификат для любого доменного имени. DANE позволяет администратору доменного имени сертифицировать ключи, используемые в клиентах или серверах TLS этого домена, сохраняя их в системе доменных имен (DNS). Для работы модели безопасности DANE требуется, чтобы записи DNS были подписаны с помощью DNSSEC.
Кроме того, DANE позволяет владельцу домена указывать, какой ЦС может выдавать сертификаты для определенного ресурса, что решает проблему того, что любой ЦС может выдавать сертификаты для любого домена.
DANE решает аналогичные проблемы, такие как:
Однако, в отличие от DANE, эти технологии широко поддерживаются браузерами.
До недавнего времени не существовало широко применяемого стандарта для передачи зашифрованной электронной почты. Отправка электронной почты не зависит от безопасности; не существует схемы URI для обозначения безопасного SMTP. Следовательно, большая часть электронной почты, которая доставляется по TLS, использует только гибкое шифрование. Поскольку DNSSEC обеспечивает аутентифицированный отказ в существовании (позволяет преобразователю подтвердить, что определенное доменное имя не существует), DANE обеспечивает инкрементный переход к проверенному зашифрованному SMTP без каких-либо других внешних механизмов, как описано в RFC 7672. Запись DANE указывает, что отправитель должен использовать TLS.
Кроме того, существует черновик для применения DANE к S / MIME и RFC 7929 стандартизирует привязки для OpenPGP.
TLSA RR (запись ресурса) для службы находится в DNS-имени, которое указывает, что ограничения сертификата должны применяться к службам на определенном порту TCP или UDP. По крайней мере, один из TLSA RR должен обеспечивать проверку (путь) для сертификата, предлагаемого службой по указанному адресу.
Не все протоколы одинаково обрабатывают совпадение общих имен. HTTP требует, чтобы общее имя в сертификате X.509, предоставляемом службой, соответствовало независимо от того, насколько TLSA подтверждает его действительность. SMTP не требует совпадения общего имени, если значение использования сертификата равно 3 (DANE-EE), но в противном случае требует совпадения общего имени. Важно проверить, есть ли конкретные инструкции для используемого протокола.
Сам RR имеет 4 поля данных, описывающих, какой уровень проверки предоставляет владелец домена.
Например. _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64 ==
Первое поле после текста TLSA в DNS RR указывает, как проверить сертификат.
| RR указывает. на якорь доверия | RR указывает на. сертификат конечного объекта,. т.е. конкретный сертификат., используемый в TLS | |
|---|---|---|
| Требовать проверки PKIX | 0 | 1 |
| Проверка пути PKIX не требуется | 2 | 3 |
При подключении к службе и получении сертификата в поле выбора указывается, какой его части должны быть проверены.
Фактический данные, которые будут сопоставлены с учетом настроек других полей. Это длинная «текстовая строка» шестнадцатеричных данных.
Сертификат 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
