Защо да използвате CAA?
Компютърните учени Phillip Hallam-Baker и Rob Stradling разработиха CAA в отговор на нарастващите опасения относно сигурността на обществено доверените сертифициращи органи. Тази инициатива попада в рамките на Internet Engineering Task Force (IETF), водеща организация за разработване на стандарти (SDO) за Интернет. IETF създава доброволни стандарти, които са широко възприети от интернет потребители, мрежови оператори и доставчици на оборудване, оказвайки влияние върху развитието на интернет.
IETF документира своите технически стандарти в публикации, известни като RFC (Искания за коментари). Тези документи очертават ключови аспекти на интернет инфраструктурата, включително адресиране, маршрутизиране и транспортни технологии. CAA е конкретно дефиниран в RFC 6844.
Сертифициращият орган (CA) винаги използва методи на валидиране на домейн за да сте сигурни, че всеки SSL /TLS заявката за сертификат е разрешена (обикновено като се уверите, че е свързана по някакъв начин с определен сайт, използвайки този домейн).
Например, CA може да предостави специален файл за проверка на заявителя. Поставянето на този файл на уебсайта доказва, че заявителят също контролира този сайт, но не може да гарантира легитимност на този контрол. Хакер, който получи контрол над даден сайт, може да се представи за легитимен собственик и след това да поиска и да получи SSL /TLS сертификат, който преминава всички стандартни проверки на CA и по този начин изглежда легитимен. След това те биха могли да се обърнат и да използват този SSL /TLS удостоверение за неразбории, на този сайт или на друго място.
CAA помага да се блокира този вид експлойт, като дефинира на кои CA могат да издават сертификати за домейн (или дори да ограничават изцяло издаването на сертификати). Това ограничава щетите, които похитителят може да нанесе - дори ако те имат контрол над даден сайт, ще имат драстично по-малко възможности да спечелят измамен SSL /TLS сертификат.
Какво е CNAME?
CNAME записът е тип DNS конфигурация, която позволява един домейн, като напр store.mybusiness.com, да действа като псевдоним за друг, като mybusiness.com. Вместо да управлява множество A записи за отразяване на промените в IP адреса, CNAME опростява това, като насочва псевдонима към целевия домейн. Този подход е много полезен за фирми, които редовно сменят уеб хостове или CDN доставчици. Освен това, CNAME записите са безценни за изграждане на системи за преодоляване при отказ, където трафикът се насочва от основен сървър към вторичен, осигурявайки непрекъснатост на услугата по време на прекъсвания.
В контекста на упълномощаването на сертифициращия орган (CAA), CNAME записите влияят на процеса, като пренасочват проверките на CAA към целевия домейн. Например ако shop.mysite.net използва CNAME, за да сочи към mysite.net, CA, извършващ проверка на CAA, ще оцени записите за mysite.net за проверка на разрешение за издаване на сертификат. Ако записът на CAA е включен mysite.net не упълномощава СО, удостоверението не може да бъде издадено. Това гарантира последователно прилагане на правилата на CAA, дори когато домейните използват CNAME записи за псевдоним на DNS.
Как работи CAA
CAA използва DNS
- Domain Name System (DNS) е решаваща част от инфраструктурата на интернет. Собственикът на всеки домейн поддържа DNS записи (вътре в т.нар файлове в зоната), сочещи името на домейна им към IP адреса, където се хоства техния сайт, и ни позволява да пишем google.com в прозорец на браузъра вместо в 216.58.194.46.
DNS записите обикновено се използват като „телефонен указател за Интернет“, но DNS позволява и други видове специални записи, които могат да присвоят друга информация на име на домейн.
Записи CAA
CAA използва специален вид запис, наречен a Запис на ресурса на сертифициращия орган (Запис на CAA). Те се публикуват с помощта на DNS и собственикът на домейна просто добавя CAA записи заедно с другите си DNS записи. Записът на CAA включва a тагове и стойност, а двойката таг-стойност се нарича a имот. Има също флаг указващо колко критично е това свойство. Ето как изглежда човек:
example.com. CAA 0 издание "ssl.com"
Тук example.com е домейнът, към който се прилага този запис, и CAA ни дава информация за това какъв запис е това. Най- 0 е флагът (нула е по подразбиране). Етикетът е издаване а стойността (в кавички) е ssl.com, които заедно съставляват имота.
Знамена
В момента флаговете имат само две строго определени състояния: 0 (некритични) и 1 (Критичен). Критичен флаг казва на CA, че го трябва да разберете напълно маркера на свойството, за да продължите. RFC 6844 оставя други възможности отворени за използване на потребителски флаг (повече за това по-долу).
Маркирания
RFC 6844 определя използването на три често използвани маркера: издаване, issueewild намлява йодеф, (Както при флаговете, той позволява други потенциални персонализирани типове маркери.)
- издаване тагове
- издаване tag определя кой (ако има такъв) CA има право да издава сертификати за този домейн. Например собственикът на домейна example.com може да ограничи издаването на сертификат до един CA (тук SSL.com), като използва следния файл на DNS зона:
example.com. CAA 0 брой „ssl.com“
Собственикът на домейн може да избере да настрои няколкозонови файлове за домейн:
example.com. CAA 0 брой „ssl.com“ example.com. CAA 0 брой „comodoca.com“
Горните записи ограничават SSL /TLS издаване на сертификат за example.com до два CA (SSL.com и Comodo.com).
- издаване record също така упълномощава посочения CA да издава сертификати за всякакви поддомейни на посочения домейн. По този начин запис, позволяващ SSL.com, може да позволи издаването на сертификати за example.com и поддомейни като www.example.com, mail.example.com и дори специалния поддомен wildcard * .example.com.
CAA запис може да се използва за ограничи издаване на сертификат също - този запис казва на сертифициращите органи, използващи CAA Не. SSL /TLS трябва да се издават сертификати за example.com и поддомейни от който и да е CA:
example.com. CAA 0 брой ";"
(Запетаята в този пример означава „не позволявайте нищо тук“, Но както ще покажем по-късно, той се използва и за дефиниране на персонализирани параметри.)
Обърнете внимание, че стандартен таг за издаване позволява на CA да издаде сертификат за заместващ знак, освен ако не бъде променен от ...
- issueewild тагове
Този маркер указва, че CA е упълномощен да издава сертификати за заместване за домейна на собственика (т.е. * .example.com).
Заместващите символи могат да отчитат неограничен набор от поддомейни и затова се изискват специални грижи и внимание при издаването на сертификати за заместващи знаци. The issueewild таг позволява на собственика на домейна да дефинира какво CA може да издава сертификати за заместващи знаци отделно от основния домейн или други поддомейни. issueewild таговете имат предимство пред всеки издаване тагове. Те използват същия синтаксис като издаване маркер. Няколко примера:
example.com. CAA 0 брой „ssl.com“ example.com. CAA 0 issueewild ";"
Горното позволява на SSL.com да издава сертификати за example.com и всички поддомейни с изключение на за wildcard * .example.com. (Нито на SSL.com, нито на който и да е друг CA е разрешено да издава сертификати за заместване за example.com.)
example.com. CAA 0 брой ";" example.com. CAA 0 issueewild "ssl.com"
Този пример забранява all CA да издават сертификати на example.com и неговите поддомейни, но създава изключение, за да позволи на SSL.com да издава сертификати за заместващи символи (и само за лична употреба сертификати за заместващи карти) за example.com.
- йодеф тагове
Третият дефиниран маркер е йодеф, Този маркер може да се използва за докладване на невалидни заявки за сертификати на собственика на домейна и изглеждат така:
example.com. CAA 0 iodef "mailto: certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"
Най-горният запис дава информация за CA, необходима за изпращане на известие по имейл до адреса certissues@example.com, Вторият насочва CA да публикува съобщение за инцидент в уеб услуга (създадена за тази цел от собственика на домейна) в certissues.example.com, (Може да се използва един или и двата метода, в зависимост от това как CA и собственикът на домейн са настроили своите операции.)
йодеф съобщенията за публикуване използват стандартен формат, наречен Описание на инцидента Описание Формат на обмен или IODEF - оттук и името. (IODEF е дефиниран в RFC 6546.)
Етикетът за проблемна поща за S/MIME
Важно развитие в CAA е разширението към S/MIME (Secure/Multipurpose Internet Mail Extensions) сертификати, формализирани в RFC 9495. S/MIME сертификатите осигуряват сигурност на имейл чрез удостоверяване, поверителност на данните и цялост на съобщенията. CA/Browser Forum въведе нов таг за собственост на CAA, наречен „issuemail“, специално за контролиране на издаването на S/MIME сертификати.
От 15 септември 2024 г. се препоръчва CAA да прилагат проверка на CAA S/MIME удостоверения, със задължително изпълнение до 15г. Стандартният формуляр за запис на CAA за имейл адреси ще изглежда така:
mail.client.example CAA 0 issuemail "authority.example"
Това разширение на CAA към имейл сертификати предоставя на собствениците на домейни същото ниво на контрол върху S/MIME издаване на удостоверение, както имат за TLS сертификати, намалявайки риска от неоторизирано издаване на сертификати.
Определени от CA флагове и маркери
CAA, както е описано в RFC 6844, определя конкретно две състояния на флага (0 и 1) и три маркера (издаване, issueewild намлява йодеф). Въпреки това, той оставя дизайна достатъчно отворен за CA, за да създадат и използват персонализирани маркери и флагове, за да определят процеса на издаване на сертификата си. Примери могат да бъдат:
example.com. CAA 0 брой „SSL.com; policy = ev“
Този запис използва стандарт издаване етикет с допълнителен параметър, който инструктира CA да използва своята политика за разширено валидиране (EV) при издаване на сертификат за този домейн.
example.com. CAA 128 pca "PCA = 12345"
Собственикът на домейна може да използва този запис с нова, дефинирана от СА СПС маркер, за да покаже, че имат предпочитан клиентски акаунт и задава номера на акаунта като параметър. (Флагът може да бъде и персонализирана стойност до 255.) В зависимост от начина, по който CA създава акаунта, това може да даде възможност за конкретни методи за фактуриране, допълнителна дефинирана от профила проверка или друга специална обработка.
Предимства и недостатъци
Има няколко отлични причини да използвате CAA. Основното и най-важно предимство е способността на CAA да намали значително риска от неправилно издаване на сертификат. Това помага да защитите вашия домейн, вашия бизнес и вашата онлайн идентичност. Потенциалните нападатели, които може да са открили грешка в софтуера на конкретен CA, не могат да го използват, за да издадат SSL сертификати за вашия домейн. Освен това, използването на маркера iodef ви позволява да получите доклад, ако бъде направен опит за експлойт.
Дизайнът на CAA повишава сигурността, но може да позволи и по-подробно разпределение на ресурсите - например, една компания може да създаде записи, за да позволи (или да ограничи) отдела за продажби и маркетинг да закупи SSL сертификати за sales.example.com от определен източник.
Освен това CAA предлага голяма гъвкавост. За собственик на домейн той използва записи на DNS ресурси, които са под техен собствен контрол и могат да се променят при необходимост, така че те не са обвързани с конкретен CA (и могат да имат повече от един CA, оторизиран с издаване на записи за дадено име на домейн) , За CAs, дори освен персонализирани приложения, новоприетите правила от CA / B Форум (групата, която определя стандарти за CA и въпроси за сигурността на браузъра) могат да позволят CAA записи да се използват за целите на валидирането, осигурявайки още една основателна причина да ги използват.
Един недостатък е, че дори когато има CAA записи, потребителят не може наложат използването му от сертифициращ орган. CA трябва да е съвместим с RFC 6844, за да може да се действа по тези записи, а несъответстващ CA може просто да игнорира изричните желания на собственика на домейна, декларирани в техните CAA записи.
CAA също трябва да бъде правилно конфигуриран както от собственика на домейна, така и от CA. Let's Encrypt (който поддържа CAA) наскоро съобщиха за незначителен проблем с тяхната кодова база което за съжаление доведе до игнориране на правилата на CAA и неправилно издаване на шест сертификата. Нито едно от тях не е злонамерено изключение (и похвала на екипа Let's Encrypt за разрешаване и докладване на проблема в рамките на часове след откриването). Това обаче подчертава, че съответстващ сертифициращ орган трябва да прилагат CAA безотказно.
Друг потенциален проблем е зависимостта на CAA от DNS. Освен ако собственикът на домейн не осигури услугите си за имена, това може да бъде вектор за атака. RFC 6844 предлага внедряване Разширения за сигурност на система за домейни (DNSSEC), който използва цифрово подписани DNS записи за удостоверяване на данни и борба със заплахата от изтриване на DNS.
И накрая, дори и с CAA на място и правилно внедрен, CAA запис сам по себе си не може напълно да попречи на издаването на измамни сертификати. Въпреки че CAA е полезен и важен инструмент за ограничаване на опциите на нападателя, похитителят с достатъчен достъп (например чрез контролиране на DNS или чрез социално инженерство) може да бъде в състояние да го насочва.
Заключение
Упълномощаването на сертифициращия орган има страхотен потенциал като част от по-широка екосистема за сигурност и широкото приемане и внедряване на CAA ще защити срещу неправилно издаване на сертификати. Въпреки че CAA сам по себе си няма да спре всяко неправилно издаване на сертификат, това е добра стъпка в правилната посока и SSL.com би искал да ви призове да обмислите сами да използвате CAA записи.
Източници
- RFC6844: Запис на ресурсите на DNS сертифициращ орган (CAA)
- RFC5070: Формат за обмен на инцидентния обект
- RFC6546: Транспортиране на съобщения за отбрана в реално време (RID) през HTTP /TLS
- RFC4033: Въведение и изисквания за DNS сигурност
- CA / B Форум бюлетин 125 - CAA Records
- Запис в Уикипедия за разрешение за сертифициране на DNS
Свързани ръководства
- Какви са изискванията за SSL.com SSL /TLS Валидиране на домейн на сертификат?
- Какво представлява „уникалната стойност“, използвана при валидирането на домейн (DV)?
- Име на домейн SSL /TLS Предварително Validation
