Miks kasutada CAA-d?
Arvutiteadlased Phillip Hallam-Baker ja Rob Stradling töötasid välja CAA vastuseks kasvavale murele avalikult usaldusväärsete sertifitseerimisasutuste turvalisuse pärast. See algatus kuulub Internet Engineering Task Force (IETF) alla, mis on juhtiv Interneti standardite arendamise organisatsioon (SDO). IETF loob vabatahtlikke standardeid, mida Interneti-kasutajad, võrguoperaatorid ja seadmete müüjad laialdaselt kasutusele võtavad, mõjutades Interneti arengut.
IETF dokumenteerib oma tehnilised standardid väljaannetes, mida nimetatakse RFC-deks (Requests for Comments). Need dokumendid kirjeldavad Interneti-infrastruktuuri põhiaspekte, sealhulgas aadressi-, marsruutimis- ja transporditehnoloogiaid. CAA on konkreetselt määratletud RFC 6844.
Sertifikaadiasutus (CA) kasutab alati meetodeid domeeni valideerimine veendumaks, et iga SSL /TLS sertifikaaditaotlus on autoriseeritud (tavaliselt veendudes, et see on mingil viisil lingitud selle domeeni kasutava konkreetse saidiga).
Näiteks võib CA anda taotlejale spetsiaalse kontrollfaili. Selle faili paigutamine veebisaidile tõestab, et taotleja kontrollib ka seda saiti, kuid ta ei saa seda tagada legitiimsus sellest kontrollist. Häkker, kes saab saidi üle kontrolli, võib maskeeruda seadusliku omanikuna ning võib seejärel taotleda ja saada SSL-i /TLS sertifikaat, mis läbib kõik CA standardkontrollid ja seega tundub õigustatud. Seejärel said nad pöörduda ümber ja kasutada seda SSL-i /TLS pahanduste tõend, sellel saidil või mujal.
CAA aitab sellist ärakasutamist blokeerida, määratledes, millistel CA-del on lubatud domeeni jaoks sertifikaate välja anda (või isegi piirates sertifikaatide väljaandmist üldse). See piirab kaaperdaja tekitatavat kahju - isegi kui neil on saidi üle kontroll, on neil petturitest SSL-i saamiseks palju vähem võimalusiTLS tunnistus.
Mis on CNAME?
CNAME-kirje on DNS-i konfiguratsiooni tüüp, mis võimaldab ühte domeeni, nt store.mybusiness.com, toimida teise varjunimena, nagu mybusiness.com. Selle asemel, et hallata mitut A-kirjet, et kajastada IP-aadressi muutusi, lihtsustab CNAME seda, suunates pseudonüümi sihtdomeenile. See lähenemisviis on väga kasulik ettevõtetele, kes vahetavad regulaarselt veebimajutajaid või CDN-i pakkujaid. Lisaks on CNAME-kirjed hindamatud tõrkesiirdesüsteemide ehitamisel, kus liiklus suunatakse esmasest serverist teise, tagades katkestuste ajal teenuse järjepidevuse.
Sertifikaadi autoriseerimise (CAA) kontekstis mõjutavad CNAME-kirjed protsessi, suunates CAA kontrollid ümber sihtdomeeni. Näiteks kui shop.mysite.net kasutab osutamiseks CNAME-i mysite.net, hindab CAA kontrolli teostav CA kirjeid mysite.net sertifikaadi väljaandmise volituse kontrollimiseks. Kui CAA rekord on mysite.net ei volita CA-d, ei saa sertifikaati väljastada. See tagab CAA poliitikate järjepideva jõustamise isegi siis, kui domeenid kasutavad DNS-i aliase jaoks CNAME-kirjeid.
Kuidas CAA töötab?
CAA kasutab DNS-i
. Domain Name System (DNS) on Interneti infrastruktuuri oluline osa. Mis tahes domeeni omanik peab DNS-i kirjeid (nn tsoonifailid) osutades oma domeeninime IP-aadressile, kus nende saiti majutatakse, ja laseme meil tippida google.com brauseriaknasse 216.58.194.46.
DNS-kirjeid kasutatakse tavaliselt Interneti-telefoniraamatuna, kuid DNS võimaldab ka muud tüüpi spetsiaalseid kirjeid, mis võivad domeeninimele määrata muud teavet.
CAA andmed
CAA kasutab spetsiaalset tüüpi kirjet nimega a Sertifitseerimisasutuse volitusressursside register (CAA rekord). Need avaldatakse DNS-i kasutades ja domeeni omanik lisab CAA-kirjed lihtsalt muude DNS-i kirjete kõrvale. CAA kirje sisaldab a silt ja väärtusja sildi-väärtuse paari nimetatakse a-ks kinnisvara. Samuti on lipp mis näitab, kui kriitiline see omadus on. Selline näeb välja:
example.com. CAA 0 väljaanne "ssl.com"
Siin example.com on domeen, millele see kirje kehtib, ja CAA annab meile teada, mis tüüpi rekord see on. 0 on lipp (vaikeväärtus on null). Silt on probleem ja väärtus (jutumärkides) on ssl.com, mis koos moodustavad vara.
Lipud
Lippidel on praegu ainult kaks rangelt määratletud olekut: 0 (mittekriitiline) ja 1 (kriitiline). Kriitiline lipp annab CA-le teada, et see nii on peab jätkamiseks atribuudi märgendist täielikult aru saama. RFC 6844 jätab kasutaja määratud lipu kasutamiseks avatuks muud võimalused (selle kohta leiate teavet allpool).
Sildid
RFC 6844 määratleb kolme levinuma sildi kasutamise: probleem, väljaandmisewild ja jodef. (Nagu lippude puhul, võimaldab see ka muid võimalikke kohandatud silditüüpe.)
. probleem silt
. probleem silt määrab, millisel (kui on) CA-l on volitus selle domeeni jaoks sertifikaate välja anda. Näiteks saab domeeni example.com omanik piirata sertifikaatide väljaandmist ühe CA-ga (siin, SSL.com), kasutades järgmist DNS-i tsoonifaili:
example.com. CAA 0 väljaanne "ssl.com"
Domeeni omanik saab valida domeeni jaoks mitme tsoonifaili seadistamise:
example.com. CAA 0 väljaanne "ssl.com" example.com. CAA 0 väljaanne "comodoca.com"
Ülaltoodud kirjed piiravad SSL-i /TLS sertifikaadi väljastamine example.com kahele CA-le (SSL.com ja Comodo.com).
. probleem rekord volitab nimetatud CA-d välja andma ka sertifikaate määratud domeeni kõigi alamdomeenide jaoks. SSL.com lubav kirje võib seega lubada sertifikaatide väljaandmist domeenile example.com ja alamdomeenid nagu www.example.com, mail.example.com ja isegi spetsiaalne metamärgi alamdomeen * .näide.com.
CAA kirjet saab kasutada piirata ka sertifikaatide väljaandmine - see kirje ütleb CAA-d kasutavatele sertifikaadiasutustele ei SSL /TLS sertifikaadid tuleks välja anda jaoks example.com ja alamdomeenid mistahes AC:
example.com. CAA 0 väljaanne ";"
(Selles näites tähendab semikoolonära luba siin midagi", Kuid nagu hiljem näitame, kasutatakse seda ka kohandatud parameetrite määratlemiseks.)
Pange tähele, et tavaline väljalaske silt võimaldab CA-l välja anda metamärgi sertifikaadi, kui seda ei muuda
. väljaandmisewild silt
See silt täpsustab, et CA-l on õigus väljastada metamärgisertifikaate omaniku domeeni jaoks (st * .näide.com).
Metamärgid võivad moodustada piiramatu hulga alamdomeene ja seetõttu väärib metamärgisertifikaatide väljastamisel erilist hoolt ja tähelepanu. The väljaandmisewild silt võimaldab domeeni omanikul määratleda, millised CA-d saavad põhidomeenist või muudest alamdomeenidest eraldi välja anda metamärkide jaoks sertifikaate. väljaandmisewild sildid on ülimuslikud ükskõik millise suhtes probleem sildid. Nad kasutavad sama süntaksit nagu probleem silt. Mõned näited:
example.com. CAA 0 väljaanne "ssl.com" example.com. CAA 0 issuewild ";"
Ülaltoodu võimaldab SSL.com-l välja anda sertifikaate example.com ja kõik alamdomeenid välja arvatud metamärgi jaoks * .näide.com. (SSL-il ega ühelgi teisel CA-l ei ole lubatud välja anda metamärgise sertifikaate example.com.)
example.com. CAA 0 väljaanne ";" example.com. CAA 0 issuewild "ssl.com"
See näide keelab kõik Pädevad asutused väljastavad sertifikaate example.com ja selle alamdomeenid, kuid loob erandi, mis võimaldab SSL.com-l välja anda metamärgisertifikaate (ja ainult metamärgi sertifikaadid) example.com.
. jodef silt
Kolmas määratletud silt on jodef. Seda silti saab kasutada kehtetute sertifikaaditaotluste teatamiseks domeeni omanikule ja need näevad välja järgmised:
example.com. CAA 0 iodef "mailto: certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"
Ülemine rekord annab CA-le teavet, mis on vajalik e-posti aadressile meilisõnumi saatmiseks sertifikaadid@näide.com. Teine suunab CA-d postitama vahejuhtumiteate veebiteenusele (mille on selle eesmärgi seadnud domeeni omanik) aadressil sertifikaadid.example.com. (Kasutada saab mõlemat või mõlemat meetodit, sõltuvalt sellest, kuidas CA ja domeeni omanik on oma toimingud seadistanud.)
jodef postisõnumid kasutavad standardset vormingut, mida nimetatakse Juhtumi objekti kirjeldus Vahetusvorming või IODEF - sellest ka nimi. (IODEF on määratletud punktis RFC 6546.)
Väljaandmisposti märgend S/MIME
Oluline areng CAA-s on selle laiendamine S/MIME (Secure/Multipurpose Internet Mail Extensions) sertifikaadid, vormistatud standardiga RFC 9495. S/MIME sertifikaadid pakuvad e-posti turvalisust autentimise, andmete privaatsuse ja sõnumite terviklikkuse kaudu. CA/brauseri foorum on võtnud kasutusele uue CAA atribuutimärgendi nimega "issuemail", mis on mõeldud spetsiaalselt dokumentide väljastamise kontrollimiseks. S/MIME tunnistused.
Alates 15. septembrist 2024 on CA-del soovitatav rakendada CAA kontrolli S/MIME sertifikaadid, mille kohustuslik rakendamine on nõutav 15. märtsiks 2025. Standardne CAA kirje vorm meiliaadresside jaoks näeb välja järgmine:
mail.client.example CAA 0 issuemail "authority.example"
See CAA laiendus meilisertifikaatidele annab domeeniomanikele samasuguse kontrolli S/MIME sertifikaatide väljastamist nagu neil on TLS sertifikaate, vähendades volitamata sertifikaatide väljastamise ohtu.
CA määratletud lipud ja sildid
RFC 6844-s kirjeldatud CAA määratleb konkreetselt ainult kaks lipuriiki (0 ja 1) ja kolm silti (probleem, väljaandmisewild ja jodef). Kuid see jätab kujunduse piisavalt avatud, et pädevad asutused saaksid kohandatud silte ja lippe luua ja kasutada oma sertifikaatide väljaandmise protsessi määratlemiseks. Näited võivad olla järgmised:
example.com. CAA 0 väljaanne "SSL.com; policy = ev"
See kirje kasutab standardit probleem lisaparameetriga silt, mis juhendab CA-d selle domeeni sertifikaadi väljastamisel kasutama laiendatud valideerimise (EV) poliitikat.
example.com. CAA 128 pca "PCA = 12345"
Domeeni omanik võiks seda kirjet kasutada uue CA-ga määratletud kirjega pca , et näidata, et neil on eelistatud kliendikonto, ja seab parameetriks konto numbri. (Lipp võib olla ka kohandatud väärtus kuni 255.) Sõltuvalt sellest, kuidas CA konto üles seab, võib see lubada konkreetseid arveldusmeetodeid, täiendavat kontoga määratletud kinnitust või muud spetsiaalset käsitsemist.
Plussid ja miinused
CAA kasutamiseks on mitu suurepärast põhjust. Peamine ja kõige olulisem eelis on CAA võime oluliselt vähendada sertifikaatide väära väljastamise riski. See aitab kaitsta teie domeeni, ettevõtet ja veebiidentiteeti. Potentsiaalsed ründajad, kes võisid leida vea konkreetse CA tarkvaras, ei saa seda teie domeeni jaoks SSL-sertifikaatide väljastamiseks ära kasutada. Veelgi enam, iodefi sildi kasutamine võimaldab teil saada aruande ärakasutamise katsest.
CAA ülesehitus suurendab turvalisust, kuid võib võimaldada ka ressursside üksikasjalikumat jaotamist - näiteks võib ettevõte seadistada kirjeid, mis võimaldavad (või piirata) müügi- ja turundusosakonnal osta SSL-i sertifikaate saidile sales.example.com määratud allikast.
Lisaks pakub CAA suurt paindlikkust. Domeeniomaniku jaoks kasutab ta DNS-i ressursikirjeid, mis on nende endi kontrolli all ja mida saab vastavalt vajadusele muuta, nii et neid ei seostata konkreetse CA-ga (ja neil võib olla mitu domeeni nime väljaandmiskirjetega volitatud CA-l) . CA-de jaoks võivad CA / B foorumi (rühm, mis kehtestab CA-de ja brauseri turbeküsimuste standardid) hiljuti vastu võetud reeglid CAA-kirjeid valideerimise eesmärgil, pakkudes veel üht head põhjust nende kasutamiseks.
Üks puudus on see, et isegi kui CAA kirjed on paigas, ei saa kasutaja seda teha jõustada selle kasutamine sertifikaadiasutuse poolt. Nende kirjete täitmiseks peab CA vastama RFC 6844-le ja nõuetele mittevastav CA võib lihtsalt ignoreerida oma CAA-kirjades deklareeritud domeeni omaniku sõnaselgeid soove.
CAA peab olema nii domeeni omaniku kui ka CA poolt õigesti konfigureeritud. Krüpteerime hiljuti (mis toetab CAA-d) teatasid oma koodibaasiga väiksemast probleemist mis viis kahjuks CAA reeglite eiramiseni ja kuue sertifikaadi vale väljaandmiseni. Ükski neist ei olnud pahatahtlik erand (ja kiitus Let's Encrypt meeskonnale, et probleem lahendati ja teatati mõne tunni jooksul pärast avastamist). See aga rõhutab, et vastav sertifikaadiasutus peab rakendama CAA veatult.
Teine potentsiaalne probleem on CAA tuginemine DNS-ile. Kui domeeni omanik ei kaitse oma nimeteenuseid, võib see olla rünnaku vektor. RFC 6844 soovitab rakendada Domeeninimede süsteemi turvalaiendid (DNSSEC), mis kasutab digitaalselt allkirjastatud DNS-i kirjeid andmete autentimiseks ja DNS-i võltsimise ohu tõkestamiseks.
Lõpuks, isegi kui CAA on paigas ja õigesti rakendatud, ei saa CAA kirje iseenesest täielikult takistada petturitest sertifikaatide väljaandmist. Kuigi CAA on kasulik ja oluline vahend ründaja võimaluste piiramiseks, võib piisava juurdepääsuga kaaperdaja (näiteks DNS-i juhtimise või sotsiaalse inseneritöö kaudu) selle ümber marsruutida.
Järeldus
Sertifitseerimisasutuse autoriseerimisel on laiema turvaökosüsteemi osana tohutu potentsiaal ning CAA laialdane kasutuselevõtt ja rakendamine kaitseb sertifikaatide väära väljastamise eest. Kuigi CAA üksi ei peata iga sertifikaadi valesti väljastamist, on see hea samm õiges suunas ja SSL.com soovib soovitada teil kaaluda CAA kirjete ise kasutamist.
Tehtud tööd
- RFC6844: DNS-i sertifitseerimisasutuse volituse (CAA) ressursiregister
- RFC5070: Juhtumi objekti kirjelduse vahetusvorming
- RFC6546: Reaalajas toimuva võrkudevahelise (RID) kaitseteate edastamine HTTP /TLS
- RFC4033: DNS-i turbe tutvustus ja nõuded
- CA / B foorumi hääletusvoor 125 - CAA andmed
- Vikipeedia kirje DNS-i sertifitseerimisasutuse autoriseerimise kohta
Seotud juhendid
- Millised on nõuded SSL.com SSL-le /TLS Sertifikaadi domeeni kontrollimine?
- Mis on domeeni valideerimisel (DV) kasutatav kordumatu väärtus?
- Domeeninimi SSL /TLS Eelvalideerimine
