Varför använda CAA?
En 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.
Hur CAA fungerar
CAA använder DNS
Smakämnen 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 - vi pratar om detta nedan). 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 förstå helt fastighetsmärket för att fortsätta. RFC 6844 lämnar andra möjligheter öppna för användardefinierad flagganvändning (vi kommer också att prata om dessa nedan).
Tags
RFC 6844 definierar användningen av tre vanliga taggar: fråga, utgivningsvild och jod. (Som med flaggor tillåter det andra potentiella anpassade taggtyper.)
Smakämnen fråga Taggen
Smakämnen 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).
Smakämnen 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 ...
Smakämnen 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).
Wildcards är en speciell typ av underdomän som fångar allt, och särskild vård och uppmärksamhet förtjänar när man utfärdar jokertecken. 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 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.
Smakämnen 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.)
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
Plus ...
Det finns flera utmärkta skäl att använda CAA. Den största och viktigaste fördelen är CAA: s förmåga att kraftigt minska risken för certifikatfelutfärdande. Detta hjälper till att skydda din domän, ditt företag och din online-identitet. Potentiella angripare som kan ha hittat en bugg i en viss CA-programvara kan inte utnyttja den för att utfärda SSL-certifikat för din domän. Med hjälp av iodef-taggen kan du dessutom få en rapport om ett utnyttjande försöks.
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.
... och minus
Det enskilt största problemet med CAA är att det inte har antagits av alla CA: er. CA / B-forumets baslinjekrav (som alla betrodda certifikatutfärdare uppfyller) instruerar en CA att specificera i vilken grad det stöder CAA i sin online-dokumentation. I skrivande stund är dock CAA-användning endast rekommenderas, krävs inte. Certifikatmyndigheter som inte följer CAA kan fortfarande riktas, och tills CAA används i större utsträckning kommer en kapare sannolikt att kunna hitta en CA som inte uppfyller kraven som är villig att utfärda ett skurkbevis.
En relaterad nackdel är att även när CAA-poster finns, 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
Certifieringsmyndighetens auktorisation har en fantastisk potential som en del av ett bredare säkerhetsekosystem, och utbredt införande och implementering av CAA kommer att skydda mot felaktig utfärdande av certifikat. Även om det är olyckligt att inte alla certifikatmyndigheter för närvarande stöder CAA, diskuteras det om att göra detta starkare eller obligatoriskt för alla CA: er. Även om CAA ensam inte kommer att stoppa varje utfä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
