Waarom CAA gebruiken?
Computerwetenschappers Phillip Hallam-Baker en Rob Stradling ontwikkelden CAA als reactie op de groeiende bezorgdheid over de veiligheid van publiekelijk vertrouwde certificeringsinstanties. Dit initiatief valt onder de Internet Engineering Task Force (IETF), een toonaangevende organisatie voor de ontwikkeling van standaarden (SDO) voor het internet. De IETF creëert vrijwillige standaarden die breed worden overgenomen door internetgebruikers, netwerkoperators en leveranciers van apparatuur, en die de evolutie van het internet beïnvloeden.
De IETF documenteert haar technische standaarden in publicaties die bekend staan als RFC's (Requests for Comments). Deze documenten schetsen de belangrijkste aspecten van internetinfrastructuur, waaronder adressering, routering en transporttechnologieën. CAA wordt specifiek gedefinieerd in RFC 6844.
Een certificeringsinstantie (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.
Wat is een CNAME?
Een CNAME-record is een type DNS-configuratie waarmee één domein, zoals winkel.mijnbedrijf.com, om als alias voor een ander te fungeren, zoals mijnbedrijf.com. In plaats van het beheren van meerdere A-records om IP-adreswijzigingen weer te geven, vereenvoudigt een CNAME dit door de alias naar het doeldomein te verwijzen. Deze aanpak is zeer nuttig voor bedrijven die regelmatig van webhost of CDN-provider wisselen. Bovendien zijn CNAME-records van onschatbare waarde voor het bouwen van failoversystemen, waarbij verkeer van een primaire server naar een secundaire server wordt geleid, waardoor de continuïteit van de service tijdens storingen wordt gewaarborgd.
In de context van Certificate Authority Authorization (CAA) beïnvloeden CNAME-records het proces door CAA-controles om te leiden naar het doeldomein. Bijvoorbeeld, als winkel.mijnsite.net gebruikt een CNAME om te verwijzen naar mijnsite.neteen CA die een CAA-controle uitvoert, zal de records evalueren op mijnsite.net om de autorisatie voor het uitgeven van een certificaat te verifiëren. Als het CAA-record op mijnsite.net de CA niet autoriseert, kan het certificaat niet worden uitgegeven. Dit zorgt voor consistente handhaving van CAA-beleid, zelfs wanneer domeinen CNAME-records gebruiken voor DNS-aliasing.
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). 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 volledig de eigenschapstag begrijpen om verder te gaan. RFC 6844 laat andere mogelijkheden open voor door de gebruiker gedefinieerd vlaggebruik (meer hierover hieronder).
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).
Wildcards kunnen een onbeperkt aantal subdomeinen omvatten, dus speciale zorg en aandacht is geboden bij het uitgeven van wildcardcertificaten. 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.)
De issuemail-tag voor S/MIME
Een belangrijke ontwikkeling in CAA is de uitbreiding naar S/MIME (Secure/Multipurpose Internet Mail Extensions)-certificaten, geformaliseerd in RFC 9495. S/MIME certificaten bieden e-mailbeveiliging via authenticatie, gegevensprivacy en berichtintegriteit. Het CA/Browser Forum heeft een nieuwe CAA-eigenschapstag geïntroduceerd, genaamd "issuemail", specifiek voor het beheren van de uitgifte van S/MIME certificaten.
Vanaf 15 september 2024 wordt CA's aangeraden om CAA-controles te implementeren voor S/MIME certificaten, met verplichte implementatie vereist vóór 15 maart 2025. Het standaard CAA-registratieformulier voor e-mailadressen ziet er als volgt uit:
mail.client.example CAA 0 probleemmail "authority.example"
Deze uitbreiding van CAA naar e-mailcertificaten biedt domeineigenaren dezelfde mate van controle over S/MIME certificaatuitgifte zoals ze dat hebben gedaan TLS certificaten, waardoor het risico op ongeautoriseerde certificaatuitgifte wordt verminderd.
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
Er zijn verschillende uitstekende redenen om CAA te gebruiken. Het belangrijkste voordeel is dat CAA het risico op verkeerde uitgifte van certificaten aanzienlijk kan verkleinen. 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 de iodef-tag een rapport krijgen als er een exploit wordt geprobeerd.
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.
Een nadeel is dat zelfs als CAA-records aanwezig zijn, een gebruiker niet 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
Certification Authority Authorization heeft een enorm potentieel als onderdeel van een breder beveiligingsecosysteem, en wijdverbreide acceptatie en implementatie van CAA zal bescherming bieden tegen verkeerde uitgifte van certificaten. Hoewel CAA alleen niet elke verkeerde uitgifte van certificaten zal stoppen, is het een goede stap in de goede richting, en SSL.com wil u dringend verzoeken 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
Gerelateerde gidsen
- Wat zijn de vereisten voor SSL.com SSL /TLS Validatie van certificaatdomein?
- Wat is de ‘unieke waarde’ die wordt gebruikt bij domeinvalidatie (DV)?
- Domeinnaam SSL /TLS Pre-validatie
