/ Unsplash / Paulius Dragunas
Что такое DANE
Сертификационные центры (CA) — это организации, которые занимаются удостоверением криптографических SSL-сертификатов. Они ставят на них свою электронную подпись, подтверждая подлинность. Однако порой возникают ситуации, когда удостоверения выдаются с нарушениями. Например, в прошлом году Google инициировали «процедуру прекращения доверия» к сертификатам Symantec из-за их компрометации (подробно эту историю мы освещали в нашем блоге — раз и два).
Чтобы избежать таких ситуаций, несколько лет назад в IETF начали разрабатывать технологию DANE (но она не получила широкого распространения в браузерах — почему так получилось, поговорим далее).
DANE (DNS-based Authentication of Named Entities) — это набор спецификаций, который позволяет использовать DNSSEC (Name System Security Extensions) для контроля достоверности SSL-сертификатов. DNSSEC представляет собой расширение для системы доменных имен, которое минимизирует атаки, связанные с подменой адресов. Используя две эти технологии, веб-мастер или клиент могут обратиться к одному из операторов зон DNS и подтвердить валидность используемого сертификата.
По сути, DANE выступает в качестве самоподписанного сертификата (гарантом его надежности является DNSSEC) и дополняет функции CA.
Как это работает
Спецификация DANE описана в RFC6698. Согласно документу, в ресурсные записи DNS был добавлен новый тип — TLSA. Он содержит информацию о передаваемом сертификате, размерность и тип передаваемых данных, а также сами данные. Веб-мастер создает цифровой отпечаток сертификата, подписывает его с помощью DNSSEC и размещает в TLSA.
Клиент подключается к сайту в интернете и сравнивает его сертификат с «копией», полученной от DNS-оператора. Если они совпадают, то ресурс считается доверенным.
На wiki-странице DANE приведен следующий пример DNS-запроса к серверу example.org по TCP-порту 443:
IN TLSA _443._tcp.example.orgОтвет на него выглядит так:
_443._tcp.example.com. IN TLSA (
3 0 0 30820307308201efa003020102020... )
DANE имеет несколько расширений, которые работают с другими записями DNS помимо TLSA. Первое — DNS-запись SSHFP для проверки ключей при SSH-соединениях. Оно описано в RFC4255, RFC6594 и RFC7479. Второе — запись OPENPGPKEY для обмена ключами с помощью PGP (RFC7929). Наконец, третье — запись SMIMEA (в RFC стандарт не оформлен, есть только его черновик) для криптографического обмена ключами по S/MIME.
В чем проблема с DANE
В середине мая прошла конференция DNS-OARC (это некоммерческая организация, которая занимается вопросами безопасности, стабильности и развития системы доменных имён). На одной из панелей эксперты пришли к выводу, что технология DANE в браузерах провалилась (по крайней мере, в текущем варианте реализации). Присутствующий на конференции Джефф Хастон (Geoff Huston), ведущий научный сотрудник APNIC, одного из пяти региональных интернет-регистраторов, отозвался о DANE как о «мертвой технологии».
Популярные браузеры не поддерживают аутентификацию сертификатов с помощью DANE. На рынке встречаются специальные плагины, которые раскрывают функциональность TLSA-записей, однако и их поддержку постепенно прекращают.
Проблемы с распространением DANE в браузерах связывают с длительностью процесса валидации по DNSSEC. Система вынуждена производить криптографические расчеты для подтверждения подлинности SSL-сертификата и проходить по всей цепочке DNS-серверов (от корневой зоны до домена хоста) при первом подключении к ресурсу.
/ Unsplash / Kaley Dykstra
Этот недостаток пытались устранить в Mozilla с помощью механизма DNSSEC Chain Extension для TLS. Он должен был сократить количество DNS-записей, которые приходилось просматривать клиенту во время аутентификации. Однако внутри группы разработчиков возникли разногласия, которые разрешить не удалось. В итоге проект забросили, хотя он был одобрен IETF в марте 2018 года.
Еще одной причиной низкой популярности DANE считается слабая распространенность DNSSEC в мире — с ним работает всего 19% ресурсов. Эксперты посчитали, что этого недостаточно для активного продвижения DANE.
Скорее всего, индустрия будет развиваться в другом направлении. Вместо того чтобы использовать DNS для верификации сертификатов SSL/TLS, игроки рынка, наоборот, будут продвигать протоколы DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH). Последний мы упоминали в одном из наших предыдущих материалов на Хабре. Они шифруют и проверяют запросы пользователей к DNS-серверу, не давая злоумышленникам возможности подменить данные. В начале года DoT уже внедрили в Google для своего Public DNS. Что касается DANE — получится ли у технологии «вернуться в седло» и все же стать массовой, предстоит увидеть в будущем.
Что еще у нас есть для дополнительного чтения:
Как автоматизировать управление ИТ-инфраструктурой — обсуждаем три тренда
Как сэкономить с помощью прикладного программного интерфейса
Как работает техподдержка 1cloud
Комментарии (18)
sHaggY_caT
02.06.2019 08:51Эту проблему можно решить с помощью блокчейна. Да, тут тоже накладные расходы, но если это не специализированный блокчейн, а выполняющий и другие функции, то это не проблема, если данный блокчейн уже широко используется.
bm13kk
02.06.2019 13:54Блокчейн пока что не решил ни одной проблемьі. Вьі предлагаете его использовать в вопросе безопастности всего .
0xd34df00d
02.06.2019 16:16Просто надо еще диплернинг подключить.
sHaggY_caT
02.06.2019 19:28Блокчейн пока что не решил ни одной проблемьі. Вьі предлагаете его использовать в вопросе безопастности
Как это связано?
всего
Не всего, а DNS. Кстати, вместо DNS тоже можно юзать блокчейн. А на смартконтрактах организовать покупку доменных имён и их освобождение, перепродажу.
Revertis
02.06.2019 13:52Для начала, мне кажется, можно было бы ограничить национальные ЦА своими национальными доменами. Чтобы условный турецкий «TUBITAK Kamu SM SSL Sertifika Hizmet Saglayicisi» не мог выпустить сертификаты для условного google.com. То же самое с будущим российским ЦА, чтобы он был ограничен для ru/рф/su доменов.
Я думаю, что небольшую такую табличку добавить во все браузеры не составит труда (хотя, конечно, конкуренцию урежет).
Tangeman
02.06.2019 16:54Частично эту проблему решает CAA в DNS, но малоэффективно пока не защищено DNSSEC или аналогичными механизмами.
achekalin
02.06.2019 14:00Чаще вижу ситуацию, когда днс-серверы не позволяют создать даже CAA, не то что ещё какие-то новопоявившиеся днс-записи: чаще всего это ограничение веб-интерфейса хостера ДНС. И это, среди прочего, не всегда от лени, но ещё и от нежелание разбираться в сложных вещах при настройке простого по идее самого протокола ДНС-сервера. Т.е. здесь "работает — не трогай" играет против безопасности.
Подумать шире — и поймём, что настройка веб-морды (скорее ее обновление) мельчайшая из проблем. Если админы не разобрались, а оттого побаиваются подписывания днс-зон, то и использовать эти фичи даже на рекурсивных серверах они если и будут, то неохотно.
Ну а принудительно весь мир на dnssec перевести с 1 июля чего года, например — просто невозможно, интернет есть сеть, где рулят не законы, а настоятельные рекомендации (и почти нет наказаний за их нарушение). Переналадки ДНС же — дело тонкое, если что-то пойдет не так — мало не покажется, так что внедряет новшество очень немногие.
Tatikoma
02.06.2019 14:26DNS flag day вполне неплохо заставляет шевелиться админов с перенастройкой серверов.
Tangeman
02.06.2019 17:00Это больше пугалка чем шевелилка. Пока DNSSEC повсеместно не используется (а именно для него важны EDNS и DNS-over-TCP), ни первый, ни второй DNS Flag Day ровным счётом ничего не меняют для подавляющего большинства клиентов (и серверов) — т.е. всё что резолвилось раньше будет и дальше резолвится, разве что всех клиентских резолверов принудительно заставят использовать DNS-over-TCP для обычных запросов (что практически невероятно).
Evengard
Честно говоря я не очень понимаю, как DNS over TLS или DNS over HTTPS поможет против подделки каким-то DNS-сервером записей.
mxms
Правильный ответ — никак. Собственно это про защиту канала передачи данных от / к DNS и никак не заменяет DNSSEC / DANE.
YourChief
Есть возможность развития в этом направлении, она описана в этой статье в блоге APNIC. Если коротко — DoT может заменить DNSSEC если авторитативные серверы будут поддерживать DoT и отвечать по нему резолверам.
Zoomerman
Тут просто. Если DNS сервер будет работать по принципу HTTPS, то для получения надежного ответа, к нему нужно будет обращаться напрямую с использованием TLS. В этом случае ответ от сервера можно считать валидным, т.к. вероятность его подмены в пути очень мала.
Если TLSA записи передавать открытым текстом, то ничего не мешает на узле провайдера заменять данные своим сертификатом. Вкупе с возможностью организовать MiTM это вообще сводит к нулю идею HTTPS для сайтов.
DerRotBaron
В случае использования DNSSEC, с открытым текстом проблем нет, так как TLSA от MiTM не будут приняты. И точкой доверия в этом случае будут только авторитативные DNS.
В случае же с DoTLS/DOH с TLSA, но без DNSSEC к авторитативным серверам добавляется ещё и резолвер, которому нет проблем подменить сразу и A и TLSA.