Varför använda CAA?
Datavetarna Phillip Hallam-Baker och Rob Stradling utvecklade CAA som svar på växande oro för säkerheten hos offentligt betrodda certifikatmyndigheter. Detta initiativ faller under Internet Engineering Task Force (IETF), en ledande organisation för standardutveckling (SDO) för Internet. IETF skapar frivilliga standarder som är allmänt accepterade av Internetanvändare, nätverksoperatörer och utrustningsleverantörer, vilket påverkar Internets utveckling.
IETF dokumenterar sina tekniska standarder i publikationer som kallas RFC (Requests for Comments). Dessa dokument beskriver viktiga aspekter av Internetinfrastruktur, inklusive adressering, routing och transportteknik. CAA definieras specifikt i RFC 6844.
En certifikatutfärdare (CA) använder alltid metoder för domänvalidering för att säkerställa att varje SSL /TLS certifikatbegäran är godkänd (vanligtvis genom att se till att den på något sätt är länkad till en viss webbplats som använder den domänen).
Till exempel kan en CA tillhandahålla en speciell verifieringsfil till den begärande. Att placera den här filen på webbplatsen bevisar att den sökande också kontrollerar webbplatsen, men den kan inte garantera legitimitet av den kontrollen. En hackare som får kontroll över en webbplats kan maskera sig som den legitima ägaren och kan sedan begära och få en SSL /TLS certifikat som klarar alla CA: s standardkontroller och därmed verkar legitim. De kunde sedan vända och använda den SSL /TLS certifikat för skada, på den webbplatsen eller någon annanstans.
CAA hjälper till att blockera denna typ av utnyttjande genom att definiera vilka certifikatutfärdare som får utfärda certifikat för en domän (eller till och med begränsa certifikatutfärdandet helt och hållet). Detta begränsar skadan som en kapare kan orsaka - även om de har kontroll över en webbplats har de drastiskt färre alternativ för att göra en skurk SSL /TLS certifikat.
Vad är en CNAME?
En CNAME-post är en typ av DNS-konfiguration som tillåter en domän, t.ex store.mybusiness.com, att fungera som ett alias för en annan, som mybusiness.com. Istället för att hantera flera A-poster för att återspegla IP-adressändringar, förenklar en CNAME detta genom att peka aliaset till måldomänen. Detta tillvägagångssätt är mycket fördelaktigt för företag som regelbundet byter webbhotell eller CDN-leverantörer. Dessutom är CNAME-poster ovärderliga för att bygga failover-system, där trafiken dirigeras från en primär server till en sekundär, vilket säkerställer tjänstens kontinuitet under avbrott.
I samband med Certificate Authority Authorization (CAA) påverkar CNAME-poster processen genom att omdirigera CAA-kontroller till måldomänen. Till exempel om shop.mysite.net använder en CNAME för att peka på mysite.net, kommer en CA som utför en CAA-kontroll att utvärdera posterna för mysite.net för att verifiera behörighet för att utfärda ett certifikat. Om CAA rekord på mysite.net inte auktoriserar CA kan certifikatet inte utfärdas. Detta säkerställer konsekvent upprätthållande av CAA-policyer även när domäner använder CNAME-poster för DNS-aliasing.
Hur CAA fungerar
CAA använder DNS
Ocuco-landskapet Domain Name System (DNS) är en avgörande del av infrastrukturen på internet. Ägaren till alla domäner har DNS-poster (inuti den så kallade zonfiler) pekar deras domännamn till IP-adressen där deras webbplats är värd och låter oss skriva google.com i ett webbläsarfönster istället för 216.58.194.46.
DNS-poster används vanligtvis som "telefonbok för Internet", men DNS tillåter också andra typer av specialposter som kan tilldela annan information till ett domännamn.
CAA-poster
CAA använder en speciell typ av skiva som kallas a Certifieringsmyndighetens auktoriseringsresursregister (CAA-post). Dessa publiceras med DNS, och domänägaren lägger helt enkelt till CAA-poster tillsammans med sina andra DNS-poster. En CAA-post innehåller en Taggen och en värde, och tag-värde-paret kallas en egenskapen. Det finns också en flagga som anger hur kritisk den här egenskapen är. Så här ser man ut:
example.com. CAA 0-utgåva "ssl.com"
Här, example.com är den domän som denna post gäller, och CAA låter oss veta vilken typ av post detta är. De 0 är flaggan (noll är standard). Taggen är fråga och värdet (i citattecken) är ssl.com, som tillsammans utgör fastigheten.
Flaggor
Flaggor har för närvarande bara två strikt definierade tillstånd: 0 (icke-kritisk) och 1 (kritisk). En kritisk flagga säger till CA att det måste helt förstå egenskapsetiketten för att fortsätta. RFC 6844 lämnar andra möjligheter öppna för användardefinierad flagganvändning (mer om detta nedan).
Taggar
RFC 6844 definierar användningen av tre vanliga taggar: fråga, utgivningsvild och jod. (Som med flaggor tillåter det andra potentiella anpassade taggtyper.)
Ocuco-landskapet fråga Taggen
Ocuco-landskapet fråga taggar anger vilken (om någon) CA är behörig att utfärda certifikat för den här domänen. Till exempel kan ägaren till domänen exempel.com begränsa certifikatutgivning till en CA (här, SSL.com) med hjälp av följande DNS-zonfil:
exempel.com. CAA 0 utgåva "ssl.com"
En domänägare kan välja att ställa in flera zonfiler för en domän:
exempel.com. CAA 0-utgåvan "ssl.com" exempel.com. CAA 0 utgåva "comodoca.com"
Ovanstående poster begränsar SSL /TLS certifikatutgivning för example.com till två CA: er (SSL.com och Comodo.com).
Ocuco-landskapet fråga post tillåter också den nämnda CA att utfärda certifikat för alla underdomäner i den angivna domänen. En post som tillåter SSL.com kan således tillåta utfärdande av certifikat för example.com och underdomäner som www.example.com, mail.example.com och till och med det speciella jokerteckenunderdomänet * .exempel.se.
En CAA-post kan användas till begränsa certifikatutfärdande också - denna post berättar certifikatutfärdare som använder CAA att Nej SSL /TLS certifikat bör utfärdas för example.com och underdomäner av vilken som helst AC:
exempel.com. CAA 0-utgåva ";"
(Semikolonet i detta exempel betyder "tillåt inte någonting här”, Men som vi kommer att se senare används det också för att definiera anpassade parametrar.)
Observera att en standardutgåva-tagg tillåter CA att utfärda ett certifikat för ett jokertecken om det inte ändras av ...
Ocuco-landskapet utgivningsvild Taggen
Den här taggen anger att en CA är behörig att utfärda jokerteckencertifikat för ägarens domän (dvs. * .exempel.se).
Jokertecken kan stå för en obegränsad uppsättning underdomäner, och därför förtjänar särskild omsorg och uppmärksamhet när man utfärdar jokerteckencertifikat. De utgivningsvild tagg låter domänägaren definiera vad CA: er kan utfärda certifikat för jokertecken separat från huvuddomänen eller andra underdomäner. utgivningsvild taggar har företräde framför alla fråga taggar. De använder samma syntax som fråga märka. Några exempel:
exempel.com. CAA 0-utgåvan "ssl.com" exempel.com. CAA 0 issuewild ";"
Ovanstående tillåter SSL.com att utfärda certifikat för example.com och alla underdomäner utom för jokertecken * .exempel.se. (Varken SSL.com eller någon annan CA är tillåten att utfärda jokerteckencertifikat för example.com.)
exempel.com. CAA 0-utgåva ";" exempel.com. CAA 0 utfärdar "ssl.com"
Detta exempel förbjuder Alla Produkter CA att utfärda certifikat till example.com och dess underdomäner, men skapar ett undantag för att SSL.com ska kunna utfärda jokerteckencertifikat (och endast jokertecken) för example.com.
Ocuco-landskapet jod Taggen
Den tredje definierade taggen är jod. Den här taggen kan användas för att rapportera ogiltiga certifikatbegäranden till domänägaren, och de ser så här ut:
exempel.com. CAA 0 iodef "mailto: certissues@example.com" exempel.com. CAA 0 iodef "certissues.example.com"
Den översta posten ger CA information som behövs för att skicka ett e-postmeddelande till adressen certissues@example.com. Den andra riktar CA till att skicka ett incidentmeddelande till en webbtjänst (inställt för detta ändamål av domänägaren) kl certissues.example.com. (Endera eller båda av dessa metoder kan användas, beroende på hur CA och domänägaren har konfigurerat sin verksamhet.)
jod postmeddelanden använder ett standardformat som kallas Incident Object Description Utbytesformat eller IODEF - därav namnet. (IODEF definieras i RFC 6546.)
issuemail-taggen för S/MIME
En viktig utveckling inom CAA är förlängningen till S/MIME (Secure/Multipurpose Internet Mail Extensions) certifikat, formaliserade i RFC 9495. S/MIME certifikat ger e-postsäkerhet genom autentisering, datasekretess och meddelandeintegritet. CA/Browser Forum har introducerat en ny CAA-egendomstagg kallad "issuemail" specifikt för att kontrollera utfärdandet av S/MIME certifikat.
Från och med den 15 september 2024 rekommenderas CA att implementera CAA-kontroll för S/MIME certifikat, med obligatorisk implementering som krävs senast den 15 mars 2025. CAA-standardformuläret för e-postadresser skulle se ut så här:
mail.client.example CAA 0 issuemail "authority.example"
Denna utvidgning av CAA till e-postcertifikat ger domänägare samma nivå av kontroll över S/MIME certifikatutfärdande som de har för TLS certifikat, vilket minskar risken för obehörig utfärdande av certifikat.
CA-definierade flaggor och taggar
CAA som beskrivs i RFC 6844 definierar endast två flaggstat (0 och 1) och tre taggar (fråga, utgivningsvild och jod). Men det lämnar designen tillräckligt öppen för att CA ska skapa och använda anpassade taggar och flaggor för att definiera deras certifikatutgivningsprocess. Exempel kan vara:
exempel.com. CAA 0-utgåva "SSL.com; policy = ev"
Denna post använder en standard fråga tagg med en extra parameter som instruerar CA att använda sin policy för utökad validering (EV) vid utfärdande av ett certifikat för den här domänen.
exempel.com. CAA 128 pca "PCA = 12345"
Domänägaren kan använda den här posten med en ny CA-definierad pca för att visa att de har ett önskat kundkonto och ställer in kontonumret som en parameter. (Flaggan kan vara ett anpassat värde också upp till 255.) Beroende på hur CA inställer kontot kan detta möjliggöra särskilda faktureringsmetoder, extra kontodefinierad verifiering eller annan speciell hantering.
För-och nackdelar
Det finns flera utmärkta skäl att använda CAA. Den främsta och viktigaste fördelen är Luftfartsverkets förmåga att kraftigt minska risken för felutfärdande av certifikat. Detta hjälper till att skydda din domän, ditt företag och din onlineidentitet. Potentiella angripare som kan ha hittat en bugg i en viss CA:s programvara kan inte utnyttja den för att utfärda SSL-certifikat för din domän. Genom att använda iodef-taggen kan du dessutom få en rapport om ett utnyttjande görs.
CAAs design ökar säkerheten men kan också möjliggöra mer detaljerad fördelning av resurser - till exempel kan ett företag skapa poster för att tillåta (eller begränsa) försäljnings- och marknadsavdelningen att köpa SSL-certifikat för sales.example.com från en utsedd källa.
Dessutom erbjuder CAA stor flexibilitet. För en domänägare använder den DNS-resursposter som är under deras egen kontroll och kan ändras efter behov, så att de inte är bundna till en specifik CA (och kan ha mer än en CA-behörig med utfärda poster för ett visst domännamn) . För CA: er, även förutom anpassade användningar, kan nyligen antagna regler av CA / B-forumet (gruppen som sätter standarder för CA- och webbläsarsäkerhetsfrågor) tillåta CAA-poster att användas för validering, vilket ger ytterligare en god anledning att använda dem.
En nackdel är att även när CAA-register finns på plats kan en användare inte förstärka dess användning av en certifikatutfärdare. En CA måste uppfylla RFC 6844 för att dessa poster ska kunna hanteras, och en CA som inte uppfyller kan helt enkelt ignorera domänägarens uttryckliga önskemål som deklareras i deras CAA-poster.
CAA måste också konfigureras korrekt av både domänägaren och en CA. Låt oss kryptera (som stöder CAA) nyligen rapporterade ett mindre problem med sin kodbas vilket tyvärr ledde till att CAA-regler ignorerades och felutfärdande av sex certifikat. Inget av dessa var skadliga undantag (och kudos till Let's Encrypt-teamet för att lösa och rapportera problemet inom några timmar efter upptäckten). Detta understryker dock att en kompatibel certifikatutfärdare måste implementera CAA felfritt.
En annan potentiell fråga är CAA: s beroende av DNS. Om inte en domänägare säkrar sina namntjänster kan detta vara en vektor för attack. RFC 6844 föreslår implementering Domain Name System Security Extensions (DNSSEC), som använder digitalt signerade DNS-poster för att autentisera data och bekämpa hotet om DNS-förfalskning.
Slutligen, även med CAA på plats och korrekt implementerat, kan en CAA-post i sig inte helt förhindra utfärdande av oseriösa certifikat. Även om CAA är ett användbart och viktigt verktyg för att begränsa en angripares alternativ, kan en kapare med tillräcklig åtkomst (till exempel genom att kontrollera DNS eller genom socialteknik) kunna röra sig runt den.
Slutsats
Certifieringsmyndighets auktorisering har fantastisk potential som en del av ett bredare säkerhetsekosystem, och ett utbrett antagande och implementering av CAA kommer att skydda mot felaktig utfärdande av certifikat. Även om CAA ensamt inte kommer att stoppa varje felutfärdande av certifikat är det ett bra steg i rätt riktning, och SSL.com vill uppmana dig att överväga att använda CAA-poster själv.
Referensprojekt
- RFC6844: CAA-resursregister (DNS Certification Authority Authorization)
- RFC5070: Incident Object Description Exchange Format
- RFC6546: Transport av RID-meddelanden i realtid (RID) via HTTP /TLS
- RFC4033: Introduktion och krav på DNS-säkerhet
- CA / B Forum-omröstning 125 - CAA-poster
- Wikipedia-inlägg om auktorisation för DNS-certifieringsmyndighet
Relaterade guider
- Vilka är kraven för SSL.com SSL /TLS Validering av certifikatdomän?
- Vad är det "unika värdet" som används i domänvalidering (DV)?
- Domännamn SSL /TLS Pre-validering
