Warum CAA verwenden?
Die Informatiker Phillip Hallam-Baker und Rob Stradling entwickelten CAA als Reaktion auf wachsende Bedenken hinsichtlich der Sicherheit öffentlich vertrauenswürdiger Zertifizierungsstellen. Diese Initiative ist der Internet Engineering Task Force (IETF) unterstellt, einer führenden Organisation zur Entwicklung von Standards (SDO) für das Internet. Die IETF erstellt freiwillige Standards, die von Internetnutzern, Netzbetreibern und Geräteherstellern weitgehend übernommen werden und so die Entwicklung des Internets beeinflussen.
Die IETF dokumentiert ihre technischen Standards in sogenannten RFCs (Requests for Comments). Diese Dokumente beschreiben wichtige Aspekte der Internet-Infrastruktur, einschließlich Adressierungs-, Routing- und Transporttechnologien. CAA ist speziell definiert in RFC 6844.
Eine Zertifizierungsstelle (CA) verwendet immer Methoden der Domain-Validierung um sicherzustellen, dass jedes SSL /TLS Die Zertifikatanforderung wird autorisiert (normalerweise, indem sichergestellt wird, dass sie in irgendeiner Weise mit einer bestimmten Site verknüpft ist, die diese Domain verwendet).
Beispielsweise kann eine Zertifizierungsstelle dem Anforderer eine spezielle Überprüfungsdatei zur Verfügung stellen. Durch das Platzieren dieser Datei auf der Website wird bewiesen, dass der Anforderer auch diese Website kontrolliert, dies kann jedoch nicht garantiert werden Legitimität dieser Kontrolle. Ein Hacker, der die Kontrolle über eine Site erlangt, kann sich als legitimer Eigentümer tarnen und dann ein SSL / anfordern und empfangen.TLS Zertifikat, das die Standardprüfungen einer Zertifizierungsstelle besteht und somit scheint legitim. Sie könnten sich dann umdrehen und dieses SSL / verwendenTLS Zertifikat für Unfug, auf dieser Website oder anderswo.
CAA hilft dabei, diese Art von Exploit zu blockieren, indem definiert wird, welche Zertifizierungsstellen Zertifikate für eine Domäne ausstellen dürfen (oder sogar die Ausstellung von Zertifikaten insgesamt einschränkt). Dies begrenzt den Schaden, den ein Entführer anrichten kann - selbst wenn er die Kontrolle über eine Site hat, hat er drastisch weniger Möglichkeiten, ein betrügerisches SSL / zu erzielenTLS Zertifikat.
Was ist ein CNAME?
Ein CNAME-Eintrag ist eine Art DNS-Konfiguration, die es einer Domäne ermöglicht, wie beispielsweise store.mybusiness.com, um als Alias für jemand anderen zu fungieren, wie mybusiness.comAnstatt mehrere A-Records für IP-Adressänderungen zu verwalten, vereinfacht ein CNAME dies, indem der Alias auf die Zieldomäne verweist. Dieser Ansatz ist besonders vorteilhaft für Unternehmen, die regelmäßig ihren Webhoster oder CDN-Anbieter wechseln. Darüber hinaus sind CNAME-Records von unschätzbarem Wert für den Aufbau von Failover-Systemen, bei denen der Datenverkehr von einem primären Server auf einen sekundären umgeleitet wird, um die Servicekontinuität bei Ausfällen zu gewährleisten.
Im Rahmen der Certificate Authority Authorization (CAA) beeinflussen CNAME-Einträge den Prozess, indem sie CAA-Prüfungen an die Zieldomäne umleiten. Wenn beispielsweise shop.mysite.net verwendet einen CNAME, um auf meinesite.netwertet eine CA, die eine CAA-Prüfung durchführt, die Datensätze aus für meinesite.net um die Berechtigung zur Ausstellung eines Zertifikats zu überprüfen. Wenn der CAA-Eintrag auf meinesite.net Die Zertifizierungsstelle wird nicht autorisiert, das Zertifikat kann nicht ausgestellt werden. Dadurch wird die konsistente Durchsetzung der CAA-Richtlinien gewährleistet, auch wenn Domänen CNAME-Einträge für DNS-Aliasing nutzen.
Wie CAA funktioniert
CAA verwendet DNS
Das Domain Name System (DNS) ist ein wesentlicher Bestandteil der Infrastruktur des Internets. Der Eigentümer einer Domain verwaltet DNS-Einträge (innerhalb der sogenannten Zonendateien) Zeigen Sie ihren Domain-Namen auf die IP-Adresse, unter der ihre Site gehostet wird, und lassen Sie uns tippen google.com in ein Browserfenster statt 216.58.194.46.
DNS-Einträge werden häufig als „Telefonbuch für das Internet“ verwendet. DNS ermöglicht jedoch auch andere Arten von speziellen Einträgen, mit denen einem Domainnamen andere Informationen zugewiesen werden können.
CAA-Aufzeichnungen
CAA verwendet eine spezielle Art von Datensatz namens a Autorisierungsressourcendatensatz der Zertifizierungsstelle (CAA-Datensatz). Diese werden mithilfe von DNS veröffentlicht, und der Domäneninhaber fügt neben seinen anderen DNS-Einträgen einfach CAA-Einträge hinzu. Ein CAA-Datensatz enthält a Etikett und einem Wertund das Tag-Wert-Paar wird als a bezeichnet Resorts. Es gibt auch eine Flagge Angabe, wie kritisch diese Eigenschaft ist. So sieht man aus:
example.com. CAA 0 Ausgabe "ssl.com"
Dabei steht: example.com ist die Domain, für die dieser Datensatz gilt, und CAA teilt uns mit, um welche Art von Datensatz es sich handelt. Das 0 ist das Flag (Null ist der Standardwert). Das Tag ist Problem und der Wert (in Anführungszeichen) ist ssl.com, die zusammen das Eigentum bilden.
Flags
Flags haben derzeit nur zwei streng definierte Zustände: 0 (unkritisch) und 1 (kritisch). Ein kritisches Flag teilt der Zertifizierungsstelle dies mit sollen Um fortzufahren, müssen Sie das Property-Tag vollständig verstehen. RFC 6844 lässt weitere Möglichkeiten für die Verwendung benutzerdefinierter Flags offen (mehr dazu weiter unten).
Schlüsselwörter
RFC 6844 definiert die Verwendung von drei allgemeinen Tags: Problem, Ausgabewild und iodef. (Wie bei Flags können auch andere potenzielle benutzerdefinierte Tag-Typen berücksichtigt werden.)
Das Problem Etikett
Das Problem Tag gibt an, welche (falls vorhanden) Zertifizierungsstelle berechtigt ist, Zertifikate für diese Domäne auszustellen. Beispielsweise kann der Eigentümer der Domain example.com die Ausstellung von Zertifikaten mithilfe der folgenden DNS-Zonendatei auf eine Zertifizierungsstelle (hier SSL.com) beschränken:
example.com. CAA 0 Ausgabe "ssl.com"
Ein Domaininhaber kann mehrere Zonendateien für eine Domain einrichten:
example.com. CAA 0 gibt "ssl.com" example.com aus. CAA 0 Ausgabe "comodoca.com"
Die obigen Datensätze beschränken SSL /TLS Zertifikatsausstellung für example.com an zwei Zertifizierungsstellen (SSL.com und Comodo.com).
Das Problem record autorisiert die benannte Zertifizierungsstelle außerdem, Zertifikate für alle Subdomänen der angegebenen Domäne auszustellen. Ein Datensatz, der SSL.com zulässt, kann somit die Ausstellung von Zertifikaten für ermöglichen example.com und Subdomains wie www.example.com, mail.beispiel.com und sogar die spezielle Wildcard-Subdomain * .example.com.
Ein CAA-Datensatz kann verwendet werden eine Beschränkung Auch die Ausstellung von Zertifikaten - dieser Datensatz teilt den Zertifizierungsstellen, die CAA verwenden, dies mit nicht SSL /TLS Zertifikate sollten ausgestellt werden für example.com und Subdomains von für CA:
example.com. CAA 0-Problem ";"
(Das Semikolon in diesem Beispiel bedeutet „erlaube hier nichts“, Aber wie wir später zeigen werden, wird es auch verwendet, um benutzerdefinierte Parameter zu definieren.)
Beachten Sie, dass ein Standard-Issue-Tag es der Zertifizierungsstelle ermöglicht, ein Zertifikat für einen Platzhalter auszustellen, sofern dies nicht durch…
Das Ausgabewild Etikett
Dieses Tag gibt an, dass eine Zertifizierungsstelle berechtigt ist, Platzhalterzertifikate für die Domain des Eigentümers auszustellen (d. H. * .example.com).
Wildcards können eine unbegrenzte Anzahl von Subdomains abdecken, daher ist bei der Ausstellung von Wildcard-Zertifikaten besondere Sorgfalt geboten. Die Ausgabewild Mit diesem Tag kann der Domänenbesitzer definieren, welche Zertifizierungsstellen Zertifikate für Platzhalter getrennt von der Hauptdomäne oder anderen Unterdomänen ausstellen können. Ausgabewild Tags haben Vorrang vor allen Problem Stichworte. Sie verwenden dieselbe Syntax wie die Problem Etikett. Einige Beispiele:
example.com. CAA 0 gibt "ssl.com" example.com aus. CAA 0 issuewild ";"
Auf diese Weise kann SSL.com Zertifikate für ausstellen example.com und alle Subdomains ausgeschlossen für den Platzhalter * .example.com. (Weder SSL.com noch eine andere Zertifizierungsstelle dürfen Platzhalterzertifikate für ausstellen example.com.)
example.com. CAA 0-Problem ";" example.com. CAA 0 issuewild "ssl.com"
Dieses Beispiel verbietet alle Zertifizierungsstellen, an die Zertifikate ausgestellt werden sollen example.com und seine Subdomains, erstellt jedoch eine Ausnahme, damit SSL.com Platzhalterzertifikate ausstellen kann (und einzige Platzhalterzertifikate) für example.com.
Das iodef Etikett
Das dritte definierte Tag ist iodef. Dieses Tag kann verwendet werden, um ungültige Zertifikatanforderungen an den Domänenbesitzer zu melden. Diese sehen folgendermaßen aus:
example.com. CAA 0 iodef "mailto: certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"
Der oberste Datensatz enthält die CA-Informationen, die zum Senden einer E-Mail-Benachrichtigung an die Adresse erforderlich sind certissues@example.com. Der zweite Befehl weist die Zertifizierungsstelle an, eine Vorfallnachricht an einen Webdienst (der vom Domäneninhaber zu diesem Zweck eingerichtet wurde) unter zu senden certissues.example.com. (Eine oder beide dieser Methoden können verwendet werden, je nachdem, wie die Zertifizierungsstelle und der Domäneninhaber ihre Vorgänge eingerichtet haben.)
iodef Post-Nachrichten verwenden ein Standardformat namens Ereignisobjekt Beschreibung Exchange-Format oder IODEF - daher der Name. (IODEF ist definiert in RFC 6546.)
Der Issuemail-Tag für S/MIME
Eine wichtige Entwicklung im CAA ist die Erweiterung auf S/MIME (Secure/Multipurpose Internet Mail Extensions)-Zertifikate, formalisiert in RFC 9495. S/MIME Zertifikate bieten E-Mail-Sicherheit durch Authentifizierung, Datenschutz und Nachrichtenintegrität. Das CA/Browser Forum hat ein neues CAA-Eigenschaftstag namens „issuemail“ eingeführt, das speziell für die Steuerung der Ausgabe von S/MIME Zertifikate.
Ab dem 15. September 2024 wird CAs empfohlen, CAA-Prüfungen für S/MIME Zertifikate, deren verbindliche Umsetzung bis zum 15. März 2025 erfolgen muss. Das Standard-CAA-Datensatzformular für E-Mail-Adressen würde folgendermaßen aussehen:
mail.client.example CAA 0 issuemail "authority.example"
Diese Erweiterung der CAA auf E-Mail-Zertifikate bietet Domänenbesitzern das gleiche Maß an Kontrolle über S/MIME Zertifikatsausstellung wie für TLS Zertifikate, wodurch das Risiko einer nicht autorisierten Zertifikatsausstellung verringert wird.
CA-definierte Flags und Tags
CAA wie in RFC 6844 beschrieben definiert nur spezifisch zwei Flag-Zustände (0 und 1) und drei Tags (Problem, Ausgabewild und iodef). Das Design bleibt jedoch so offen, dass Zertifizierungsstellen benutzerdefinierte Tags und Flags erstellen und verwenden können, um ihren Prozess zur Ausstellung von Zertifikaten zu definieren. Beispiele könnten sein:
example.com. CAA 0-Ausgabe "SSL.com; policy = ev"
Dieser Datensatz verwendet einen Standard Problem Tag mit einem zusätzlichen Parameter, der die Zertifizierungsstelle anweist, ihre EV-Richtlinie (Extended Validation) zu verwenden, wenn ein Zertifikat für diese Domäne ausgestellt wird.
example.com. CAA 128 pca PCA = 12345
Der Domäneninhaber kann diesen Datensatz mit einer neuen, von der Zertifizierungsstelle definierten Datei verwenden PKA Tag, um anzuzeigen, dass sie ein bevorzugtes Kundenkonto haben, und legt die Kontonummer als Parameter fest. (Das Flag kann auch ein benutzerdefinierter Wert von bis zu 255 sein.) Abhängig davon, wie die Zertifizierungsstelle das Konto einrichtet, können bestimmte Abrechnungsmethoden, eine zusätzliche kontodefinierte Überprüfung oder eine andere spezielle Behandlung möglich sein.
Vor-und Nachteile
Es gibt mehrere gute Gründe für die Nutzung von CAA. Der wichtigste Vorteil ist, dass CAA das Risiko falsch ausgestellter Zertifikate deutlich reduziert. Dies schützt Ihre Domain, Ihr Unternehmen und Ihre Online-Identität. Potenzielle Angreifer, die einen Fehler in der Software einer bestimmten Zertifizierungsstelle gefunden haben, können diesen nicht ausnutzen, um SSL-Zertifikate für Ihre Domain auszustellen. Darüber hinaus erhalten Sie durch die Verwendung des iodef-Tags einen Bericht, wenn ein Exploit versucht wird.
Das Design von CAA erhöht die Sicherheit, kann aber auch eine detailliertere Zuweisung von Ressourcen ermöglichen. Beispielsweise könnte ein Unternehmen Datensätze einrichten, die es der Vertriebs- und Marketingabteilung ermöglichen (oder einschränken), SSL-Zertifikate für sales.example.com von einer bestimmten Quelle zu erwerben.
Darüber hinaus bietet CAA eine große Flexibilität. Für einen Domänenbesitzer werden DNS-Ressourceneinträge verwendet, die unter ihrer eigenen Kontrolle stehen und bei Bedarf geändert werden können, sodass sie nicht an eine bestimmte Zertifizierungsstelle gebunden sind (und mehr als eine Zertifizierungsstelle mit Ausgabedatensätzen für einen bestimmten Domänennamen autorisiert sein kann). . Für CAs können neu verabschiedete Regeln des CA / B-Forums (der Gruppe, die Standards für CA- und Browsersicherheitsfragen festlegt) die Verwendung von CAA-Datensätzen zu Validierungszwecken ermöglichen, was einen weiteren guten Grund für deren Verwendung darstellt.
Ein Nachteil besteht darin, dass ein Benutzer selbst bei vorhandenen CAA-Einträgen nicht erzwingen seine Verwendung durch eine Zertifizierungsstelle. Eine Zertifizierungsstelle muss RFC 6844-konform sein, damit auf diese Datensätze reagiert werden kann, und eine nicht konforme Zertifizierungsstelle ignoriert möglicherweise einfach die ausdrücklichen Wünsche des Domäneninhabers, die in ihren CAA-Datensätzen angegeben sind.
CAA muss auch sowohl vom Domäneninhaber als auch von einer Zertifizierungsstelle korrekt konfiguriert werden. Lassen Sie uns kürzlich verschlüsseln (was CAA unterstützt) meldete ein kleines Problem mit ihrer Codebasis Dies führte leider dazu, dass CAA-Regeln ignoriert wurden und sechs Zertifikate falsch ausgestellt wurden. Keine dieser Ausnahmen war böswillig (und ein großes Lob an das Let's Encrypt-Team für die Lösung und Meldung des Problems innerhalb von Stunden nach der Entdeckung). Dies unterstreicht jedoch, dass eine konforme Zertifizierungsstelle sollen CAA implementieren einwandfrei.
Ein weiteres potenzielles Problem ist die Abhängigkeit von CAA von DNS. Sofern ein Domaininhaber seine Namensdienste nicht sichert, kann dies ein Angriffsvektor sein. RFC 6844 schlägt die Implementierung vor DNSSEC (Domain Name System Security Extensions), das digital signierte DNS-Einträge verwendet, um Daten zu authentifizieren und die Bedrohung durch DNS-Spoofing zu bekämpfen.
Selbst wenn CAA vorhanden und korrekt implementiert ist, kann ein CAA-Datensatz allein die Ausstellung von nicht autorisierten Zertifikaten nicht vollständig verhindern. Obwohl CAA ein nützliches und wichtiges Werkzeug ist, um die Optionen eines Angreifers einzuschränken, kann ein Hijacker mit ausreichendem Zugriff (z. B. durch Steuern von DNS oder durch Social Engineering) möglicherweise um ihn herum routen.
Fazit
Die Zertifizierungsstellenautorisierung bietet als Teil eines umfassenderen Sicherheitsökosystems enormes Potenzial. Die weitverbreitete Einführung und Implementierung von CAA schützt vor der Fehlausstellung von Zertifikaten. Obwohl CAA allein nicht jede Fehlausstellung von Zertifikaten verhindern kann, ist es ein guter Schritt in die richtige Richtung. SSL.com möchte Sie dringend bitten, die Verwendung von CAA-Datensätzen selbst in Betracht zu ziehen.
Referenzen
- RFC6844: CAA-Ressourceneintrag (DNS Certification Authority Authorization)
- RFC5070: Das Incident-Objekt Beschreibung Exchange-Format
- RFC6546: Transport von Echtzeit-RID-Nachrichten (Inter-Network Defense) über HTTP /TLS
- RFC4033: Einführung und Anforderungen in die DNS-Sicherheit
- CA / B Forum Stimmzettel 125 - CAA Records
- Wikipedia-Eintrag zur Autorisierung der DNS-Zertifizierungsstelle
Verwandte Anleitungen
- Was sind die Anforderungen für SSL.com SSL /TLS Validierung der Zertifikatsdomäne?
- Was ist der „eindeutige Wert“, der bei der Domänenvalidierung (DV) verwendet wird?
- Domain Name SSL /TLS Vorabvalidierung
