/ Flickr / Jim Pennucci / CC
DNS-записи используются еще с 2013 года, но их применение носило скорее рекомендательный характер, потому центры сертификации (CA — certificate authorities) не были обязаны подчиняться этим правилам. Но вот участники форума CA/Browser, объединяющего создателей популярных браузеров и сертификационные компании, проголосовали за то, чтобы сделать процедуру проверки записи Certification Authority Authorization (CAA) частью процесса выдачи сертификата.
«CAA не станет «серебряной пулей», однако будет еще одним уровнем защиты», — рассказывает Скотт Хелме (Scott Helme), консультант по информационной безопасности.
Это требование вступит в силу 8 сентября, и те CA, которые не смогут его удовлетворить, рискуют получить штрафы. Таким образом, теперь центры сертификации должны будут в обязательном порядке проверять, что запросы на выдачу SSL/TLS-сертификата поступают от владельца домена.
Цель такого решения — снизить число случаев неавторизованной выдачи сертификатов при компрометации центра сертификации или взлома домена, когда злоумышленник может запросить валидный сертификат для скомпрометированного домена у любой сертификатной компании и впоследствии применить его для проведения MITM-атак или перенаправления пользователей на фишинговые ресурсы.
Для формирования записи владельцам доменов можно использовать инструмент CAA Record Generator, который автоматически сгенерирует правильные командные строки.
Дополнением к тегу issue, определяющему легитимных CA, запись будет поддерживать тег iodef, проверка которого также окажется обязательной. Этот тег позволит владельцу домена определить адреса электронной почты или URL, куда CA должны будут отправлять уведомления о подозрительных запросах на сертификаты.
P.S. Вот еще несколько материалов по теме из блога IaaS-провайдера 1cloud:
Комментарии (23)
Erelecano
18.04.2017 20:04К сожалению пока у крупных регистраторов и ДНС-хостеров записи типа CAA не поддерживаются. Сам я использую namecheap, в феврале писал в их поддержку вопрос про CAA, мне было отвечено, что «да, планируется скоро добавить, мы вас известим», но вот уже апрель заканчивается, а воз и ныне там.
mxms
19.04.2017 23:02Хороший повод установить собственный primary DNS.
Erelecano
20.04.2017 11:20Когда я был молодым и зеленым админом, а 99% здесь комментирующих ходили под стол и под себя, я держал свои NS'ы, я держал свои MX'ы и считал, что это очень круто. Но потом я понял, что я не могу обеспечить достаточной надежности работы своих NS'ов и MX'ов, даже не смотря на то, что у меня есть проекты, у которых за последние 3-4 года доступность 100% я понимаю, что моя надежность по определению ниже, чем надежность ДНС-хостеров и почтовых хостеров, а потому я предпочитаю использовать готовые решения для подобных целей.
И, да. ну поднимете вы свой праймари и что? А слейв у вашего хостера выпучит глаза и скажет «Какой еще CAA?» и не сможет подтянуть зону.mxms
20.04.2017 11:27Ну безусловно, провайдеры DNS имеют более высокую надёжность иначе за что бы им брать деньги.
Однако, во-первых, это деньги, а, во-вторых, как вы верно выше подметили, посредственная функциональность. К примеру, я не смог найти устраивающий меня вариант с поддержкой DNSSEС и возможностью ротации ключей при наличии API, покрывающего весь набор взаимодействий с DNS.
Пришлось поднимать свой.
Касаемо secondary, тут тут с поддержкой всё намного лучше, поскольку это просто AXFR, который высасывает всё, что ему отдают. И выбор NS хостера это, обычно, не лучший вариант. В то же время, к примеру, бесплатный afraid.org прекрасно поддерживает всё, включая DNSSEC и этот самый CAA.
~ # host -t ns kostikov.co kostikov.co name server ns2.afraid.org. kostikov.co name server beta.peek.ru. ~ # host -t caa kostikov.co kostikov.co has CAA record 0 iodef "mailto:abuse@peek.ru" kostikov.co has CAA record 0 issue "letsencrypt.org" kostikov.co has CAA record 0 issuewild ";"Erelecano
20.04.2017 14:42Я, для всех своих проектов, использую namecheap и как регистратора, и как днс-хостера, их надежность для меня достаточна. Да, мне сейчас не хватает CAA, но как я уже писал выше на мой запрос был ответ явно не автоматом, а живым человеком, что они знают о данном типе записи и они ее скоро добавят.
А по поводу того, что это просто AXFR… Ну я вот не знаю, как отреагирует какой-нибудь pdns или bind если ему попробовать отдать непонятные ему типы зон, никогда не пробовал, если честно.mxms
20.04.2017 14:49Нормально отреагирует, если не совcем уж древний. Но всегда можно проверить поставив experimentum crucis.
kolodkin
18.04.2017 20:36Теперь нельзя будет получить сертификат LetsEncript на басплатный адресс выданный сервисом типа http://freedns.afraid.org/?
sumanai
18.04.2017 21:01Очевидно, только если владелец домена разместит запись, разрешающую другой центр сертификации. При отсутствии какой-либо записи CAA скорее всего будет применена разрешающая политика, так как далеко не все DNS её поддерживают.
journeym
19.04.2017 12:32На этом CA/Browser какие-то странные ребята сидят. Сначала они режут порты по которым почжно чекать владелец ли ты сайта, теперь этот бред. Это все равно не поможет с фишингом справится.
el777
Хорошая идея.
Но вопрос такой — DNS самое слабое звено здесь. Есть случаи "отравления" кеша резолвера, когда он начинает резолвить совсем не так как надо. Одна из задач SSL — как раз верификация домена, что он именно тот, за кого себя выдает. DNS в силу дизайна и появления задолго до описанных проблем задачу решить не может, она решается с помощью SSL.
И теперь мы пытаемся повысить надежность SSL-верификации с помощью DNS.
sumanai
DNSSEC разве не решит эту проблему?
el777
когда будет внедрен повсеместно )
vesper-bot
Вообще-то для этого придумали DNSSEC. Мало того, что CAA, что клиентская сторона TLSA рекомендуют использовать DNSSEC для верификации соответствующих записей.
el777
В каком году он придуман?
Как часто он вам встречается в 2017?
vesper-bot
Не помню. Кажется, в 2014м его ещё не было, но тогда я в DNS так глубоко не закапывался — есть, работает, и хватит с меня. Сейчас видел в одном месте точно, но по чужим серверам не ходил, чтобы искать у остальных. Кроме того, оба RFC поддерживают fallback на текущую конфигурацию вида permit any any, а те, кто будут себе настраивать CAA и TLSA, заботясь о своей безопасности от атаки со стороны ЦС, будут поднимать DNSSEC, иначе у них это нормально работать не будет. И думаю, что технология будет-таки развиваться — DNS для этого самый подходящий хост, так как их обязательно надо держать доступными снаружи, и обязательно защищать достаточным образом, чтобы кто попало не мог их поломать. При этом большинство организаций, которые держат хотя бы публичный DNS-сервер, уже хотя бы как-то заботятся о его безопасности. А кто не заботится, тот уже ССЗБ.
el777
Я давно за ним слежу.
Первые разговоры пошли 18 лет назад(!) — в марте 1999. rfc2535.
12 лет назад в марте 2005 вышла новая спека — rfc4033.
Примерно 5 лет назад подписана зона .RU. За полгода всего 82 домена сделали подписи.
Думаете, в мире ситуация лучше?
Вот забавный сайт: https://dnssec-name-and-shame.com/domain/www.ietf.org
Судя по нему DNSSEC внедрен только в тех, кто сам его продвигает :)
25 крупнейших сайтов мира не используют.
vesper-bot
Хм. Познавательно :) и ссылка интересная. Обнаружил, что домен paypal.com решил внедрить у себя DNSSEC, возможно, в связи с отсутствием альтернатив.
Вообще, технология хотя и сыровата, но позволяет двойной контроль над защищенным соединением — сервер отдает сертификат, DNS TLSA+DNSSEC обеспечивает (если его проверять), что другой сертификат выдаст ошибку согласования TLS-соединения. В итоге одновременно строится доверие между клиентом и сервером с помощью ЦС, и указывается, какой именно должен быть ЦС (а то и вообще точный сертификат, какой вариант TLSA-записи настроен на этот сервер).
А вообще — как организация, эксплуатирующая сервер, может удостовериться, что при попытке зайти на их сервер клиент не попадет на поддельный сервер? Раньше было достаточно соглашения между ЦСами, что они не выдают сертификат на SSL без проверки запроса. LetsEncrypt это немного сломал, одновременно расширив границы использования SSL на довольно большой сегмент веб-сайтов. Нужна новая технология. Подняли старую (раз уж 1999 года идея), но не задействованную технологию, решили её поддерживать и форсить. Почему бы и нет? Делать-то надо сейчас.
el777
При этом начал подтверждать сайты по DNS.
mxms
Собственно, она уже есть и называется DANE.
Однако, несмотря на то, что стандарту уже несколько лет, внедрение его в программное обеспечение идёт крайне вяло. Браузеры так вообще, судя по всему не планируют поддержку DANE в обозримой перспективе. Оно и понятно. DANE способен похоронить большую часть бизнеса CA по выпуску сертификатов а он, как известно, активно спонсирует разработчиков браузеров.
Поэтому внедрение CAA это двоякая вещь. С одной стороны, вроде бы повышается безопасность, а с другой — поддерживается олигополия CA на выпуск сертификатов.
vesper-bot
Есть один минус у этого сайта — не дает проверить, подписан ли домен первого уровня, иначе невозможно подписать домены следующих уровней. Может, скажем, .de не подписан — и всё, никаких вам google.de или, скажем, t-mobile.de.
el777
Это полушуточный сайт.
Есть серьезная проверялка: https://dnssec-debugger.verisignlabs.com/habrahabr.ru
По факту многие зоны уже подписаны — http://stats.research.icann.org/dns/tld_report/
mxms
Да почти все основные. Реальная проблема сейчас это то, что многие регистраторы поддерживают крайне ограниченный набор доменов первого уровня, для которых можно передать отпечаток KSK. Тут в положительную сторону отличается Gandi, который предоставляет возможность внедрить DNSSEC для большого количества доменов.