Waarom CAA gebruiken?
Een CA gebruikt altijd methoden van domeinvalidatie om ervoor te zorgen dat elke SSL /TLS certificaataanvraag is geautoriseerd (meestal door ervoor te zorgen dat het op de een of andere manier is gekoppeld aan een bepaalde site met dat domein).
Een CA kan bijvoorbeeld een speciaal verificatiebestand aan de aanvrager verstrekken. Het plaatsen van dit bestand op de website bewijst dat de aanvrager ook die site beheert, maar kan de wettigheid van die controle. Een hacker die de controle over een site verwerft, kan zich voordoen als de legitieme eigenaar en kan vervolgens een SSL /TLS certificaat dat de standaardcontroles van elke CA doorstaat en dus lijkt rechtmatig. Ze kunnen zich dan omdraaien en die SSL /TLS certificaat voor onheil, op die site of elders.
CAA helpt dit soort misbruik te blokkeren door te definiëren welke CA's certificaten voor een domein mogen uitgeven (of zelfs de uitgifte van certificaten helemaal te beperken). Dit beperkt de schade die een hijacker kan toebrengen - zelfs als ze controle hebben over een site, hebben ze drastisch minder opties om een frauduleuze SSL /TLS certificaat.
Hoe CAA werkt
CAA gebruikt DNS
De Domain Name System (DNS) is een cruciaal onderdeel van de infrastructuur van internet. De eigenaar van elk domein houdt DNS-records bij (binnen de zogenaamde zonebestanden) die hun domeinnaam naar het IP-adres verwijst waar hun site wordt gehost, en laat ons typen google.com in een browservenster in plaats van 216.58.194.46.
DNS-records worden vaak gebruikt als het "telefoonboek voor internet", maar DNS staat ook andere soorten speciale records toe die andere informatie aan een domeinnaam kunnen toewijzen.
CAA-records
CAA gebruikt een speciaal soort record genaamd a Bronvermelding certificeringsinstantie (CAA-record). Deze worden gepubliceerd met behulp van DNS en de domeineigenaar voegt eenvoudig CAA-records toe naast zijn andere DNS-records. Een CAA-record bevat een label en waarde, en het tag-waardepaar wordt een eigendom. Er is ook een vlag aangeven hoe kritiek deze eigenschap is. Hier is hoe een eruit ziet:
voorbeeld.com. CAA 0 probleem "ssl.com"
Hier example.com is het domein waarop dit record van toepassing is, en CAA laat ons weten wat voor soort record dit is. De 0 is de vlag (nul is de standaard - we zullen het hieronder bespreken). De tag is kwestie en de waarde (tussen aanhalingstekens) is ssl.com, die samen het pand vormen.
Vlaggen
Vlaggen hebben momenteel slechts twee strikt gedefinieerde staten: 0 (niet-kritiek) en 1 (kritisch). Een kritische vlag vertelt de CA dat dit het geval is Dan moet je begrijp de eigenschaptag volledig om door te gaan. RFC 6844 laat andere mogelijkheden open voor het gebruik van door de gebruiker gedefinieerde vlaggen (we zullen deze hieronder ook bespreken).
Tags
RFC 6844 definieert het gebruik van drie algemene tags: kwestie, probleemwild en jodef. (Net als bij vlaggen zijn er andere mogelijk aangepaste tagtypen mogelijk.)
De kwestie label
De kwestie tag specificeert welke (indien aanwezig) CA gemachtigd is om certificaten uit te geven voor dit domein. De eigenaar van het domein example.com kan de uitgifte van certificaten bijvoorbeeld beperken tot één CA (hier SSL.com) door het volgende DNS-zonebestand te gebruiken:
example.com. CAA 0-probleem 'ssl.com'
Een domeineigenaar kan ervoor kiezen om meerdere zonebestanden voor een domein in te stellen:
example.com. CAA 0 probleem "ssl.com" example.com. CAA 0-probleem "comodoca.com"
De bovenstaande records beperken SSL /TLS certificaatuitgifte voor example.com naar twee CA's (SSL.com en Comodo.com).
De kwestie record machtigt de genoemde CA ook om certificaten uit te geven voor alle subdomeinen van het opgegeven domein. Een record dat SSL.com toestaat, kan dus de uitgifte van certificaten voor toestaan example.com en subdomeinen zoals www.example.com, mail.voorbeeld.com en zelfs het speciale wildcard-subdomein * .voorbeeld.com.
Een CAA-record kan worden gebruikt om beperken certificaatuitgifte ook - dit record vertelt certificaatautoriteiten die CAA gebruiken dat geen SSL /TLS certificaten moeten worden afgegeven voor example.com en subdomeinen door elke CA:
example.com. CAA 0 probleem ";"
(De puntkomma in dit voorbeeld betekent 'sta hier niets toe", Maar zoals we later zullen laten zien, wordt het ook gebruikt om aangepaste parameters te definiëren.)
Houd er rekening mee dat een standaardprobleemlabel de CA toestaat een certificaat uit te geven voor een jokerteken, tenzij gewijzigd door ...
De probleemwild label
Deze tag geeft aan dat een CA geautoriseerd is om wildcard-certificaten uit te geven voor het domein van de eigenaar (bijv * .voorbeeld.com).
Jokertekens zijn een speciaal soort catch-all subdomein en speciale aandacht en aandacht verdient het uitgeven van jokertekens. De probleemwild Met de tag kan de domeineigenaar definiëren welke CA's certificaten voor jokertekens afzonderlijk van het hoofddomein of andere subdomeinen kunnen uitgeven. probleemwild tags hebben voorrang op alle kwestie tags. Ze gebruiken dezelfde syntaxis als de kwestie label. Een paar voorbeelden:
example.com. CAA 0 probleem "ssl.com" example.com. CAA 0 is een wild ";"
Het bovenstaande stelt SSL.com in staat om certificaten uit te geven voor example.com en alle subdomeinen behalve voor de wildcard * .voorbeeld.com. (Het is SSL.com noch enige andere CA toegestaan om wildcard-certificaten uit te geven voor example.com.)
example.com. CAA 0 probleem ";" example.com. CAA 0 geeft het wild "ssl.com" uit
Dit voorbeeld verbiedt allen Certificaten waaraan certificaten moeten worden afgegeven example.com en zijn subdomeinen, maar creëert een uitzondering om SSL.com toe te staan wildcardcertificaten (en Slechts wildcard certificaten) voor example.com.
De jodef label
De derde gedefinieerde tag is jodef. Deze tag kan worden gebruikt om ongeldige certificaataanvragen aan de domeineigenaar te melden, en ze zien er als volgt uit:
example.com. CAA 0 jodef "mailto: certissues@example.com" example.com. CAA 0 jodef "certissues.example.com"
Het bovenste record geeft de CA-informatie die nodig is om een e-mailmelding naar het adres te sturen certissues@example.com. De tweede geeft de CA de opdracht om een incidentbericht te posten naar een webservice (hiervoor ingesteld door de domeineigenaar) op certissues.example.com. (Een of beide methoden kunnen worden gebruikt, afhankelijk van hoe de CA en de domeineigenaar hun bewerkingen hebben ingesteld.)
jodef berichten plaatsen gebruiken een standaard formaat genaamd de Beschrijving incidentobject Exchange-indeling of IODEF - vandaar de naam. (IODEF is gedefinieerd in RFC 6546.)
Door CA gedefinieerde vlaggen en tags
CAA zoals beschreven in RFC 6844 definieert alleen specifiek twee vlaggenstaten (0 en 1) en drie tags (kwestie, probleemwild en jodef). Het laat het ontwerp echter voldoende open voor CA's om aangepaste tags en vlaggen te maken en te gebruiken om hun certificaatuitgifteproces te definiëren. Voorbeelden zijn:
example.com. CAA 0 probleem "SSL.com; policy = ev"
Dit record gebruikt een standaard kwestie tag met een extra parameter die de CA instrueert om hun Extended Validation (EV) -beleid te gebruiken bij het uitgeven van een certificaat voor dit domein.
example.com. CAA 128 pca "PCA = 12345"
De domeineigenaar kan dit record gebruiken met een nieuw, door de CA gedefinieerd pca tag om aan te geven dat ze een voorkeursklantaccount hebben en stelt het accountnummer in als parameter. (De vlag kan ook een aangepaste waarde zijn van maximaal 255.) Afhankelijk van hoe de CA het account instelt, kan dit bepaalde factureringsmethoden, extra accountgedefinieerde verificatie of andere speciale handelingen mogelijk maken.
Voors en tegens
Pluspunten ...
Er zijn verschillende uitstekende redenen om CAA te gebruiken. Het belangrijkste en belangrijkste voordeel is het vermogen van CAA om het risico van verkeerde uitgifte van certificaten aanzienlijk te verminderen. Dit helpt uw domein, uw bedrijf en uw online identiteit te beschermen. Potentiële aanvallers die mogelijk een bug in de software van een bepaalde CA hebben gevonden, kunnen deze niet misbruiken om SSL-certificaten voor uw domein uit te geven. Bovendien kunt u met het gebruik van de iodef-tag een rapport krijgen als er wordt misbruikt.
Het ontwerp van CAA verhoogt de veiligheid, maar kan ook een meer gedetailleerde toewijzing van middelen mogelijk maken - een bedrijf zou bijvoorbeeld records kunnen opzetten om de verkoop- en marketingafdeling toe te staan (of te beperken) om SSL-certificaten voor sales.example.com aan te schaffen bij een aangewezen bron.
Daarnaast biedt CAA grote flexibiliteit. Voor een domeineigenaar gebruikt het DNS-bronrecords die onder eigen controle staan en die indien nodig kunnen worden gewijzigd, zodat ze niet aan een specifieke CA zijn gebonden (en er kan meer dan één CA zijn geautoriseerd met uitgiftecords voor een bepaalde domeinnaam) . Voor CA's kunnen, zelfs afgezien van aangepast gebruik, door nieuw aangenomen regels door het CA / B Forum (de groep die normen stelt voor CA- en browserbeveiligingsaangelegenheden) CAA-records worden gebruikt voor validatiedoeleinden, wat nog een goede reden is om ze te gebruiken.
... en minnen
Het grootste probleem met CAA is dat het niet door alle CA's is overgenomen. De basisvereisten van het CA / B-forum (waaraan alle vertrouwde CA's voldoen) instrueren een CA om in hun online documentatie te specificeren in welke mate zij CAA ondersteunt. Op het moment van schrijven is CAA-gebruik echter alleen aanbevolen, niet verplicht. Certificaatautoriteiten die niet voldoen aan CAA kunnen nog steeds worden aangevallen, en totdat CAA op grotere schaal wordt gebruikt, zal een kaper waarschijnlijk een niet-conforme CA kunnen vinden die bereid is een frauduleus certificaat uit te geven.
Een aanverwant nadeel is dat zelfs als er CAA-records zijn, een gebruiker dat niet kan afdwingen het gebruik ervan door een certificeringsinstantie. Een CA moet in overeenstemming zijn met RFC 6844 om op die records te kunnen reageren, en een niet-conforme CA kan eenvoudigweg de uitdrukkelijke wensen van de domeineigenaar negeren, zoals aangegeven in hun CAA-records.
CAA moet ook correct worden geconfigureerd door zowel de domeineigenaar als een CA. Let's Encrypt (die CAA ondersteunt) onlangs meldde een klein probleem met hun codebasis wat er helaas toe leidde dat CAA-regels werden genegeerd en de verkeerde uitgifte van zes certificaten. Geen van deze waren schadelijke uitzonderingen (en een pluim voor het Let's Encrypt-team voor het oplossen en rapporteren van het probleem binnen enkele uren na ontdekking). Dit onderstreept echter dat een compatibele certificeringsinstantie Dan moet je CAA implementeren feilloos.
Een ander mogelijk probleem is de afhankelijkheid van CAA van DNS. Tenzij een domeineigenaar zijn naamservices beveiligt, kan dit een aanvalsvector zijn. RFC 6844 stelt implementatie voor Domeinnaamsysteembeveiligingsuitbreidingen (DNSSEC), die digitaal ondertekende DNS-records gebruikt om gegevens te verifiëren en de dreiging van DNS-spoofing te bestrijden.
Ten slotte, zelfs met CAA op zijn plaats en correct geïmplementeerd, kan een CAA-record op zichzelf de uitgifte van frauduleuze certificaten niet volledig voorkomen. Hoewel CAA een nuttig en belangrijk hulpmiddel is om de opties van een aanvaller te beperken, kan een hijacker met voldoende toegang (bijvoorbeeld door DNS te controleren of via social engineering) er omheen lopen.
Conclusie
Autorisatie door certificeringsinstanties heeft een geweldig potentieel als onderdeel van een breder veiligheidsecosysteem, en de brede acceptatie en implementatie van CAA zal beschermen tegen verkeerde uitgifte van certificaten. Hoewel het jammer is dat momenteel niet alle certificaatautoriteiten CAA ondersteunen, is er discussie om dit sterker aanbevolen of verplicht te maken voor alle CA's. Hoewel CAA alleen niet elke verkeerde uitgifte van certificaten zal stoppen, is het een goede stap in de goede richting, en SSL.com zou u willen aansporen om zelf CAA-records te gebruiken.
Referenties
- RFC6844: DNS Certification Authority Authorization (CAA) bronrecord
- RFC5070: Het uitwisselingsformaat voor de beschrijving van het incidentobject
- RFC6546: Transport van real-time inter-netwerk verdediging (RID) -berichten via HTTP /TLS
- RFC4033: Inleiding en vereisten voor DNS-beveiliging
- CA / B Forum Ballot 125 - CAA Records
- Wikipedia-vermelding over autorisatie van DNS-certificeringsinstantie
