Базовая инфраструктура, которая сделала бы это возможным, существует и называется DNS-аутентификацией именованных объектов (DANE) и указана в RFC6698 . Это работает с помощьюTLSA записи ресурса, которая указывает сертификат или его открытый ключ конечного объекта или один из его CA в цепочке (на самом деле существует четыре различных типа, подробности см. В RFC).
Принятие
Дейн, однако, еще не получил широкого распространения. VeriSign контролирует внедрение DNSSEC и DANE и отслеживает их рост с течением времени :
Для сравнения, согласно данным VeriSign, существует около 2,7 миллиона DNS-зон, что означает, что чуть более 1% всех зон имеют хотя бы одну запись TLSA.
Я не могу дать никакого авторитетного ответа, почему DANE, но вот мои предположения:
DANE страдает от той же проблемы, что и списки отзыва сертификатов (CRL) и сетевой протокол статуса сертификата (OCSP). Для проверки действительности представленного сертификата необходимо связаться с третьей стороной. Ханно Бёк дает хороший обзор , почему это большая проблема на практике. Это сводится к вопросу о том, что делать, когда вы не можете связаться с третьей стороной. В этом случае поставщики браузеров предпочли мягкий отказ (иначе разрешение), что сделало все это довольно бессмысленным, и в итоге Chrome решил отключить OCSP в 2012 году.
DNSSEC
Возможно, DNS предлагает гораздо лучшую доступность, чем серверы CRL и OCSP в центрах сертификации, но все же делает невозможной автономную проверку. Кроме того, DANE следует использовать только вместе с DNSSEC. Так как обычный DNS работает по протоколу UDP, не прошедшему проверку подлинности, он весьма подвержен фальсификации, атакам MITM и т. Д. Принятие DNSSEC намного лучше, чем принятие DANE, но все еще далеко от повсеместного распространения.
И с DNSSEC мы снова сталкиваемся с проблемой мягкого сбоя. Насколько мне известно, ни одна из основных серверных / клиентских операционных систем не предоставляет проверяющий распознаватель DNSSEC по умолчанию.
Тогда есть также проблема отзыва. DNSSEC не имеет механизма отзыва и вместо этого использует недолговечные ключи.
Поддержка программного обеспечения
Все участвующее программное обеспечение должно поддерживать DANE.
Теоретически, вы можете подумать, что это будет задачей криптографических библиотек, и разработчикам приложений не придется много делать, но фактом является то, что криптографические библиотеки обычно предоставляют только примитивы, а приложения должны выполнять большую часть конфигурации и настройки самостоятельно. (и, к сожалению, есть много способов ошибиться).
Я не знаю, что какой-либо крупный веб-сервер (например, Apache или nginx), например, внедрил DANE или планирует сделать это. Веб-серверы имеют здесь особое значение, потому что все больше и больше материалов основано на веб-технологиях, и поэтому они часто являются первыми, где что-то реализуется.
Когда мы смотрим на CRL, OCSP и OCSP Stapling в качестве сравнения, мы можем сделать вывод о том, как пойдет история внедрения DANE. Только некоторые приложения, использующие OpenSSL, libnss, GnuTLS и т. Д., Поддерживают эти функции. Основному программному обеспечению, такому как Apache или nginx, потребовалось некоторое время, чтобы поддержать его, и, снова обращаясь к статье Ханно Бека, они ошиблись, и их реализация имеет недостатки. Другие крупные программные проекты, такие как Postfix или Dovecot , не поддерживают OCSPи имеют очень ограниченную функциональность CRL, в основном указывающую на файл в файловой системе (который не обязательно перечитывается регулярно, поэтому вам придется перезагрузить сервер вручную и т. д.). Имейте в виду, что это проекты, которые часто используют TLS. Затем вы можете начать смотреть на вещи, где TLS встречается гораздо реже, например, на PostgreSQL / MySQL, и, возможно, они в лучшем случае предлагают CRL.
Так что я даже не использую его на современных веб-серверах, и большинство других программ даже не имеют возможности реализовать OCSP и CRL, удачи вам с вашим пятилетним корпоративным приложением или устройством.
Потенциальные приложения
Итак, где вы могли бы использовать DANE? На данный момент не в общем Интернете. Если вы управляете сервером и клиентом, возможно, это вариант, но в этом случае вы часто можете прибегнуть к закреплению с открытым ключом.
В почтовом пространстве DANE набирает обороты, потому что SMTP долгое время не имел никакого аутентифицированного транспортного шифрования. SMTP-серверы иногда использовали TLS между собой, но не проверяли, действительно ли совпадают имена в сертификатах, теперь они начинают проверять это через DANE.