Аутентификация именованных объектов на основе DNS
| Интернет-безопасность протоколы |
|---|
| Управление ключами |
| Прикладной уровень |
| Система доменных имен |
| Интернет-уровень |
Аутентификация именованных объектов на основе DNS ( DANE ) — это протокол безопасности Интернета , позволяющий привязывать X.509 цифровые сертификаты , обычно используемые для безопасности транспортного уровня (TLS), к доменным именам с помощью расширений безопасности системы доменных имен ( DNSSEC ). [1]
Это предлагается в RFC 6698 как способ аутентификации клиентских и серверных объектов TLS без центра сертификации ( CA ). Он дополнен руководством по эксплуатации и развертыванию в РФК 7671 . Использование DANE для конкретного приложения определено в RFC 7672 для SMTP и RFC 7673 для использования DANE со служебными (SRV) записями .
Обоснование
[ редактировать ]Шифрование TLS/SSL в настоящее время основано на сертификатах, выданных центрами сертификации (CA). В течение последних нескольких лет [ когда? ] , ряд провайдеров центров сертификации подверглись серьезным нарушениям безопасности , что позволило выдавать сертификаты для известных доменов тем, кто не владеет этими доменами. Доверие большому количеству центров сертификации может стать проблемой, поскольку любой взломанный центр сертификации может выдать сертификат для любого доменного имени. DANE позволяет администратору доменного имени сертифицировать ключи, используемые на клиентах или серверах TLS этого домена, сохраняя их в системе доменных имен (DNS). Для работы модели безопасности DANE необходимо, чтобы записи DNS были подписаны с помощью DNSSEC.
Кроме того, DANE позволяет владельцу домена указать, какому центру сертификации разрешено выдавать сертификаты для определенного ресурса, что решает проблему возможности любого центра сертификации выдавать сертификаты для любого домена.
DANE решает аналогичные проблемы:
- Прозрачность сертификата
- Обеспечение того, чтобы мошеннические центры сертификации не могли выдавать сертификаты без разрешения владельца домена, не будучи обнаруженными.
- Авторизация центра сертификации DNS
- Ограничение того, какие центры сертификации могут выдавать сертификаты для данного домена
Однако, в отличие от DANE, эти технологии широко поддерживаются браузерами.
Шифрование электронной почты
[ редактировать ]До недавнего времени не существовало широко внедренного стандарта для зашифрованной передачи электронной почты. [2] Отправка электронной почты не зависит от безопасности; не существует схемы URI для обозначения безопасного SMTP. [3] Следовательно, большая часть электронной почты, доставляемой по TLS, использует только оппортунистическое шифрование . [4] Поскольку DNSSEC обеспечивает аутентифицированное отрицание существования (позволяет распознавателю подтвердить отсутствие определенного доменного имени), DANE обеспечивает поэтапный переход к проверенному зашифрованному SMTP без каких-либо других внешних механизмов, как описано в РФК 7672 . Запись DANE указывает, что отправитель должен использовать TLS. [3]
Кроме того, RFC 8162 существует для применения DANE к S/MIME . [5] и RFC 7929 стандартизирует привязки для OpenPGP . [6]
Поддерживать
[ редактировать ]Приложения
[ редактировать ]- Google Chrome не поддерживает DANE, поскольку Google Chrome хочет исключить использование 1024-битного RSA в браузере. [7] (ранее DNSSEC использовал 1024-битный корень, подписанный RSA, [8] и многие зоны по-прежнему подписаны с помощью 1024-битного RSA, хотя в настоящее время по умолчанию используется 256-битный ECDSA. [9] ). По словам Адама Лэнгли, код был написан [10] и, хотя сегодня его нет в Chrome, [11] он остается доступным в виде дополнения. [12]
- Mozilla Firefox не поддерживает DANE. Судя по реакциям в заявках по теме («У нас нет планов по реализации этой функции»), DNSSEC и DANE в настоящее время рассматриваются разработчиками Mozilla как находящиеся вне сферы действия Firefox. [13] [14] Поддержка дополнений была доступна до Firefox 56 (последнее обновление — 2016 г.). [15] ), но больше не существует. Его больше нельзя реализовать с помощью более поздних и более ограничительных API-интерфейсов расширений Firefox. [16]
- GNU Privacy Guard Позволяет получать ключи через OpenPGP DANE (--auto-key-locate). Новая опция --export-options экспорт-дата. (версия 2.1.14) [17]
- Cheogram Android позволяет проверять через DANE и показывает статус, использовался ли DANE или нет. [18]
Серверы
[ редактировать ]Услуги
[ редактировать ]Библиотеки
[ редактировать ]TLSA РР
[ редактировать ]TLSA RR (запись ресурса) для службы расположена в DNS-имени, которое указывает, что ограничения сертификата должны применяться к службам на определенном порту TCP или UDP. По крайней мере, одна из записей TLSA должна предоставить подтверждение (путь) сертификата, предлагаемого службой по указанному адресу.
Не все протоколы обрабатывают сопоставление общих имен одинаково. HTTP требует, чтобы общее имя в сертификате X.509, предоставленном службой, совпадало независимо от того, подтверждает ли TLSA его действительность. SMTP не требует совпадений общего имени, если значение использования сертификата равно 3 (DANE-EE), но в противном случае требует совпадения общего имени. Важно проверить, существуют ли конкретные инструкции для используемого протокола.
Поля данных RR
[ редактировать ]Сам RR имеет 4 поля данных, описывающих, какой уровень проверки обеспечивает владелец домена.
Например _25._tcp.somehost.example.com. TLSA 3 1 1 0123456789ABCDEF
Использование сертификата
[ редактировать ]| PKIX-путь проверка |
Цель RR | |
|---|---|---|
| Доверительный якорь | Конечная сущность | |
| Необходимый | 0 | 1 |
| Не требуется | 2 | 3 |
Первое поле после текста TLSA в DNS RR указывает, как проверить сертификат.
- Значение 0 соответствует так называемому ограничению CA (и PKIX-TA). Сертификат, предоставленный при установке TLS, должен быть выдан указанным корневым центром сертификации или одним из его промежуточных центров сертификации с действительным путем сертификации к корневому центру сертификации, которому уже доверяет приложение, выполняющее проверку. Запись может просто указывать на промежуточный центр сертификации, и в этом случае сертификат для этой службы должен быть получен через этот центр сертификации, но вся цепочка до доверенного корневого центра сертификации должна оставаться действительной. [а]
- Значение 1 соответствует так называемому ограничению сертификата службы (и PKIX-EE). Используемый сертификат должен соответствовать записи TLSA, а также должен пройти проверку пути сертификации PKIX доверенному корневому центру сертификации.
- Значение 2 соответствует так называемому утверждению привязки доверия (и DANE-TA). Запись TLSA соответствует сертификату корневого центра сертификации или одного из промежуточных центров сертификации сертификата, используемого службой. Путь сертификации должен быть действительным вплоть до соответствующего сертификата, но доверенный корневой центр сертификации не требуется.
- Значение 3 соответствует так называемому сертификату, выданному доменом (и DANE-EE). Запись TLSA соответствует самому используемому сертификату. Используемый сертификат не требует подписи других сторон. Это полезно для самозаверяющих сертификатов, а также в тех случаях, когда у валидатора нет списка доверенных корневых сертификатов.
Селектор
[ редактировать ]При подключении к сервису и получении сертификата в поле селектора указывается, какие его части следует проверить.
- Значение 0 означает выбор всего сертификата для сопоставления.
- Значение 1 означает, что для сопоставления сертификатов необходимо выбрать только открытый ключ. Сопоставления открытого ключа часто бывает достаточно, поскольку он, скорее всего, будет уникальным.
Тип соответствия
[ редактировать ]- Тип 0 означает, что вся выбранная информация присутствует в данных ассоциации сертификата .
- Тип 1 означает выполнение хеширования SHA-256 выбранных данных.
- Тип 2 означает выполнение хэша SHA-512 выбранных данных.
Данные ассоциации сертификатов
[ редактировать ]Фактические данные, которые необходимо сопоставить с учетом настроек других полей. Это длинная «текстовая строка» шестнадцатеричных данных.
Примеры
[ редактировать ]Запись TLSA для www
_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 Привязки аутентификации именованных объектов на основе DNS (DANE) для OpenPGP
- RFC 4255. Использование DNS для безопасной публикации отпечатков ключей Secure Shell (SSH)
- RFC 8162: Использование безопасного DNS для связывания сертификатов с доменными именами для S/MIME
- Черновик: Оппортунистическое шифрование с семантикой DANE и IPsec: IPSECA [27]
См. также
[ редактировать ]Примечания
[ редактировать ]- ^ Необычный пример, когда это может быть полезно: вы не полностью доверяете корневому ЦС, но многие приложения все еще его используют, и вы доверяете определенному из промежуточных ЦС, поэтому вы указываете промежуточный ЦС и все равно получаете полная проверка пути доверия.
Ссылки
[ редактировать ]- ^ Самад, Мухаммад Алиф Адха Бин (6 октября 2011 г.). «DANE: переход TLS-аутентификации на новый уровень с помощью DNSSEC» . Журнал IETF . Проверено 5 августа 2018 г.
- ^ «Поддержка Postfix TLS — проверка сертификата безопасного сервера» . Postfix.org . Проверено 30 декабря 2015 г.
- ^ Jump up to: а б Духовный; Хардакер (28 июля 2013 г.). ДЕЙН для SMTP (PDF) . Протокол IETF 87. IETF.
- ^ Филиппо Вальсорда (31 марта 2015 г.). «Печальное состояние SMTP-шифрования» . Проверено 30 декабря 2015 г.
- ^ Хоффман, П. (май 2017 г.). Использование безопасного DNS для связывания сертификатов с доменными именами для S/MIME . IETF . дои : 10.17487/RFC8162 . RFC 8162 . Проверено 30 марта 2022 г.
- ^ Воутерс, П. (август 2016 г.). Привязки аутентификации именованных объектов на основе DNS (DANE) для OpenPGP . IETF . дои : 10.17487/RFC7929 . РФК 7929 . Проверено 14 сентября 2016 г.
- ^ Лэнгли, Адам (17 января 2015 г.). «ImperialViolet — Почему в браузерах нет DANE» . www.imperialviolet.org . Проверено 24 марта 2017 г. [ самостоятельный источник ]
- ^ Дуэйн Весселс, Verisign (16 мая 2016 г.). «Увеличение ключа подписи зоны прочности для корневой зоны» . Verisign.com . Проверено 29 декабря 2016 г.
- ^ «Руководство по DNSSEC для Bind9» . bind9.readthedocs.io . Проверено 22 августа 2021 г.
- ^ Адам Лэнгли (20 октября 2012 г.). «Сшитые сертификаты DANE» . Имперский Фиолетовый . Проверено 16 апреля 2014 г. [ самостоятельный источник ]
- ^ Адам Лэнгли (16 июня 2011 г.). «HTTPS с аутентификацией DNSSEC в Chrome» . Имперский Фиолетовый . Проверено 16 апреля 2014 г. [ самостоятельный источник ]
- ^ Как добавить поддержку DNSSEC в Google Chrome
- ^ «672600 — использовать цепочку DNSSEC/DANE, вшитую в рукопожатие TLS при проверке цепочки сертификатов» .
- ^ «1479423 — поддержка проверки DNSSEC/DANE/TLSA» .
- ^ Вебер, Йоханнес (25 октября 2016 г.). «Как использовать DANE/TLSA» . Веберблог.нет .
- ^ Валидатор DNSSEC/TLSA
- ^ «GnuPG — Примечания к выпуску» . gnupg.org. 12 июня 2021 г. Проверено 27 августа 2021 г. [ самостоятельный источник ]
- ^ "хеограмма-андроид 2.13.0-1" . Проверено 11 февраля 2021 г.
- ^ «Поддержка Postfix TLS — ДЕЙН» . Postfix.org . Проверено 16 апреля 2014 г.
- ^ «Выпуск PowerMTA 5.0» . SparkPost.com . Проверено 26 апреля 2020 г.
- ^ «Спецификация Exim 4.91: зашифрованные SMTP-соединения с использованием TLS/SSL/15. DANE» . exim.org . Проверено 5 июля 2018 г.
- ^ "mod_s2s_auth_dane_in" . prosody.im . Проверено 11 февраля 2024 г.
- ^ Скатурро, Майкл (24 августа 2014 г.). «Защитите свою электронную почту по-немецки» . Хранитель . Проверено 29 апреля 2018 г.
... В мае прошлого года [Posteo] стал первым в мире провайдером электронной почты, внедрившим на своих серверах аутентификацию именованных объектов на основе DNS (Dane). ...
- ^ ДЕЙН Везде?! Давайте снова сделаем Интернет частным местом , tutanota.de , получено 17 декабря 2015 г. [ самостоятельный источник ]
- ^ Ричард Левитт (07 января 2016 г.). «ДЕЙН МЕНЯЕТСЯ» . Гитхаб . Проверено 13 января 2016 г. [ самостоятельный источник ]
- ^ «Проверка сертификата с помощью DANE (DNSSEC)» . Гну.орг. [ самостоятельный источник ]
- ^ Остервейл, Эрик; Уайли, Глен; Окубо, Томофуми; Лаву, Рамана; Мохайсен, Азиз (6 июля 2015 г.). «Оппортунистическое шифрование с семантикой DANE и IPsec: IPSECA» . Рабочая группа по интернет-инжинирингу .
Внешние ссылки
[ редактировать ]- DNSSEC не нужен - Против DNSSEC
- За DNSSEC – опровержение пунктов раздела «Против DNSSEC».
- Список испытательных полигонов DANE
- Онлайн-инструмент для проверки почтовых серверов на наличие поддержки DNSSEC и DANE
- Иллюстрированная пропагандистская работа DANE со ссылками на инструкции и инструменты.