DNS Certification Authority Authorization ( CAA ) - это механизм политики безопасности в Интернете , который позволяет владельцам доменных имен указывать центрам сертификации, уполномочены ли они выдавать цифровые сертификаты для определенного доменного имени . Это делается с помощью новой записи ресурса системы доменных имен (DNS) CAA .
Статус | Предлагаемый стандарт |
---|---|
Впервые опубликовано | 18 октября 2010 г. |
Последняя версия | RFC 8659, ноябрь 2019 г. |
Организация | IETF |
Авторы |
|
Сокращение | CAA |
Его разработали компьютерные ученые Филип Халлам-Бейкер и Роб Стрэдлинг в ответ на растущую озабоченность по поводу безопасности публично доверенных центров сертификации. Это стандарт, предложенный инженерной группой Интернета (IETF) .
Задний план
Серия неправильно выданные сертификаты с 2001 годом [1] [2] повреждено доверие публично доверенными сертификатами, [3] и ускорили работу по различным механизмам безопасности, в том числе сертификата прозрачности для отслеживания неправильной выдачи, HTTP Public Key пиннинга и DANE к блокировать неправильно выданные сертификаты на стороне клиента , а CAA - блокировать неправильную выдачу на стороне центра сертификации. [4]
Первый проект CAA был написан Филипом Халлам-Бейкером и Робом Стрэдлингом и представлен как проект IETF Internet в октябре 2010 года. [5] Он был постепенно улучшен рабочей группой PKIX , [6] и одобрен IESG как RFC 6844 , предлагаемый стандарт , в январе 2013 года. [7] Вскоре после этого началось обсуждение CA / Browser Forum [4], а в марте 2017 года они проголосовали за обязательную реализацию CAA для всех центров сертификации к сентябрю 2017 года [8]. [9] По крайней мере, один центр сертификации, Comodo , не смог реализовать CAA до истечения крайнего срока. [10] Исследование 2017 года, проведенное Техническим университетом Мюнхена, выявило множество случаев, когда центры сертификации не могли правильно реализовать некоторые части стандарта. [4]
В сентябре 2017 года Джейкоб Хоффман-Эндрюс представил Интернет-проект, призванный упростить стандарт CAA. Это было улучшено рабочей группой LAMPS и одобрено как RFC 8659 , предлагаемый стандарт, в ноябре 2019 г. [11]
По состоянию на январь 2020 г.[Обновить], QUALYS сообщает , что до сих пор, только 6,8% из 150,000 наиболее популярных TLS Поддержки сайтов используют ВГ запись. [12]
Записывать
Центры сертификации, реализующие CAA, выполняют поиск в DNS записей ресурсов CAA и, если таковые обнаруживаются, перед выдачей цифрового сертификата убедитесь, что они указаны как авторизованная сторона . Каждая запись ресурса CAA состоит из следующих компонентов: [11]
- флаг
- Флаги байт , который реализует расширяемую систему сигнализации для использования в будущем. По состоянию на 2018 год [Обновить], был определен только критический флаг эмитента , который указывает центрам сертификации, что они должны понимать соответствующий тег свойства перед выдачей сертификата. [11] Этот флаг позволяет в будущем расширять протокол обязательными расширениями [4], аналогичными критическим расширениям в сертификатах X.509 .
- тег
- Одно из следующих свойств:
- проблема
- Это свойство разрешает владельцу домена, указанного в значении связанного свойства, выдавать сертификаты для домена, для которого опубликовано свойство.
- дикая
- Это свойство действует как проблема, но только разрешает выпуск сертификатов с подстановочными знаками и имеет приоритет над свойством выпуска для запросов сертификатов с подстановочными знаками.
- iodef
- Это свойство определяет метод, с помощью которого центры сертификации могут сообщать владельцу доменного имени о недействительных запросах сертификатов с помощью формата обмена описанием объекта инцидента . По состоянию на 2018 год [Обновить], не все центры сертификации поддерживают этот тег, поэтому нет гарантии, что все выдачи сертификатов будут сообщены.
- Почта для связи
- Все чаще контактная информация недоступна в WHOIS из-за опасений по поводу возможных нарушений GDPR. Это свойство позволяет владельцам доменов публиковать контактную информацию в DNS. [13] [14]
- Контактный телефон
- То же, что и выше, для телефонных номеров. [15]
- значение
- Значение, связанное с выбранным тегом свойства.
Отсутствие каких - либо ВГ записей разрешает нормальный неограниченный выпуск, а также наличие одной пустого вопрос тега запрещает весь выпуск. [11] [9] [16]
Третьи стороны, наблюдающие за поведением центра сертификации, могут проверять недавно выпущенные сертификаты по записям CAA домена, но должны знать, что записи CAA домена могли измениться между временем выпуска сертификата и временем их проверки третьей стороной. Клиенты не должны использовать CAA в процессе проверки своих сертификатов. [11]
Расширения
RFC 8657 определяет "accounturi"
и "validationmethods"
параметры, которые позволяют пользователям указывать желаемые методы проверки управления доменом, как определено в протоколе ACME . Например, администратор веб-сайта может привязать контролируемый им домен к определенной учетной записи, зарегистрированной в желаемом центре сертификации.
История
Проект первого расширения стандарта CAA был опубликован 26 октября 2016 года, предложив новый счет URI- маркер конца вопроса собственности, привязывает домен к конкретному Automated Сертификат экологического менеджмента счета. [17] Это было изменено 30 августа 2017 года, чтобы также включить новый токен методов проверки , который привязывает домен к определенному методу проверки, [18], а затем 21 июня 2018 года были внесены дополнительные изменения, чтобы удалить дефис в учетной записи. -uri и validation-methods вместо методов accounturi и validation . [19]
Примеры
Чтобы указать, что только центр сертификации, указанный ca.example.net , уполномочен выдавать сертификаты для example.com и всех поддоменов, можно использовать эту запись CAA: [11]
example.com. В CAA 0 проблема "ca.example.net"
Чтобы запретить выдачу любого сертификата, можно разрешить выдачу только пустому списку издателей:
example.com. В CAA 0 проблема ";"
Чтобы указать, что центры сертификации должны сообщать о недействительных запросах сертификатов на адрес электронной почты и на конечную точку межсетевой защиты в реальном времени :
example.com. В CAA 0 iodef "mailto: [email protected]"example.com. В CAA 0 iodef "http://iodef.example.com/"
Чтобы использовать будущее расширение протокола, например такое, которое определяет новое будущее свойство, которое должно быть понято центром сертификации, прежде чем они смогут безопасно продолжить, можно установить критический флаг эмитента :
example.com. В CAA 0 проблема "ca.example.net"example.com. В CAA 128 будущее "значение"
Известные инциденты с соблюдением нормативных требований
В 2017 году было обнаружено, что Camerfirma неправильно проверяла записи CAA. Camerfirma заявила, что неправильно поняла базовые требования CA / Browser Forum, описывающие валидацию CAA. [20]
В начале 2020 года Let's Encrypt сообщила, что их программное обеспечение неправильно запрашивало и проверяло записи CAA, что потенциально могло повлиять на более 3 миллионов сертификатов. [21] Let's Encrypt работал с клиентами и операторами сайтов над заменой более 1,7 миллиона сертификатов, но решил не отзывать остальные, чтобы избежать простоя клиентов и поскольку срок действия всех затронутых сертификатов истечет менее чем через 90 дней. [22]
Смотрите также
- Компрометация центра сертификации
- Сертификат прозрачности
- Аутентификация именованных объектов на основе DNS
- Закрепление открытого ключа HTTP
- Список типов записей DNS
Рекомендации
- ^ Ристич, Иван. «История SSL / TLS и PKI» . Злющая утка . Проверено 8 июня 2018 года .
- ^ Брайт, Питер (30 августа 2011 г.). «Другой поддельный сертификат вызывает те же старые вопросы о центрах сертификации» . Ars Technica . Проверено 10 февраля 2018 года .
- ^ Руохонен, Юкка (2019). «Эмпирический обзор раннего внедрения авторизации центра сертификации DNS». Журнал технологий кибербезопасности . 3 (4): 205–218. arXiv : 1804.07604 . DOI : 10.1080 / 23742917.2019.1632249 . S2CID 5027899 .
- ^ а б в г Шейтле, Квирин; Чунг, Тэджун; и другие. (Апрель 2018 г.). «Первый взгляд на авторизацию центра сертификации (CAA)» (PDF) . Обзор компьютерных коммуникаций ACM SIGCOMM . 48 (2): 10–23. DOI : 10.1145 / 3213232.3213235 . ISSN 0146-4833 . S2CID 13988123 .
- ^ Халлам-Бейкер, Филипп ; Стрэдлинг, Роб (18 октября 2010 г.). Запись ресурса авторизации центра сертификации (CAA) DNS . IETF . ID draft-hallambaker-donotissue-00.
- ^ Халлам-Бейкер, Филипп ; Стрэдлинг, Роб; Бен, Лори (2 июня 2011 г.). Запись ресурса авторизации центра сертификации (CAA) DNS . IETF . ID draft-ietf-pkix-caa-00.
- ^ Халлам-Бейкер, Филипп ; Стрэдлинг, Роб (январь 2013 г.). Запись ресурса авторизации центра сертификации (CAA) DNS . IETF . DOI : 10,17487 / RFC6844 . ISSN 2070-1721 . RFC 6844 .
- ^ Холл, Кирк (8 марта 2017 г.). «Результаты бюллетеня 187 - Сделайте проверку CAA обязательной» . CA / Форум браузеров . Проверено 7 января 2018 года .
- ^ а б Битти, Дуг (22 августа 2017 г.). "Что такое CAA (авторизация центра сертификации)?" . GlobalSign . Проверено 2 февраля 2018 года .
- ^ Чимпану, Каталин (11 сентября 2017 г.). «Comodo поймали на нарушении нового стандарта CAA через день после того, как он вступил в силу» . Пищевой компьютер . Проверено 8 января 2018 года .
- ^ а б в г д е Запись ресурса авторизации центра сертификации (CAA) DNS . IETF . Ноябрь 2019 г. doi : 10.17487 / RFC8659 . ISSN 2070-1721 . RFC 8659 .
- ^ «Импульс SSL» . SSL Labs . Qualys . 3 января 2020 . Проверено 31 января 2020 года .
- ^ «Инфраструктура открытого ключа с использованием параметров X.509 (PKIX)» . www.iana.org . Проверено 22 августа 2020 года .
- ^ https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf
- ^ Битти, Дуг (7 января 2019 г.). «Бюллетень SC14: Контактная информация CAA и соответствующие методы проверки телефона» . CA / Browser Forum (список рассылки) . Проверено 19 октября 2020 года .
- ^ «Что такое авторизация центра сертификации (CAA)?» . Symantec . Проверено 8 января 2018 года .
- ^ Ландау, Гюго (26 октября 2016 г.). Расширения записи CAA для URI учетной записи и привязки метода ACME . IETF . ID draft-ietf-acme-caa-00.
- ^ Ландау, Гюго (30 августа 2017 г.). Расширения записи CAA для URI учетной записи и привязки метода ACME . IETF . ID draft-ietf-acme-caa-04.
- ^ Ландау, Гюго (21 июня 2018 г.). Расширения записи CAA для URI учетной записи и привязки метода ACME . IETF . ID draft-ietf-acme-caa-05.
- ^ «CA: Проблемы Camerfirma - MozillaWiki» . wiki.mozilla.org . Проверено 27 апреля 2021 года .
- ^ Клэберн, Томас (3 марта 2020 г.). «Давайте зашифровать? Давайте отзовем 3 миллиона сертификатов HTTPS в среду, скорее, как:« Проверка ошибок в цикле кода » . www.theregister.com . Проверено 27 апреля 2021 года .
- ^ Барретт, Брайан (3 марта 2020 г.). «Интернет избежал небольшой катастрофы на прошлой неделе» . Проводной . ISSN 1059-1028 . Проверено 27 апреля 2021 года .
Внешние ссылки
- RFC 8659
- Список идентификаторов CA для использования в записях CAA в Общей базе данных CA