Dns caa что это
DNS-запись CAA. Зачем нужна и как использовать?
CAA (Certification Authority Authorization) — это новый тип DNS-записи, предназначенный для определения центров сертификации, которым разрешен выпуск SSL/TLS-сертификатов для определенного доменного имени или субдомена.
Крупнейшие и наиболее популярные центры сертификации договорились, что начиная с 8 сентября 2017 года в обязательном порядке строго следовать инструкциям, указанным в CAA-записях доменного имени или субдомена для которого запрашивается выпуск сертификата.
Использование CAA-записи позволит повысить уровень безопасности в сети Интернет и сократить случаи неавторизованного получения сертификатов для сторонних доменных имен.
Я подготовил подробную инструкцию, которая разъясняет возможности CAA-записи и формат ее использования.
Значение CAA-записи состоит из трех частей, разделенных пробелом:
Значение flag представляет собой 8-битное число, старший бит которого обозначает критичность понимания записи центром сертификации. В данный момент допустимы следующие значения:
Значение tag может принимать одно из следующих значений:
Значение value зависит от значения tag и должно быть заключено в двойные кавычки («»).
Некоторые центры сертификации позволяют использовать дополнительные параметры для значения value. В этом случае, параметры должны быть разделены точкой с запятой (;).
Пример: 0 issue «comodoca.com; account=12345»
Пример: example.com. CAA 0 issue «comodoca.com»
Пример: example.com. CAA 0 issue «;»
Пример: example.com. CAA 0 issuewild «comodoca.com»
Пример: example.com. CAA 0 issuewild «;»
Пример: example.com. CAA 0 iodef «mailto:abuse@example.com»
CAA-запись поддерживают не все DNS-провайдеры. Актуальный список по состоянию на 30 августа 2017 года в алфавитном порядке:
Вы можете воспользоваться этим или этим онлайн-генератором для правильного и быстрого создания необходимых CAA-записей.
Форум центров сертификации и разработчиков браузеров утвердил обязательность DNS CAA
Об актуальной теме утвержденных недавно как обязательные дополнительных средств усиления валидности сертификатов безопасности (SSL/TSL) рассказывают специалисты Qualis, облачного провайдера, оказывающего широкий спектр услуг в области интернет-безопасности.
CAA (Certification Authority Authorization – авторизация центров сертификации), определенная в RFC 6844 в 2013 г., была предложена, чтобы усилить экосистему PKI (Public Key Infrastructure) при помощи нового средства контроля за тем, какой именно центр сертификации может выдавать сертификат данному конкретному домену.
Несмотря на то, что САА введена уже более 4 лет назад, она все еще мало известна сегодня, и на данный момент только 100 или, может быть, около 200 сайтов ее используют. Однако предстоят значительные перемены, потому что форум центров сертификации и разработчиков браузеров (форум CA/Browser) утвердил CAA в качестве обязательной – в рамках стандартного набора базовых условий для выпуска сертификата безопасности. Новая норма начнет действовать с сентября 2017 года.
Возможность выпуска сертификата безопасности любым сертификационным центром (СА) для любого домена неоднократно указывалась как наиболее слабое место экосистемы PKI. Несмотря на то, что центры сертификации должны действовать не нарушая неких общих правил, до сих пор нет средств технического контроля за тем, что они делают. Отсюда возникает некое слабое звено в системе, а при наличии сотен CA – таких звеньев, соответственно, сотни.
САА создает механизм, позволяющий владельцам доменов создавать на уровне DNS-записей белые списки центров, которым они разрешают выдавать сертификаты для своего домена. Для этого вводится новая ресурсная DNS-запись, САА (тип 257). Владелец домена ограничивает выдачу сертификатов, указывая явно адрес центра сертификации в этой записи.
Например, вот таким образом:
И это всё. Перед тем как выпустить сертификат для какого-нибудь домена, СА проверяет его ресурсную DNS-запись CAA, и выпускает сертификат только в том случае, если находит там свой адрес. В дополнение к директиве «issue» из вышеприведенного примера, есть еще директива «issuewild», ограничивающая выпуск расширенных wildcard-сертификатов, и директива «iodef», которая содержит URL, по которому СА может обратиться, если что-то происходит неправильно – в смысле политики сертификации или технических проблем. (128 – это контрольный байт с установленным старшим битом, указывающий на то, что данная директива критически важна и должна исполняться безусловно).
С некоторой точки зрения САА выполняет почти ту же функцию, что и HPKP (HTTP Public Key Pinning — прикрепление публичных ключей HTTP), но несколько иным образом. Во-первых, САА предотвращает выпуск сертификата, в то время как HPKP осуществляет проверку на стороне клиента во время исполнения, определяя уже выпущенные сертификаты как валидные или не валидные.
Во-вторых, HPKP – для браузеров, а CAA – для центров сертификации. HPKP, дающая список ключей, средство технического контроля, в то время как САА осуществляет, скорее, административный контроль. Да, ожидается, что при несоответствии САА-записи центр сертификации прекращает выдачу сертификата, но ведь центр сертификации может переключиться в ручной режим и принять решение о выпуске, если запрос будет признан все-таки подлинным. И да, это опять сложность – центров сертификации много, и самая главная проблема для них – противостоять неким «социальным» факторам давления и все же выполнять некие формальные правила в случае несоответствия САА-записей.
Но говорить, что САА бесполезна или пересекается с HPKP – не стоит. Тут есть определенные преимущества, в частности, по сравнению с HPKP у САА меньше возможностей для злоупотребления и нарушения прав собственности в онлайн-пространстве.
HPKP при неверном функционировании может полностью разрушить ваш веб-бизнес, а САА будет только слегка раздражать, если что-то пойдет не так.
И кроме того, «прикрепление публичных ключей для подтверждения владения веб-ресурсом» пугает потенциальных пользователей HPKP своей сложностью и громоздкостью, по сравнению с простотой DNS-записи CAA.
Проверить наличие САА-записи можно при помощи любого онлайн-сервиса, анализирующего состав записей DNS для публичных доменов.
DNS-запись CAA. Зачем нужна и как использовать?
CAA (Certification Authority Authorization) — это новый тип DNS-записи, предназначенный для определения центров сертификации, которым разрешен выпуск SSL/TLS-сертификатов для определенного доменного имени или субдомена.
Крупнейшие и наиболее популярные центры сертификации договорились, что начиная с 8 сентября 2017 года в обязательном порядке строго следовать инструкциям, указанным в CAA-записях доменного имени или субдомена для которого запрашивается выпуск сертификата.
Использование CAA-записи позволит повысить уровень безопасности в сети Интернет и сократить случаи неавторизованного получения сертификатов для сторонних доменных имен.
Я подготовил подробную инструкцию, которая разъясняет возможности CAA-записи и формат ее использования.
Значение CAA-записи состоит из трех частей, разделенных пробелом:
Значение flag представляет собой 8-битное число, старший бит которого обозначает критичность понимания записи центром сертификации. В данный момент допустимы следующие значения:
Значение tag может принимать одно из следующих значений:
Значение value зависит от значения tag и должно быть заключено в двойные кавычки («»).
Некоторые центры сертификации позволяют использовать дополнительные параметры для значения value. В этом случае, параметры должны быть разделены точкой с запятой (;).
Пример: 0 issue «comodoca.com; account=12345»
Пример: example.com. CAA 0 issue «comodoca.com»
Пример: example.com. CAA 0 issue «;»
Пример: example.com. CAA 0 issuewild «comodoca.com»
Пример: example.com. CAA 0 issuewild «;»
Пример: example.com. CAA 0 iodef «mailto:abuse@example.com»
CAA-запись поддерживают не все DNS-провайдеры. Актуальный список по состоянию на 30 августа 2017 года в алфавитном порядке:
Вы можете воспользоваться этим или этим онлайн-генератором для правильного и быстрого создания необходимых CAA-записей.
«Теперь обязательно»: выдача SSL-сертификатов с учетом DNS-записи
В этом году публичные организации, отвечающие за распределение сертификатов, в обязательном порядке начнут учитывать специальные DNS-записи. Эти записи позволяют владельцам доменов определять «круг лиц», которым дозволено выдавать сертификаты SSL/TLS (о них мы писали в нашем предыдущем посте) для их домена.
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 должны будут отправлять уведомления о подозрительных запросах на сертификаты.
Вносим CAA запись в DNS (bind9)
Начиная с сентября 2017 года удостоверяющим центрам предписано обязательно проверять CAA-записи в DNS перед генерацией сертификата. CAA (RFC-6844, Certificate Authority Authorization) позволяет владельцу домена явно определить удостоверяющий центр, который имеет полномочия для генерации сертификатов для указанного домена. При наличии CAA-записи все остальные удостоверяющие центры обязаны блокировать выдачу сертификатов от своего имени для данного домена и информировать его владельца о попытках компрометации.
И так, исходя из этого я решил внести данную запись в свой DNS сервер. Оговорюсь, что сервер работает на Ubuntu Server 16.04 с пакетом bind9 и с центром сертификации Let’s Encrypt. Давайте же начнем.
Вносим CAA запись.
Откроем файл настройки прямой зоны DNS для сайта mysie.ru на редактирование.
И вносим в него запись CAA. Вот так выглядит файл прямой зоны для mysite.ru:
Допустимо указание нескольких записей issue, при использовании сертификатов от нескольких удостоверяющих центров:
сертификаты для mysite.ru генерируются только удостоверяющим центром Let’s Encrypt. В поле iodef задаётся метод оповещения о попытке генерации сертификата, уведомления отправляется на email указанный в этом поле.
Проверка CAA записи
Проверить корректность записей CAA можно командой:
Если есть вопросы, то пишем в комментариях.
Также можете вступить в Телеграм канал, ВК или подписаться на Twitter. Ссылки в шапки страницы.
Заранее всем спасибо.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.