Комментарии 6
TLS и на клиенте, и не сервере
Исправьте, пожалуйста)
В DNS сложно строго сопоставить имена серверов: конкретный контекст DNS-запроса никакого имени сервера не предусматривает - запрос отправляется по IP-адресу.
Что же мешает в сертификате указать IP-адрес?
Чисто технически - ничто не мешает: вписать IP-адрес в сертификат несложно, это предусмотрено форматом. Но, если говорить про имеющиеся "хорошо известные УЦ", то сертификаты для IP-адресов выпускают неохотно, так как есть трудности с надёжной проверкой права управления адресом, а также с сопровождением. Впрочем, Let's Encrypt вот обещают для всех в этом году сделать автоматические короткоживущие TLS-сертификаты на IP-адреса. Поскольку там есть механизм подтверждения чисто по TLS, то можно будет в прозрачном режиме привестить ACME-проверку к DoT, не поднимая ненужного веб-сервера.
Однако, если про использование УЦ, то есть другие особенности. Проверка соответствия IP-адресов потребует ввести доверие инфраструктуре УЦ ещё и для DNS, что создаст очень нехорошую зависимость от работы и политик этих УЦ; а DNS, всё же, фундамент Интернета. Если же доверие УЦ не предусматривать, то, при активной атаке, подменить сертификат, выпущенный для IP-адреса, даже проще, чем сертификат для DNS-имён: имена нужно как-то узнать для конкретной сессии, до подмены, а IP-адрес сервера - заранее известен.
Я не понимаю как это должно работать. В принципе можно вообразить атаку на сервера УЦ с подменой IP на BGP где-нибудь в транзите. В отличии от корневых DNS, маршруты до которых хорошо защищены и чьи сертификаты заранее всем известны, распределение маршрутов и расположение AS не так хорошо контролируется. Да и вообще IP это сеть доверия под контролем ICAN в отличии от строго вертикальной системы DNS.
Можно пытаться распределять сертификаты сверху вниз через механизм похожий на делегирование через NS, но из этой схемы выпадают рекурсеры.
То что хотят сделать Let's Encrypt это скорее проблема защиты канала общения, но не задача подтверждения источника как в https. Т.е. от MITM это не защищает в полной мере.
В принципе можно вообразить атаку на сервера УЦ
Атаковать валидатор УЦ необязательно. Чтобы клиент мог поверить подписи в сертификате - этот клиент должен верить в ключи УЦ, которым сертификат выпущен. Соответственно, ключи откуда-то нужно взять. Если же у клиента таких доверенных ключей нет и в сертификате подпись он проверяет просто, "чтобы сходилось", то перехватывающий узел может выпустить и подписать свой сертификат, который будет предназанчен именно для конкретной сессии (это нетрудно - сертификат выпускается за какие-то десятки миллисекунд).
Если клиент дополнительно сверяет имя в сертификате с именем, которое заранее известно клиенту, то перехватывающему узлу нужно подходящее имя вписать в подставной сертификат, а для этого имя нужно как-то выяснить. Это не всегда просто сделать: то есть, можно ожидать, что какое-то имя есть в поле SNI начального сообщения TLS, но, во-первых, для DoT тут есть оговорки; во-вторых, придётся парсить TLS-сессию и сообщения. Для IP-адреса - всё проще: он заранее известен, так что и сертификат можно заранее заготовить.
В отличии от корневых DNS, маршруты до которых хорошо защищены
У корневых DNS-серверов очень много локальных узлов, которые расставлены по разным местам Интернета. Какие-то исключительные особо эффективные методы защиты для маршрутов там не применяются, да их и не получится применять для всех локальных узлов. Всё в общем порядке. Да, собственно, BGP везде примерно одинаково "защищён" сейчас.
Но тут важно другое: с точки зрения обычного клиентского подключения (а не межсетевого взаимодействия на уровне AS), в IP-сетях всякий промежуточный узел может ответить вместо "оконечного", соответственно, для активной атаки лишь нужно "встать в разрыв"; ну и вот разные "угоны маршрутов" - лишь служат для того, чтобы петлёй закинуть к себе "хопы", которые в штатном режиме - "чужие" (то есть, должны были бы быть в других сетях). С DNS тут даже хуже, потому что распространённый доступ тут по UDP. Так что для защиты протоколов, работающих выше IP, в принципе нужны какие-то дополнительные меры, типа проверки ключей/подписей.
Можно пытаться распределять сертификаты сверху вниз через механизм похожий
Или просто использовать отпечатки ключей. Или, например, проверять отпечатки ключей и цепочки с валидацией DNSSEC. А исключительно TLS-cертификаты, да ещё и с привычной иерархией, для DoT вообще не очень подходят, на мой взгляд.
Как DNS работает через TLS: DNS-over-TLS на практике