Hvorfor bruke CAA?
En CA bruker alltid metoder for domenevalidering for å sikre at hver SSL /TLS sertifikatforespørsel er autorisert (vanligvis ved å sørge for at den på noen måte er koblet til et bestemt nettsted som bruker det domenet).
For eksempel kan en CA gi en spesiell bekreftelsesfil til rekvirenten. Plassering av denne filen på nettstedet viser at rekvirenten også kontrollerer nettstedet, men det kan ikke garantere legitimitet av den kontrollen. En hacker som får kontroll over et nettsted, kan utsette seg som den legitime eieren, og kan deretter be om og motta en SSL /TLS sertifikat som består alle CAs standardkontroller og dermed synes lovlig. De kunne da snu og bruke den SSL /TLS sertifikat for ugagn, på det nettstedet eller andre steder.
CAA hjelper til med å blokkere denne typen utnyttelse ved å definere hvilke CAer som har lov til å utstede sertifikater for et domene (eller til og med begrense sertifikatutstedelse helt). Dette begrenser skaden en kaprer kan påføre - selv om de har kontroll over et nettsted, vil de ha drastisk færre muligheter for å score en useriøs SSL /TLS sertifikat.
Slik fungerer CAA
CAA bruker DNS
De Domain Name System (DNS) er en avgjørende del av infrastrukturen til internett. Eieren av ethvert domene fører DNS-poster (inne i det såkalte sonefiler) peker domenenavnet sitt til IP-adressen der nettstedet deres er vert, og lar oss skrive google.com inn i et nettleservindu i stedet for 216.58.194.46.
DNS-poster brukes ofte som "telefonbok for Internett", men DNS tillater også andre typer spesielle poster som kan tildele annen informasjon til et domenenavn.
CAA-poster
CAA bruker en spesiell type plate kalt a Sertifiseringsinstans autorisasjonsressursjournal (CAA-post). Disse blir publisert ved hjelp av DNS, og domeneeieren legger bare CAA-poster sammen med sine andre DNS-poster. En CAA-post inkluderer en stikkord og en verdi, og tag-verdi-paret blir referert til som en eiendom. Det er også flagg som indikerer hvor kritisk denne egenskapen er. Slik ser du ut:
eksempel.com. CAA 0 utgave "ssl.com"
Her example.com er domenet denne posten gjelder, og CAA gir oss beskjed om hva slags post dette er. De 0 er flagget (null er standard - vi snakker om dette nedenfor). Merkelappen er utstedelse og verdien (i anførselstegn) er ssl.com, som til sammen utgjør eiendommen.
Flagg
Flaggene har bare to strengt definerte tilstander for tiden: 0 (ikke-kritisk) og 1 (kritisk). Et kritisk flagg sier til CA at det må forstå eiendomsmerket for å fortsette. RFC 6844 lar andre muligheter være åpne for brukerdefinert flaggbruk (vi vil også snakke om disse nedenfor).
Tags
RFC 6844 definerer bruken av tre vanlige koder: utstedelse, utstedt vill og iodef. (Som med flagg gir det mulighet for andre potensielle tilpassede taggtyper.)
De utstedelse stikkord
De utstedelse tag spesifiserer hvilken (hvis noen) CA som er autorisert til å utstede sertifikater for dette domenet. For eksempel kan eieren av domenet example.com begrense sertifikatutstedelse til en CA (her, SSL.com) ved å bruke følgende DNS-sonefil:
eksempel.com. CAA 0 utgave "ssl.com"
En domeneeier kan velge å sette opp flere sonefiler for et domene:
eksempel.com. CAA 0 utgave "ssl.com" example.com. CAA 0 utgave "comodoca.com"
Ovennevnte poster begrenser SSL /TLS sertifikatutstedelse for example.com til to CAer (SSL.com og Comodo.com).
De utstedelse posten tillater også den nevnte CA å utstede sertifikater for eventuelle underdomener til det angitte domenet. En post som tillater SSL.com kan således tillate utstedelse av sertifikater for example.com og underdomener som www.example.com, mail.example.com og til og med det spesielle wildcard-underdomenet * .example.com.
En CAA-post kan brukes til begrense sertifikatutstedelse også - denne posten forteller sertifikatmyndigheter som bruker CAA at Nei. SSL /TLS sertifikater bør utstedes for example.com og underdomener etter noen AT:
eksempel.com. CAA 0 utgave ";"
(Semikolonet i dette eksemplet betyr “ikke tillat noe her“, Men som vi vil vise senere, brukes den også til å definere egendefinerte parametere.)
Merk at en standard utstedelseskode tillater CA å utstede et sertifikat for et jokertegn med mindre det er endret av ...
De utstedt vill stikkord
Denne taggen spesifiserer at en CA er autorisert til å utstede jokertegnsertifikater for eierens domene (dvs. * .example.com).
Jokertegn er en spesiell type underdomen, og spesiell omsorg og oppmerksomhet er verdt når du utsteder jokertegn. De utstedt vill tag lar domeneeieren definere hva CAs kan utstede sertifikater for jokertegn separat fra hoveddomenet eller andre underdomener. utstedt vill koder har forrang fremfor alle utstedelse tags. De bruker samme syntaks som utstedelse stikkord. Noen eksempler:
eksempel.com. CAA 0 utgave "ssl.com" example.com. CAA 0 issuewild ";"
Ovenstående lar SSL.com utstede sertifikater for example.com og alle underdomener unntatt for jokertegn * .example.com. (Verken SSL.com eller noen annen CA har lov til å utstede jokertegnsertifikater for example.com.)
eksempel.com. CAA 0 utgave ";" eksempel.com. CAA 0 utstedelses "ssl.com"
Dette eksemplet forbyr alle CAs å utstede sertifikater til example.com og dets underdomener, men oppretter et unntak for å tillate SSL.com å utstede jokertegnesertifikater (og bare jokersertifikater) for example.com.
De iodef stikkord
Den tredje definerte koden er iodef. Denne taggen kan brukes til å rapportere ugyldige sertifikatforespørsler til domeneeieren, og de ser slik ut:
eksempel.com. CAA 0 iodef "mailto: certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"
Topprekorden gir CA-informasjonen som er nødvendig for å sende en e-postvarsling til adressen certissues@example.com. Den andre ber CA overføre en hendelsesmelding til en webtjeneste (satt opp for dette formålet av domeneeieren) kl certissues.example.com. (En eller begge disse metodene kan brukes, avhengig av hvordan CA og domeneeier har satt opp sin virksomhet.)
iodef postmeldinger bruker et standardformat kalt Hendelsesobjekt Beskrivelse Utvekslingsformat eller IODEF - derav navnet. (IODEF er definert i RFC 6546.)
CA-definerte flagg og tagger
CAA som beskrevet i RFC 6844 definerer bare to flaggstater (0 og 1) og tre tagger (utstedelse, utstedt vill og iodef). Imidlertid lar designen være åpen nok til at CAer kan opprette og bruke tilpassede koder og flagg for å definere sertifikatutstedelsesprosessen. Eksempler kan være:
eksempel.com. CAA 0 utgave "SSL.com; policy = ev"
Denne posten bruker en standard utstedelse -kode med en ekstra parameter som instruerer CA til å bruke deres utvidede valideringspolicy (EV) -policy når du utsteder et sertifikat for dette domenet.
eksempel.com. CAA 128 pca "PCA = 12345"
Domeneeieren kan bruke denne posten med en ny, CA-definert PCA for å vise at de har en foretrukket kundekonto og angir kontonummeret som en parameter. (Flagget kan også være en tilpasset verdi på opptil 255.) Avhengig av hvordan CA oppretter kontoen, kan dette gi rom for spesielle faktureringsmetoder, ekstra kontodefinert bekreftelse eller annen spesiell håndtering.
Fordeler og ulemper
Plusser ...
Det er flere gode grunner til å bruke CAA. Den viktigste og viktigste fordelen er CAAs evne til å redusere risikoen for utstedelse av sertifikater sterkt. Dette bidrar til å beskytte domenet ditt, virksomheten din og din online identitet. Potensielle angripere som kan ha funnet en feil i en bestemt CA-programvare, kan ikke utnytte den til å utstede SSL-sertifikater for domenet ditt. Ved å bruke iodef-taggen kan du dessuten få en rapport hvis en utnyttelse blir forsøkt.
CAAs design øker sikkerheten, men kan også tillate mer detaljert tildeling av ressurser - for eksempel kan et selskap sette opp poster for å tillate (eller begrense) salgs- og markedsavdelingen å kjøpe SSL-sertifikater for sales.example.com fra en angitt kilde.
I tillegg tilbyr CAA stor fleksibilitet. For en domeneeier bruker den DNS-ressursposter som er under deres egen kontroll og kan endres etter behov, slik at de ikke er bundet til en spesifikk CA (og kan ha mer enn én CA-autorisert med utgivelsesposter for et gitt domenenavn) . For CAer, selv bortsett fra tilpasset bruk, kan nylig vedtatte regler fra CA / B Forum (gruppen som setter standarder for CA- og nettlesersikkerhetsspørsmål) tillate CAA-poster å bli brukt til validering, noe som gir en annen god grunn til å bruke dem.
... og minus
Det eneste største problemet med CAA er at det ikke har blitt vedtatt av alle CAer. CA / B-forumets grunnlinjekrav (som alle pålitelige CAer oppfyller) instruerer en CA om å spesifisere i hvilken grad den støtter CAA i deres online dokumentasjon. I skrivende stund er imidlertid CAA-bruk bare anbefales, ikke obligatorisk. Sertifikatmyndigheter som ikke er i samsvar med CAA kan fortsatt målrettes, og inntil CAA er i større bruk vil en kaprer sannsynligvis kunne finne en ikke-kompatibel CA som er villig til å utstede et useriøst sertifikat.
En relatert ulempe er at selv når CAA-poster er plassert, kan en bruker ikke håndheve bruken av en sertifikatmyndighet. En CA må være i samsvar med RFC 6844 for at disse postene skal kunne følges, og en CA som ikke overholder rett og slett kan ignorere domeneeierens uttrykkelige ønsker som deklarert i deres CAA-poster.
CAA må også være riktig konfigurert av både domeneeieren og en CA. La oss kryptere (som støtter CAA) nylig rapporterte et mindre problem med kodebasen som dessverre førte til at CAA-regler ble ignorert og feil utstedelse av seks sertifikater. Ingen av disse var ondsinnede unntak (og kudos til Let's Encrypt-teamet for å løse og rapportere problemet innen få timer etter oppdagelsen). Dette understreker imidlertid at en kompatibel sertifikatmyndighet må implementere CAA prikkfritt.
Et annet potensielt problem er CAAs avhengighet av DNS. Med mindre en domeneeier sikrer navnetjenester, kan dette være en vektor for angrep. RFC 6844 foreslår implementering Domenenavn System Security Extensions (DNSSEC), som bruker digitalt signerte DNS-poster for å autentisere data og bekjempe trusselen om forfalskning av DNS.
Til slutt, selv med CAA på plass og korrekt implementert, kan en CAA-post i seg selv ikke helt forhindre utstedelse av falske sertifikater. Selv om CAA er et nyttig og viktig verktøy for å begrense angriperens muligheter, kan en kaprer med tilstrekkelig tilgang (for eksempel ved å kontrollere DNS eller gjennom sosial engineering) være i stand til å rute rundt den.
konklusjonen
Autorisasjon for sertifiseringsmyndigheter har kjempefint potensial som en del av et bredere sikkerhetsøkosystem, og utbredt adopsjon og implementering av CAA vil beskytte mot feil utstedelse av sertifikater. Selv om det er uheldig at ikke alle sertifikatmyndigheter støtter CAA, diskuteres det om å gjøre dette sterkere foreslått eller obligatorisk for alle CAer. Selv om CAA ikke alene vil stoppe alle feilutstedelser av sertifikater, er det et godt skritt i riktig retning, og SSL.com vil oppfordre deg til å vurdere å bruke CAA-poster selv.
Referanser
- RFC6844: DNS-sertifiseringsinstansautorisasjon (CAA) ressursjournal
- RFC5070: Incident Object Description Exchange Format
- RFC6546: Transport av RID-meldinger i sanntid (RID) i sanntid via HTTP /TLS
- RFC4033: Introduksjon og krav til DNS-sikkerhet
- CA / B Forum Ballot 125 - CAA Records
- Wikipedia-oppføring om autorisasjon av DNS-sertifiseringsinstans
