Hvorfor bruge CAA?
En CA bruger altid metoder til domænevalidering for at sikre, at hver SSL /TLS certificeringsanmodning er autoriseret (normalt ved at sikre, at den på en eller anden måde er knyttet til et bestemt sted, der bruger dette domæne).
F.eks. Kan en CA muligvis levere en særlig bekræftelsesfil til rekvirenten. Placering af denne fil på webstedet beviser, at rekvirenten også kontrollerer dette websted, men det kan ikke garantere legitimitet af denne kontrol. En hacker, der får kontrol over et websted, kan maskerere sig som den legitime ejer og derefter kunne anmode om og modtage en SSL /TLS certifikat, der består enhver CA's standardkontrol og dermed synes legitim. De kunne derefter vende om og bruge den SSL /TLS certifikat for ondskab, på dette websted eller andre steder.
CAA hjælper med at blokere denne form for udnyttelse ved at definere, hvilke CA'er der har tilladelse til at udstede certifikater til et domæne (eller endda begrænse certifikatudstedelse helt). Dette begrænser den skade, en flykaprer kan påføre - selvom de har kontrol over et websted, har de drastisk færre muligheder for at score en slyngel SSL /TLS certifikat.
Sådan fungerer CAA
CAA bruger DNS
Domain Name System (DNS) er en vigtig del af infrastrukturen på Internettet. Ejeren af ethvert domæne fører DNS-poster (inde i det såkaldte zone filer) peger deres domænenavn til IP-adressen, hvor deres websted er vært, og lader os skrive google.com ind i et browservindue i stedet for 216.58.194.46.
DNS-poster bruges almindeligvis som "telefonbogen til internettet", men DNS tillader også andre typer specielle poster, der kan tildele andre oplysninger til et domænenavn.
CAA-poster
CAA bruger en særlig form for post kaldet a Registreringsautorisations autorisationsressourceregistrering (CAA-registrering). Disse offentliggøres ved hjælp af DNS, og domæneejeren tilføjer blot CAA-poster sammen med sine andre DNS-poster. En CAA-registrering inkluderer en tag og en værdi, og tag-værdiparret kaldes en ejendom. Der er også en flag angiver hvor kritisk denne egenskab er. Sådan ser du ud:
example.com. CAA 0-udgave "ssl.com"
Her, example.com er det domæne denne post gælder for, og CAA fortæller os, hvilken slags post dette er. Det 0 er flag (nul er standard - vi taler om dette nedenfor). Mærket er spørgsmål og værdien (i anførselstegn) er ssl.com, der tilsammen udgør ejendommen.
Flag
Flag har kun to strengt definerede tilstande i øjeblikket: 0 (ikke-kritisk) og 1 (kritisk). Et kritisk flag fortæller CA, at det skal forstå ejendomsmærket for at fortsætte. RFC 6844 efterlader andre muligheder åbne for brugerdefineret brug af flag (vi taler også om disse nedenfor).
Tags
RFC 6844 definerer brugen af tre almindelige tags: spørgsmål, udstedelsesvildt , iodef. (Som med flag giver det mulighed for andre potentielle tilpassede tagtyper.)
spørgsmål tag
spørgsmål tag specificerer, hvilken (hvis nogen) CA er autoriseret til at udstede certifikater til dette domæne. F.eks. Kan ejeren af domænet eksempel.com begrænse certifikatudstedelse til en CA (her SSL.com) ved hjælp af følgende DNS-zonefil:
eksempel.com. CAA 0 udgave "ssl.com"
En domæneejer kan vælge at opsætte flere zonefiler til et domæne:
eksempel.com. CAA 0 udgave "ssl.com" example.com. CAA 0 udgave "comodoca.com"
Ovenstående poster begrænser SSL /TLS certifikatudstedelse for example.com til to CA'er (SSL.com og Comodo.com).
spørgsmål post bemyndiger også den navngivne CA til at udstede certifikater for eventuelle underdomæner på det specificerede domæne. En registrering, der tillader SSL.com, kan således tillade udstedelse af certifikater for example.com og underdomæner som www.example.com, mail.example.com og endda det specielle wildcard-underdomæne * .example.com.
En CAA-post kan bruges til begrænse certifikatudstedelse også - denne post fortæller certifikatmyndigheder, der bruger CAA, at ingen SSL /TLS certifikater skal udstedes for example.com og underdomæner efter enhver Californien:
eksempel.com. CAA 0-udgave ";"
(Semikolonet i dette eksempel betyder “tillad ikke noget her“, Men som vi viser senere, bruges det også til at definere brugerdefinerede parametre.)
Bemærk, at et standardudstedelsesmærke tillader CA at udstede et certifikat til et wildcard, medmindre det er ændret af ...
udstedelsesvildt tag
Dette tag specificerer, at en CA er autoriseret til at udstede jokertegncertifikater til ejerens domæne (dvs. * .example.com).
Jokertegn er en speciel form for fange-alt underdomæne, og særlig pleje og opmærksomhed er fortjent ved udstedelse af jokertegnecertifikater. Det udstedelsesvildt tag lader domæneejeren definere, hvad CA'er kan udstede certifikater til jokertegn separat fra hoveddomænet eller andre underdomæner. udstedelsesvildt tags har forrang frem for ethvert spørgsmål tags. De bruger den samme syntaks som spørgsmål tag. Nogle eksempler:
eksempel.com. CAA 0 udgave "ssl.com" example.com. CAA 0 udstedelsesvild ";"
Ovenstående tillader SSL.com at udstede certifikater for example.com og alle underdomæner undtagen til jokertegn * .example.com. (Hverken SSL.com eller nogen anden CA er tilladt at udstede jokertegnecertifikater til example.com.)
eksempel.com. CAA 0-udgave ";" eksempel.com. CAA 0 udstedelsesvild "ssl.com"
Dette eksempel forbyr alle CA'er, der udsteder certifikater til example.com og dens underdomæner, men opretter en undtagelse for at give SSL.com mulighed for at udstede jokertegnecertifikater (og kun jokertegnecertifikater) for example.com.
iodef tag
Det tredje definerede tag er iodef. Dette tag kan bruges til at rapportere ugyldige certifikatanmodninger til domænejeren, og de ser sådan ud:
eksempel.com. CAA 0 iodef "mailto: certissues@example.com" eksempel.com. CAA 0 iodef "certissues.example.com"
Den øverste rekord giver de CA-oplysninger, der er nødvendige for at sende en e-mail-anmeldelse til adressen certissues@example.com. Den anden instruerer CA til at sende en hændelsesbesked til en webtjeneste (oprettet til dette formål af domænejeren) kl certissues.example.com. (Enten eller begge af disse metoder kan bruges, afhængigt af hvordan CA og domænejeren har konfigureret deres operationer.)
iodef postmeddelelser bruger et standardformat kaldet the Beskrivelse af hændelsesobjekter Udvekslingsformat eller IODEF - deraf navnet. (IODEF er defineret i RFC 6546.)
CA-definerede flag og tags
CAA som beskrevet i RFC 6844 definerer kun specifikt to flagstat (0 og 1) og tre tags (spørgsmål, udstedelsesvildt , iodef). Imidlertid efterlader det designet åbent for, at CA'er kan oprette og bruge brugerdefinerede tags og flag til at definere deres certifikatudstedelsesproces. Eksempler kan være:
eksempel.com. CAA 0-udgave "SSL.com; policy = ev"
Denne post bruger en standard spørgsmål mærke med en ekstra parameter, der instruerer CA til at bruge deres politik for udvidet validering (EV), når der udstedes et certifikat til dette domæne.
eksempel.com. CAA 128 pca "PCA = 12345"
Domæneejeren kunne bruge denne post med en ny, CA-defineret PCA tag for at vise, at de har en foretrukken kundekonto og indstiller kontonummeret som en parameter. (Flagget kan også være en brugerdefineret værdi på op til 255.) Afhængigt af hvordan CA opretter kontoen, kan dette muliggøre særlige faktureringsmetoder, ekstra kontodefineret verifikation eller anden speciel håndtering.
Fordele og ulemper
Plusser ...
Der er flere gode grunde til at bruge CAA. Den største og vigtigste fordel er CAAs evne til i høj grad at reducere risikoen for udstedelse af certifikater. Dette hjælper med at beskytte dit domæne, din virksomhed og din online identitet. Potentielle angribere, der muligvis har fundet en fejl i en bestemt CA's software, kan ikke udnytte den til at udstede SSL-certifikater til dit domæne. Ved at bruge iodef-koden kan du desuden få en rapport, hvis der forsøges en udnyttelse.
CAA's design øger sikkerheden, men kan også give mulighed for en mere detaljeret fordeling af ressourcer - for eksempel kan en virksomhed oprette poster, der tillader (eller begrænser) salgs- og marketingafdelingen at købe SSL-certifikater til sales.example.com fra en bestemt kilde.
Derudover tilbyder CAA stor fleksibilitet. For en domæneejer bruger den DNS-ressourceposter, der er under deres egen kontrol og kan ændres efter behov, så de ikke er bundet til en bestemt CA (og kan have mere end en CA autoriseret med udgiftsposter til et givet domænenavn) . For CA'er, selv bortset fra tilpasset brug, kan nyligt vedtagne regler fra CA / B Forum (gruppen, der sætter standarder for CA- og browsersikkerhedsspørgsmål) give CAA-poster brugt til valideringsformål, hvilket giver en anden god grund til at bruge dem.
... og minus
Det største enkeltstående problem med CAA er, at det ikke er blevet vedtaget af alle CA'er. CA / B-forums baseline-krav (som alle betroede CA'er opfylder) instruerer en CA om at specificere, i hvilken grad det understøtter CAA i deres online-dokumentation. I skrivende stund er CAA-brug dog kun anbefales, ikke påkrævet. Certifikatmyndigheder, som ikke overholder CAA, kan stadig målrettes, og indtil CAA er i bredere brug, vil en kaprer sandsynligvis være i stand til at finde en ikke-kompatibel CA, der er villig til at udstede et useriøst certifikat.
En relateret ulempe er, at selv når CAA-poster er placeret, kan en bruger ikke håndhæve dets anvendelse af en certifikatmyndighed. En CA skal være i overensstemmelse med RFC 6844 for at disse poster kan handles, og en ikke-kompatibel CA kan simpelthen ignorere domæneejerens udtrykkelige ønsker som deklareret i deres CAA-poster.
CAA skal også være konfigureret korrekt af både domæneejeren og en CA. Lad os kryptere (som understøtter CAA) for nylig rapporterede et mindre problem med deres kodebase hvilket desværre førte til, at CAA-regler blev ignoreret og forkert udstedelse af seks certifikater. Ingen af disse var ondsindede undtagelser (og kudos til Let's Encrypt-teamet for at løse og rapportere problemet inden for få timer efter opdagelsen). Dette understreger dog, at en kompatibel certifikatmyndighed skal implementere CAA fejlfrit.
Et andet potentielt problem er CAA's afhængighed af DNS. Medmindre en domæneejer sikrer deres navnetjenester, kan dette være en vektor til angreb. RFC 6844 foreslår implementering Domain Name System Security Extensions (DNSSEC), der bruger digitalt signerede DNS-poster til at autentificere data og bekæmpe truslen om forfalskning af DNS.
Endelig, selv med CAA på plads og korrekt implementeret, kan en CAA-post i sig selv ikke helt forhindre udstedelse af falske certifikater. Selvom CAA er et nyttigt og vigtigt redskab til at begrænse en angribers muligheder, kan en flykaprer med tilstrækkelig adgang (for eksempel ved at kontrollere DNS eller gennem social engineering) muligvis rute rundt om det.
Konklusion
Godkendelse af certificeringsmyndigheder har et fantastisk potentiale som en del af et bredere sikkerhedsøkosystem, og udbredt vedtagelse og implementering af CAA vil beskytte mod forkert udstedelse af certifikater. Selvom det er uheldig, at ikke alle certifikatmyndigheder i øjeblikket støtter CAA, diskuteres der for at gøre dette mere stærkt foreslået eller obligatorisk for alle CA'er. Selvom CAA alene ikke stopper enhver udstedelse af certifikater, er det et godt skridt i den rigtige retning, og SSL.com vil gerne opfordre dig til at overveje at bruge CAA-poster selv.
Referencer
- RFC6844: DNS-certificeringsmyndighedsautorisation (CAA) ressourcepost
- RFC5070: Incident Object Description Exchange Format
- RFC6546: Transport af RID-beskeder i realtid (RID) via HTTP /TLS
- RFC4033: Introduktion og krav til DNS-sikkerhed
- CA / B Forum-stemmeseddel 125 - CAA-poster
- Wikipedia-post om autorisation af DNS-certificeringsmyndighed
