Warum CAA verwenden?
Eine Zertifizierungsstelle verwendet immer Methoden von 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.
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"
Hier 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 die Standardeinstellung - darüber werden wir weiter unten sprechen). 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 Verstehen Sie das Property-Tag vollständig, um fortzufahren. RFC 6844 lässt andere Möglichkeiten für die Verwendung von benutzerdefinierten Flags offen (wir werden auch weiter unten darauf eingehen).
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 jedem 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 sind eine besondere Art von Catch-All-Subdomain, und bei der Ausstellung von Wildcard-Zertifikaten ist besondere Sorgfalt und Aufmerksamkeit geboten. Das 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.)
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
Pluspunkte…
Dies sind mehrere gute Gründe für die Verwendung von CAA. Der wichtigste und wichtigste Vorteil ist die Fähigkeit von CAA, das Risiko einer fehlerhaften Ausstellung von Zertifikaten erheblich zu verringern. Dies schützt Ihre Domain, Ihr Unternehmen und Ihre Online-Identität. Potenzielle Angreifer, die möglicherweise 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 können Sie mit dem iodef-Tag einen Bericht abrufen, 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.
… Und Minuspunkte
Das größte Problem bei CAA ist, dass es nicht von allen CAs übernommen wurde. Die Basisanforderungen des CA / B-Forums (die alle vertrauenswürdigen Zertifizierungsstellen erfüllen) weisen eine Zertifizierungsstelle an, in ihrer Online-Dokumentation anzugeben, inwieweit sie CAA unterstützt. Zum jetzigen Zeitpunkt wird jedoch nur CAA verwendet empfohlen, nicht benötigt. Zertifizierungsstellen, die nicht mit CAA kompatibel sind, können weiterhin angesprochen werden, und bis CAA in größerem Umfang eingesetzt wird, kann ein Entführer wahrscheinlich eine nicht konforme CA finden, die bereit ist, ein nicht autorisiertes Zertifikat auszustellen.
Ein damit verbundener Nachteil ist, dass ein Benutzer dies nicht kann, selbst wenn CAA-Datensätze vorhanden sind 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.
Zusammenfassung
Die Autorisierung durch die Zertifizierungsstelle hat ein enormes Potenzial als Teil eines breiteren Sicherheitsökosystems, und die weit verbreitete Einführung und Implementierung von CAA schützt vor einer fehlerhaften Ausstellung von Zertifikaten. Obwohl es bedauerlich ist, dass derzeit nicht alle Zertifizierungsstellen CAA unterstützen, wird diskutiert, dies für alle CAs stärker zu empfehlen oder verbindlich zu machen. Obwohl CAA allein nicht jede Fehlausstellung von Zertifikaten verhindert, ist dies ein guter Schritt in die richtige Richtung, und SSL.com möchte Sie dringend bitten, die Verwendung von CAA-Datensätzen selbst in Betracht zu ziehen.
Bibliographie
- 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
