by Gregor Wegberg
With the introduction of Certification Authority Authorization (CAA) domain holders can specify the Certificate Authorities authorized to issue certificates for the domain. This article in German explains CAA and its use.
Zertifizierungsstellen, die in den Browsern von Mozilla, Google und Apple als vertrauenswürdig eingestuft werden, sind seit dem 8. September 2017 dazu verpflichtet CAA Einträge bei der Herausgabe von Zertifikaten zu beachten. Damit muss ein Grossteil der bekannten Zertifizierungsstellen CAA unterstützen und der Einsatz für Domaininhaber lohnt sich.
Vertrauenswürdige Zertifikate können somit nicht mehr durch eine nahezu beliebige Zertifizierungsstelle ausgestellt werden. Diese Einschränkung verringert das Risiko und erhöht den Aufwand für Angreifer, die versuchen ein gültiges Zertifikat für Angriffe zu erlangen.
Gelingt es einem Angreifer ein vertrauenswürdiges Zertifikat für eine Domain zu beantragen, kann dieses verwendet werden um sich als legitime Webseite auszugeben oder um Man-in-the-Middle-Angriffe durchzuführen. Aufgrund des vertrauenswürdigen Zertifikats würde der Nutzer oder seine Software im Normalfall diese Angriffe nicht erkennen. CAA versucht diese fälschliche Ausstellung eines Zertifikats durch eine vertrauenswürdige Zertifizierungsstelle zu verhindern. Der Einsatz von CAA sollte als Teil einer Defense-in-Depth-Strategie angesehen werden.
Bei der Auswahl einer Zertifizierungsstelle sollte auf die Unterstützung und Überprüfung von CAA Einträgen geachtet werden. Bei Sicherheitsprodukten ist die Mitarbeit und Nutzung neuer Technologien zur Verbesserung der Sicherheit besonders wichtig und ein klares positives Zeichen.
Um CAA zu nutzen wird die Domain Name System (DNS) Konfiguration um einen entsprechenden Eintrag ergänzt. Dies führt zu geringen Kosten für die Einführung und den Einsatz von CAA für alle Domains. Besonders für Webseiten, die SSL/TLS für die sichere Kommunikation nutzen, ist der Einsatz von CAA empfohlen.
In den nachfolgenden Kapiteln wird auf die Nutzung von CAA und damit verbundene Stolpersteine auf einer technischen Stufe betrachtet.
Technischer Blick auf CAA
CAA wird in RFC 6844 definiert und führt einen neuen DNS Resource Record (RR) ein mit dem aktuell drei verschiedene Aussagen für eine Domain getroffen werden können. Anhand des folgenden Beispiels werden die verschiedenen Aussagemöglichkeiten diskutiert:
example.net. CAA 0 issue "ca.test" example.net. CAA 0 issue "other-ca.test; UID=123456" example.net. CAA 0 issuewild ";" intern.example.net. CAA 0 issue ";" intern.example.net. CAA 0 iodef "mailto:security@example.net" home.example.net. CAA 0 issuewild "ca.test"
Eine Zertifizierungsstelle prüft auf CAA Einträge von links nach rechts. Wird beispielsweise ein Zertifikat für «admin.ch.eu.example.net» beantragt, wird die Zertifizierungsstelle in folgender Reihenfolge nach CAA Einträgen suchen und die ersten gefundenen anwenden:
- admin.ch.eu.example.net.
- ch.eu.example.net.
- eu.example.net.
- example.net.
- net.
In unserem Fall würde die Zertifizierungsstelle bei «example.net» auf den ersten CAA Eintrag stossen und diesen anwenden (die ersten drei Zeilen in unserem Beispiel). In diesem Fall dürften nur die Zertifizierungsstellen «ca.test» und «other-ca.test» ein Zertifikat für «admin.ch.eu.example.net» ausstellen. Aufgrund der dritten Zeile dürfte aber keine Zertifizierungsstelle Wildcard Zertifikate (z. B. *.eu.example.net) ausstellen.
issue Einträge definieren somit, welche Zertifizierungsstellen ein Zertifikat für eine bestimmte Domain ausstellen dürfen. Falls ein issuewild Eintrag fehlt, gelten issue Einträge auch für Wildcard Zertifikate.
Mit issuewild wird festgehalten, welche Zertifizierungsstellen ein Wildcard Zertifikat ausstellen dürfen. Soll ein Wildcard Zertifikat ausgestellt werden und existiert mindestens ein issuewild Eintrag, werden alle issue Einträge ignoriert.
Die zweite Zeile hat hierbei noch die Besonderheit, dass zusätzliche Informationen enthalten sind in Form von «UID=123456». Solche zusätzlichen Informationen sind nicht standardisiert und abhängig von der Zertifizierungsstelle. In unserem Beispiel würde diese zusätzliche Information festhalten, dass beim Anbieter «other-ca.test» Zertifikate nur mit dem Benutzerkonto «123456» beantragt werden dürfen. Damit kann die Angriffsfläche weiter eingeschränkt werden.
[…] example.net. CAA 0 issuewild ";" intern.example.net. CAA 0 issue ";" intern.example.net. CAA 0 iodef "mailto:security@example.net" […]
Für Subdomains und die Domain «intern.example.net» gelten die drei oben aufgeführten Regeln:
- Es dürfen keine Wildcard Zertifikate ausgestellt werden. Dies aufgrund des
issueEintrags für «intern.example.net» und nicht demissuewildfür «example.net». Es gelten jeweils die CAA Einträge, die als erstes gefunden werden, gemäss der vorhin aufgezeigten Reihenfolge. - Für alle Domains und Subdomains von «intern.example.net» dürfen keine Zertifikate aufgrund der zweiten Regel ausgestellt werden. Dies ist eine spezifischere Aussage als die Regeln für «example.net», bei denen die Ausstellung von Zertifikaten durch zwei Zertifizierungsstellen erlaubt ist. Diese spezifischere Regel überstimmt die beiden weniger spezifischen und gilt alleinig (siehe den weiter oben beschriebenen Prozess zum Auffinden von CAA Einträgen für eine gegebene Domain).
- Nicht autorisierte Anfragen aufgrund der CAA Regeln sollen von der angefragten Zertifizierungsstelle aufgrund des iodef Eintrags per E-Mail an «security@example.net» gemeldet werden.
iodef Einträge bitten Zertifizierungsstellen, nicht autorisierte Anfragen zu melden. Abgesehen von E-Mail-Adressen sind auch HTTP/HTTPS URLs als Werte erlaubt. Weitere Details siehe RFC 6844, Kapitel 5.4. Oneconsult empfiehlt bei Gebrauch von iodef eine E-Mail-Adresse anzugeben. Die Entwicklung einer Webseite, die solche Informationen entgegennehmen und verarbeiten kann, ist allerdings nicht trivial und mit zusätzlichen Kosten verbunden.
[…] home.example.net. CAA 0 issuewild "ca.test"
Die letzte Zeile im Beispiel erlaubt es der Zertifizierungsstelle «ca.test» Wildcard Zertifikate für Domains und Subdomain von «home.example.net» auszustellen. Achtung: Es dürfen aber beliebige Zertifizierungsstellen normale Zertifikate ausstellen! Aufgrund der Reihenfolge mit der nach CAA Einträgen gesucht wird, würde eine Zertifizierungsstelle nur den issuewild Eintrag anwenden und solange kein Wildcard Zertifikat ausgestellt werden soll gibt es keine Beschränkung für Zertifizierungsstellen. Aus diesem Grund ist es wichtig in solchen Fällen einen zusätzlichen issue Eintrag hinzuzufügen. Zum Beispiel mit dem Wert «;» um zu signalisieren, dass nur Wildcard Zertifikate ausgestellt werden dürfen.
Bei der Erstellung solcher CAA Einträge ist die Webapplikation von SSLMate zu empfehlen. Dieser erzeugt basierend auf wenigen Infos die nötigen CAA Einträge für verschiedene DNS Systeme.
Mögliche Stolpersteine
Bei der Einführung von CAA ist die Reihenfolge zu beachten, mit der Zertifizierungsstellen nach CAA Einträgen suchen. Diese wurde zu Beginn des vorherigen Kapitels beschrieben. Gleichsam ist der Unterschied zwischen issue und issuewild von Bedeutung. Werden keine Wildcard Zertifikate eingesetzt, so ist ein issuewild Eintrag mit dem Wert «;» empfohlen. Werden hingegen nur Wildcard Zertifikate ausgestellt, ist ein analoger issue Eintrag empfohlen. Von der Nutzung von Wildcard Zertifikaten wird übrigens aus Sicherheitsgründen abgeraten.
Aufgrund der fehlenden Integritäts- und Authentizitätsgarantien im DNS Protokoll ist es denkbar, dass Angreifer während der unautorisierten Beantragung von Zertifikaten die Kommunikation zwischen der Zertifizierungsstelle und dem von ihr verwendeten DNS Server angreifen und somit CAA Einträge manipulieren oder unterdrücken. Dies kann durch den Domaininhaber mit dem Einsatz von «DNSSEC» verhindert werden. Auch sind Zertifizierungsstellen angehalten, Gegenmassnahmen für diese Art von Angriff einzuleiten. Ein solcher Angriff würde einen signifikanten zusätzlichen Aufwand für die Angreifer bedeuten und damit die Kosten des Angriffs weiter in die Höhe treiben.
Fazit
CAA bietet allem voran Domaininhabern an festzulegen, welche Zertifizierungsstellen autorisiert sind Zertifikate für die Domain auszustellen. Gleichzeitig ist es eine zusätzliche Kontrolle, die Zertifizierungsstellen nutzen können um die fehlerhafte Ausstellung von Zertifikaten zu verhindern. Konsequenterweise sind CAA Einträge nur zum Zeitpunkt eines Antrags auf Ausstellung eines Zertifikats von Relevanz. Sie sind kein Indikator, welche Zertifizierungsstelle ein Zertifikat signiert haben muss und darf vom Client nicht für eine solche Überprüfung verwendet werden. Für diesen Einsatzzweck ist «DANE» in Kombination mit DNSSEC angedacht.
Gregor Wegberg ist Penetration Tester & Security Consultant bei der Oneconsult AG
Über Oneconsult
Die Oneconsult-Unternehmensgruppe ist seit 2003 Ihr inhabergeführter, produkte- und herstellerunabhängiger Schweizer Cybersecurity Services Partner mit Büros in Thalwil (Zürich), Bern und München. Die Oneconsult-Gruppe besteht aus der Holdinggesellschaft Oneconsult International AG und deren Tochtergesellschaften Oneconsult AG und Oneconsult Deutschland GmbH.
30+ hochqualifizierte Spezialisten – darunter zertifizierte Penetration Tester (OPST, OPSA, OSCP, GXPN), IT-Forensiker (GCFA, GCFE, GREM), ISO Security Auditoren (ISO 27001 Lead Auditor) und IT Security Researcher – meistern Ihre anspruchsvollsten Herausforderungen im Informationssicherheitsbereich. Gemeinsam packen wir Ihre externen und internen Bedrohungen, wie Malware-Infektionen, Hacker-/APT-Attacken sowie digitalen Betrug und Datenverlust mit Kerndienstleistungen wie Penetration Tests / Ethical Hacking, APT-Tests unter Realbedingungen und ISO 27001 Security Audits an. Bei Notfällen können Sie rund um die Uhr (24 h x 365 Tage) auf die Unterstützung des Oneconsult Incident Response & IT Forensics Expertenteams zählen.
