Miksi käyttää CAA: ta?
Varmentaja käyttää aina menetelmiä verkkotunnuksen validointi varmistaa, että jokainen SSL /TLS varmennepyyntö on valtuutettu (yleensä varmistamalla, että se on jollain tavalla linkitetty tiettyyn sivustoon, joka käyttää tätä verkkotunnusta).
Esimerkiksi CA voi toimittaa pyynnön esittäjälle erityisen varmennustiedoston. Tämän tiedoston sijoittaminen verkkosivustolle osoittaa, että hakija myös hallitsee kyseistä sivustoa, mutta se ei voi taata oikeutus tämän valvonnan. Hakkeri, joka saa hallinnan sivustosta, voi naamioitua lailliseksi omistajaksi ja voi sitten pyytää ja vastaanottaa SSL /TLS todistus, joka läpäisee minkä tahansa varmentajan vakiotarkastukset ja siten näyttää laillinen. He voisivat sitten kääntyä ympäri ja käyttää sitä SSL /TLS pahoinpitelytodistus kyseisellä sivustolla tai muualla.
CAA auttaa estämään tämäntyyppisen hyväksikäytön määrittelemällä, mitkä varmentajat voivat antaa varmenteita verkkotunnukselle (tai jopa rajoittaa varmenteiden myöntämistä kokonaan). Tämä rajoittaa kaappaajan aiheuttamia vahinkoja - vaikka he hallitsisivatkin sivustoa, heillä on huomattavasti vähemmän vaihtoehtoja saada väärennetty SSL /TLS todistus.
Kuinka CAA toimii
CAA käyttää DNS: ää
- Domain Name System (DNS) on tärkeä osa Internetin infrastruktuuria. Minkä tahansa verkkotunnuksen omistaja ylläpitää DNS-tietueita (ns vyöhyke-tiedostot) osoittamalla verkkotunnuksen nimen IP-osoitteeseen, jossa heidän sivustoaan ylläpidetään, ja antaa meidän kirjoittaa google.com selainikkunaan 216.58.194.46.
DNS-tietueita käytetään yleisesti "Internet-puhelinluettelona", mutta DNS sallii myös erityyppisiä erityistietueita, jotka voivat määrittää muita tietoja verkkotunnukselle.
CAA-tietueet
CAA käyttää erityistä tietuetta nimeltään a Varmentajaviranomaisen valtuutusresurssitietue (CAA-tietue). Ne julkaistaan DNS: llä, ja verkkotunnuksen omistaja lisää vain CAA-tietueita muiden DNS-tietueidensa rinnalle. CAA-tietue sisältää a tag ja arvo, ja tunniste-arvo-pariin viitataan nimellä omaisuus. On myös lippu osoittaa kuinka kriittinen tämä ominaisuus on. Tältä näyttää:
example.com. CAA 0 antaa "ssl.com"
Täällä example.com on toimialue, johon tätä tietuetta sovelletaan, ja CAA ilmoittaa meille, millainen tietue tämä on. 0 on lippu (oletus on nolla - puhumme tästä alla). Tunniste on kysymys ja arvo (lainausmerkeissä) on ssl.com, jotka yhdessä muodostavat kiinteistön.
Liput
Lippuissa on tällä hetkellä vain kaksi tiukasti määriteltyä valtiota: 0 (ei-kriittinen) ja 1 (Kriittinen). Kriittinen lippu kertoo CA: lle siitä täytyy ymmärrä täysin ominaisuusmerkki jatkaaksesi. RFC 6844 jättää muut mahdollisuudet avoimiksi käyttäjän määrittelemälle lipun käytölle (puhumme näistä myös alla).
Tunnisteet
RFC 6844 määrittelee kolmen yleisen tunnisteen käytön: kysymys, ongelma ja jodef. (Kuten lippujen kanssa, se sallii muiden mahdollisten mukautettujen tunnistetyyppien.)
- kysymys tag
- kysymys -tagi määrittää, mikä (jos sellainen on) CA on valtuutettu myöntämään varmenteita tälle verkkotunnukselle. Esimerkiksi verkkotunnuksen esimerkki.com omistaja voi rajoittaa sertifikaattien myöntämisen yhdelle CA: lle (tässä SSnos) käyttämällä seuraavaa DNS-vyöhyketiedostoa:
esimerkki.com. CAA 0: n numero "ssl.com"
Verkkotunnuksen omistaja voi valita useita vyöhykkeitä koskevia tiedostoja verkkotunnukselle:
esimerkki.com. CAA 0 -asiakas "ssl.com" example.com. CAA 0: n numero "comodoca.com"
Yllä olevat tietueet rajoittavat SSL: ää /TLS todistuksen myöntäminen example.com kahdelle CA: lle (SSL.com ja Comodo.com).
- kysymys tietue myös valtuuttaa nimetyn CA: n myöntämään varmenteita määritetyn verkkotunnuksen kaikille aliverkkotunnuksille. Tietotekniikka, joka sallii SSL.com-merkinnän, voi siten sallia sertifikaattien myöntämisen example.com ja aliverkkotunnukset kuten www.example.com, mail.example.com ja jopa erityisen jokerimerkin aliverkkotunnuksen * .esimerkki.fi.
CAA-tietuetta voidaan käyttää rajoittaa myös varmenteiden myöntäminen - tämä tietue kertoo CAA: ta käyttäville varmenteen myöntäjille siitä Nro SSL /TLS todistukset olisi annettava vuodelle example.com ja aliverkkotunnukset Kaikki CA:
esimerkki.com. CAA 0 -asia ";"
(Puolipiste tässä esimerkissä tarkoittaaälä salli mitään täällä", Mutta kuten myöhemmin näytämme, sitä käytetään myös mukautettujen parametrien määrittelyyn.)
Huomaa, että tavallinen ongelmatunniste antaa varmentajan myöntää varmenteen jokerimerkille, ellei…
- ongelma tag
Tämä tunniste määrittää, että varmentaja on valtuutettu antamaan jokerimerkkivarmenteet omistajan verkkotunnukselle (ts * .esimerkki.fi).
Jokerimerkit ovat erityinen tyyppi kattava aliverkkotunnus, ja erityisen varovaisuus ja huomio ansaitaan annettaessa jokerimerkkejä. ongelma -tunniste antaa verkkotunnuksen omistajalle määritellä, mitkä CA: t voivat myöntää varmenteita yleismerkeille erikseen päätoimialueesta tai muista aliverkkotunnuksista. ongelma tunnisteet ovat etusijalla mihin tahansa kysymys tunnisteita. He käyttävät samaa syntaksia kuin kysymys tag. Joitain esimerkkejä:
esimerkki.com. CAA 0 -asiakas "ssl.com" example.com. CAA 0 issuewild ";"
Yllä oleva antaa SSL.com: lle myöntää sertifikaatteja example.com ja kaikki aliverkkotunnukset paitsi jokerimerkille * .esimerkki.fi. (SSL.com: llä eikä millään muulla CA: lla ole oikeutta antaa yleismerkkivarmenteita example.com.)
esimerkki.com. CAA 0 -asia ";" esimerkki.com. CAA 0 issuewild "ssl.com"
Tämä esimerkki kieltää kaikki Varmentajan myöntää varmenteita example.com ja sen aliverkkotunnukset, mutta se luo poikkeuksen sallia SSnosten myöntää yleismerkkivarmenteita (ja vain jokerimerkkisertifikaatit) example.com.
- jodef tag
Kolmas määritelty tunniste on jodef. Tätä tunnistetta voidaan käyttää virheellisten varmennepyyntöjen ilmoittamiseen verkkotunnuksen omistajalle, ja ne näyttävät seuraavalta:
esimerkki.com. CAA 0 iodef "mailto: sertissues@example.com" example.com. CAA 0 jodef "sertikudokset.esimerkki.fi"
Huipputietue antaa CA: lle tiedot, joita tarvitaan sähköposti-ilmoituksen lähettämiseen osoitteeseen certissues@example.com. Toinen kehottaa CA: ta lähettämään tapahtumailmoituksen verkkopalvelulle (verkkotunnuksen omistajan tätä tarkoitusta varten perustama) osoitteessa certissues.example.com. (Kumpaakin tai molempia näistä menetelmistä voidaan käyttää riippuen siitä, kuinka varmentaja ja verkkotunnuksen omistaja ovat määrittäneet toimintonsa.)
jodef Lähetä viestit käyttävät vakiomuotoa, nimeltään Tapahtumaobjektin kuvaus vaihtoformaatti tai IODEF - tästä nimi. (IODEF määritellään RFC 6546.)
CA: n määrittämät liput ja tunnisteet
RFC 6844: ssä kuvattu CAA määrittelee vain kaksi lippuvaltiota (0 ja 1) ja kolme tunnistetta (kysymys, ongelma ja jodef). Se jättää kuitenkin suunnittelun tarpeeksi avoimeksi, jotta varmentajat voivat luoda ja käyttää mukautettuja tunnisteita ja lippuja sertifikaattien myöntämisprosessin määrittelemiseksi. Esimerkkejä voivat olla:
esimerkki.com. CAA 0 -numero "SSL.com; policy = ev"
Tämä tietue käyttää standardia kysymys tunniste ylimääräisellä parametrilla, joka kehottaa varmentajaa käyttämään laajennettua validointia (EV) -käytäntöään myöntäessään sertifikaattia tälle verkkotunnukselle.
esimerkki.com. CAA 128 pca "PCA = 12345"
Verkkotunnuksen omistaja voisi käyttää tätä tietuetta uuden CA: n määrittämän kanssa PCA -tagi osoittaa, että heillä on ensisijainen asiakastili ja asettaa tilinumero numeroparametriksi. (Lippu voi olla myös mukautettu arvo, jopa 255.) Riippuen siitä, miten varmentaja perustaa tilin, tämä voi mahdollistaa tietyt laskutusmenetelmät, ylimääräisen tilille määritetyn varmennuksen tai muun erityisen käsittelyn.
Hyvät ja huonot puolet
Plussat…
Nämä ovat useita erinomaisia syitä käyttää CAA: ta. Tärkein ja tärkein etu on CAA: n kyky vähentää huomattavasti varmenteiden väärinkäytön riskiä. Tämä auttaa suojaamaan verkkotunnustasi, yritystäsi ja online-identiteettiäsi. Mahdolliset hyökkääjät, jotka ovat saattaneet löytää virheen tietyn CA: n ohjelmistosta, eivät voi käyttää sitä SSL-varmenteiden myöntämiseen verkkotunnuksellesi. Lisäksi käyttämällä iodef-tagia saat raportin, jos yritetään hyödyntää.
CAA: n suunnittelu lisää tietoturvaa, mutta voi myös mahdollistaa resurssien tarkemman kohdentamisen - esimerkiksi yritys voisi perustaa tietueita, jotta myynti- ja markkinointiosasto voi (tai rajoittaa) ostaa SSL-varmenteita osoitteeseen sales.example.com määrätystä lähteestä.
Lisäksi CAA tarjoaa suurta joustavuutta. Verkkotunnuksen omistajalle se käyttää DNS-resurssitietueita, jotka ovat heidän hallussaan ja joita voidaan muuttaa tarpeen mukaan, joten niitä ei ole sidottu tiettyyn varmentajaan (ja sillä voi olla useampi kuin yksi varmentaja, jolla on valtuudet antaa tietueita tietylle verkkotunnukselle). . CA: n osalta, myös räätälöityjen käyttötarkoitusten lisäksi, CA / B-foorumin (ryhmä, joka asettaa standardit CA: n ja selaimen tietoturva-asioille) hiljattain hyväksymät säännöt voivat sallia CAA-tietueiden käytön validointitarkoituksiin, mikä tarjoaa toisen hyvän syyn niiden hyödyntämiseen.
… Ja miinukset
Suurin yksittäinen asia CAA: n kanssa on, että kaikki CA: t eivät ole hyväksyneet sitä. CA / B-foorumin perusvaatimukset (jotka kaikki luotetut varmentajat täyttävät) käskevät varmentajaa määrittelemään, missä määrin se tukee CAA: ta online-asiakirjoissaan. Tämän kirjoituksen jälkeen CAA: n käyttö on kuitenkin vain suositeltu, ei vaadittu. Varmentajaviranomaisiin, jotka eivät ole CAA: n mukaisia, voidaan silti kohdistaa asiaan, ja kunnes CAA on laajemmassa käytössä, kaappaaja pystyy todennäköisesti löytämään vaatimustenvastaisen CA: n, joka haluaa myöntää vilpillisen varmenteen.
Tähän liittyvä haitta on, että käyttäjä ei voi edes CAA-tietueiden ollessa paikallaan valvoa varmenteen myöntäjä käyttää sitä. Varmentajan on oltava RFC 6844 -standardin mukainen, jotta näitä tietueita voidaan käyttää, ja vaatimustenvastainen varmentaja voi yksinkertaisesti jättää huomiotta verkkotunnuksen omistajan nimenomaiset toiveet, jotka on ilmoitettu CAA-tietueissaan.
Sekä toimialueen omistajan että varmentajan on määritettävä CAA oikein. Salataan (joka tukee CAA: ta) äskettäin ilmoitti pienestä ongelmasta koodikantansa kanssa mikä valitettavasti johti CAA: n sääntöjen huomiotta jättämiseen ja kuuden varmenteen väärään myöntämiseen. Mikään näistä ei ollut haitallinen poikkeus (ja kiitos Let's Encrypt -tiimille ongelman ratkaisemisesta ja ilmoittamisesta muutaman tunnin sisällä löytämisestä). Tämä korostaa kuitenkin, että vaatimustenmukainen varmentaja on täytyy toteuttaa CAA moitteetta.
Toinen mahdollinen asia on CAA: n luottamus DNS: ään. Ellei verkkotunnuksen omistaja suojaa nimipalvelujaan, tämä voi olla hyökkäyksen vektori. RFC 6844 ehdottaa toteuttamista Verkkotunnusjärjestelmän suojauslaajennukset (DNSSEC), joka käyttää digitaalisesti allekirjoitettuja DNS-tietueita tietojen todentamiseen ja DNS-väärentämisen uhan torjuntaan.
Lopuksi, vaikka CAA olisi paikallaan ja oikein toteutettu, CAA-tietue ei sellaisenaan voi täysin estää väärennettyjen varmenteiden myöntämistä. Vaikka CAA on hyödyllinen ja tärkeä työkalu hyökkääjän vaihtoehtojen rajoittamiseen, kaappaaja, jolla on riittävät käyttöoikeudet (esimerkiksi ohjaamalla DNS: ää tai sosiaalisen suunnittelun avulla), voi pystyä reitittämään sen ympärille.
Yhteenveto
Sertifiointiviranomaisen valtuutuksella on mahtava potentiaali osana laajempaa turvallisuusekosysteemiä, ja CAA: n laaja hyväksyminen ja käyttöönotto suojaa sertifikaattien väärinkäytöksiltä. Vaikka on valitettavaa, että kaikki sertifikaattien myöntäjät eivät tällä hetkellä tue CAA: ta, keskustellaan siitä, tehdäänkö tästä voimakkaammin ehdotettu tai pakollinen kaikille CA: lle. Vaikka CAA yksin ei pysäytä kaikkea sertifikaattien väärinkäyttöä, se on hyvä askel oikeaan suuntaan, ja SSL.com kehottaa sinua harkitsemaan CAA-tietueiden käyttöä itse.
Viitteet
- RFC6844: DNS-sertifiointiviranomaisen valtuutuksen (CAA) resurssitietue
- RFC5070: Tapahtumaobjektin kuvausmuoto
- RFC6546: Reaaliaikaisen verkkojen välisen puolustusviestin (RID) siirto HTTP /TLS
- RFC4033: Johdatus DNS-tietoturvaan ja vaatimukset
- CA / B-keskustelupalsta 125 - CAA-tietueet
- Wikipedia-merkintä DNS-sertifiointiviranomaisen valtuutuksesta
