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