Was ist DANE/TLSA?

Einführung in DANE und TLSA

Die Public-Key-Infrastruktur ( PKI) ist auf Zertifizierungsstellen (CAs) angewiesen , um die Gültigkeit von TLS-Zertifikaten zu gewährleisten . Das Problem besteht darin, dass jede der Hunderten von CAs, denen Browser vertrauen, ein Zertifikat für jede beliebige Domain ausstellen kann – unabhängig davon, ob diese Domain in irgendeiner Beziehung zu der jeweiligen CA steht. Wird auch nur eine dieser CAs kompromittiert, falsch konfiguriert oder unter Druck gesetzt, kann ein Angreifer ein gefälschtes Zertifikat für Ihre Domain erlangen, dem Browser ohne Weiteres vertrauen. Dies ist die strukturelle Schwäche des CA-Vertrauensmodells und keine bloße Theorie. Fälle von fehlerhafter Zertifikatsausstellung sind bereits vorgekommen und werden auch in Zukunft vorkommen.

DANE (DNS-basierte Authentifizierung benannter Entitäten) ist ein Sicherheitsprotokoll, das diese Schwachstelle behebt. Gemäß RFC 6698 ermöglicht DANE Domaininhabern, ihre TLS-Zertifikatsinformationen direkt im DNS zu veröffentlichen, geschützt durch DNSSEC-Signaturen. Vereinfacht gesagt: Anstatt einer von Hunderten Zertifizierungsstellen die Bestätigung eines Zertifikats zu überlassen, erlaubt DANE dem Domaininhaber, genau das Zertifikat oder den Schlüssel anzugeben, den Sie von meinem Server erhalten sollten. Alle anderen Zertifikate sollten abgelehnt werden.

DANE übermittelt diese Informationen über einen TLSA-DNS-Eintrag. Ein TLSA-Eintrag befindet sich in der DNS-Zone einer Domain und teilt Clients mit, welches TLS-Zertifikat oder welchen öffentlichen Schlüssel sie akzeptieren sollen. Zusammen ermöglichen DANE und TLSA Domaininhabern eine deutlich stärkere Kontrolle über die Zertifikatsvalidierung.

Warum die traditionelle PKI allein nicht ausreicht

Um zu verstehen, warum DANE wichtig ist, muss man zunächst die Schwächen der PKI betrachten. Das CA-Modell basiert auf einer einzigen Idee: Browser und Betriebssysteme enthalten eine Liste vertrauenswürdiger Stammzertifizierungsstellen (Root CAs), und jedes von einer dieser CAs signierte Zertifikat wird als gültig behandelt. Das klingt zunächst gut, bis man sich bewusst macht, dass es weltweit über 100 vertrauenswürdige Stammzertifizierungsstellen gibt.

Hier liegt das Problem: Jede dieser Zertifizierungsstellen (CAs) kann Zertifikate für jede beliebige Domain ausstellen. Wird eine CA kompromittiert oder von einer Regierung oder einem anderen Angreifer unter Druck gesetzt, kann sie ein gefälschtes Zertifikat für Ihre Domain erstellen. Die meisten Kunden werden diesem Zertifikat bedenkenlos vertrauen. Dies ist keine bloße Theorie. Im Jahr 2011 wurde die CA DigiNotar gehackt, und es wurden gefälschte Zertifikate für große Domains, darunter Google, ausgestellt. Dieser Vorfall verdeutlichte, wie anfällig das CA-Modell sein kann.

Tools wie Certificate Transparency (CT) -Logs und CAA-Einträge haben die Situation verbessert. Sie warnen jedoch meist erst, nachdem ein ungültiges Zertifikat bereits ausgestellt wurde. DANE hingegen ist eine Präventivmaßnahme. Es legt fest, welche Zertifikate auf DNS-Ebene akzeptiert werden, bevor ein TLS-Handshake manipuliert werden kann.

Wie DNSSEC DANE ermöglicht

DANE funktioniert nicht eigenständig. Es ist vollständig von DNSSEC (Domain Name System Security Extensions) abhängig. Ohne DNSSEC würde das Hinterlegen von Zertifikatsinformationen im DNS wenig nützen, da DNS-Einträge relativ leicht manipuliert werden können.

DNSSEC fügt kryptografische Signaturen in die gesamte DNS-Hierarchie ein. Jede Ebene des DNS-Baums, von der Root-Zone über die Top-Level-Domain (TLD) bis hin zu Ihrer spezifischen Domain-Zone, signiert die darunterliegenden Einträge. Wenn ein Resolver einen TLSA-Eintrag abruft, ermöglicht DNSSEC die Überprüfung, ob der Eintrag echt und unverändert ist.

Man kann sich DNS ohne DNSSEC wie einen Brief ohne Sicherheitssiegel vorstellen. Jeder, der ihn unterwegs bearbeitet, könnte den Inhalt verändern. DNSSEC fügt dieses Siegel in jedem Schritt hinzu. DANE nutzt dann diesen versiegelten, vertrauenswürdigen Kanal, um verbindliche Anweisungen darüber zu übermitteln, welche TLS-Zertifikate akzeptiert werden.

Damit DANE Sie tatsächlich schützt, muss DNSSEC vollständig implementiert und durchgängig validiert sein – von der autoritativen DNS-Zone bis hin zum auflösenden Client. DANE, das auf unsignierten DNS-Servern basiert, bietet keine wirkliche Sicherheit.

TLSA-Datensätze und ihre Felder verstehen

Ein TLSA-Eintrag wird unter einem bestimmten DNS-Namen veröffentlicht und enthält das Protokoll, den Port und die Domain des Dienstes. Beispielsweise würde der TLSA-Eintrag für HTTPS auf Port 443 unter example.com wie folgt aussehen:

_443._tcp.example.com. IN TLSA <Usage> <Selector> <MatchingType> <CertificateData>

Jedes der vier Felder hat eine spezifische Aufgabe:

• Zertifikatsnutzung (0 bis 3): Dieses Feld legt fest, worauf der Datensatz verwiesen wird. Die Verwendungsmethode 3, bekannt als DANE-EE, ist die strengste Option. Sie verweist direkt auf das eigene Zertifikat oder den Schlüssel des Servers und umgeht die herkömmliche CA-Validierung vollständig.
• Auswahl (0 oder 1): Dies teilt dem Client mit, ob er das vollständige Zertifikat (0) oder nur die SubjectPublicKeyInfo, also den öffentlichen Schlüssel (1), abgleichen soll. Das Festlegen des öffentlichen Schlüssels ist im Allgemeinen vorzuziehen, da dieser auch bei einer Zertifikatserneuerung gültig bleibt, solange das Schlüsselpaar unverändert bleibt.
• Übereinstimmungstyp (0, 1 oder 2): Dies definiert die Darstellung der Zertifikatsdaten. Der Wert 1 bedeutet SHA-256, der Wert 2 bedeutet SHA-512. Die Verwendung eines Hashwerts wird dringend empfohlen, um die Größe der DNS-Einträge überschaubar zu halten.
• Zertifikatszuordnungsdaten: Dies ist der tatsächliche Wert, entweder ein Hashwert oder das Rohzertifikat bzw. der Rohschlüssel, den der Client während des TLS-Handshakes mit dem vom Server vorgelegten Zertifikat vergleicht.

Ein Server, der ein von einer Zertifizierungsstelle signiertes Zertifikat verwendet, kann die Methode 1 (DANE-TA) nutzen, um den öffentlichen Schlüssel der ausstellenden Zertifizierungsstelle zu verwenden. Ein Server mit einem selbstsignierten Zertifikat würde typischerweise die Methode 3 (DANE-EE) verwenden, um direkt sein eigenes Endbenutzerzertifikat zu verwenden.

Wie DANE vor Man-in-the-Middle- und Downgrade-Angriffen schützt

DANE ist besonders nützlich, wenn man sieht, wie es zwei der gefährlichsten Angriffsarten in der Netzwerksicherheit blockiert: Man-in-the-Middle- Angriffe (MITM) und TLS-Downgrade-Angriffe.

Bei einem Man-in-the-Middle-Angriff positioniert sich ein Angreifer zwischen Client und Server. Er fängt die Verbindung ab und präsentiert dem Client sein eigenes Zertifikat, während er den Datenverkehr an den echten Server weiterleitet. Gelingt es dem Angreifer, ein gefälschtes, aber von einer Zertifizierungsstelle als vertrauenswürdig eingestuftes Zertifikat für die Zieldomäne zu erlangen, kann der Client den Einbruch nicht erkennen. DANE schließt diese Sicherheitslücke. Selbst wenn das gefälschte Zertifikat für den Browser gültig erscheint, stimmt es nicht mit dem TLSA-Eintrag im DNS überein, und ein DANE-fähiger Client verweigert die Verbindung.

Downgrade-Angriffe funktionieren anders. Der Angreifer manipuliert den TLS-Handshake, um beide Seiten zur Verwendung einer älteren, schwächeren Protokollversion oder Verschlüsselungssuite zu zwingen, die leichter zu knacken ist. Manche Downgrade-Angriffe gehen noch weiter und entfernen die Verschlüsselung vollständig durch SSL-Stripping. DANE hilft, dies in Kombination mit SMTP-Sicherheitstools wie STARTTLS zu verhindern. Wenn ein Mailserver einen TLSA-Eintrag für seinen SMTP-Port veröffentlicht, weiß der sendende Mail Transfer Agent (MTA), der diesen Eintrag validiert, dass TLS erforderlich ist und welches Zertifikat zu erwarten ist. Jeder Versuch, TLS herabzustufen oder zu entfernen, wird dadurch erkennbar.

Es ist wichtig, die Grenzen von DANE offen anzusprechen. Die Browserunterstützung ist uneinheitlich. Gängige Browser validieren TLSA-Einträge für HTTPS nicht nativ, daher profitiert das alltägliche Surfen im Web ohne zusätzliche Plugins oder individuelle Konfigurationen nicht von DANE. DANE funktioniert am besten in Server-zu-Server-Umgebungen, insbesondere bei der E-Mail-Zustellung, und in Umgebungen, in denen die gesamte Technologieinfrastruktur unter Ihrer Kontrolle steht.

Wie Verschlüsselungsberatung helfen kann

DANE bietet eine wichtige Kontrollebene für die TLS-Zertifikatvalidierung, bringt aber gleichzeitig erhebliche operative Komplexität mit sich. DNSSEC muss vollständig implementiert und validiert sein. TLSA-Einträge müssen bei jeder Zertifikatserneuerung synchron aktualisiert werden. Und die zugrundeliegende PKI-Basis muss solide sein, bevor DNS-Einträge verknüpft werden. Dies sind keine einmaligen Aufgaben, sondern fortlaufende operative Verantwortlichkeiten, die mit dem Wachstum Ihrer Zertifikatsumgebung zunehmen.

Die PKI-Dienste und der CertSecure Manager von Encryption Consulting gehen beide Seiten dieser Herausforderung an – die Architektur und die laufende Verwaltung.

Für Organisationen, die ihre PKI-Grundlage aufbauen oder absichern:

Unsere PKI-Services unterstützen Sie bei der Konzeption und Implementierung einer Zertifizierungsstellenhierarchie, die speziell für Umgebungen mit strengen Anforderungen an die Zertifikatskontrolle entwickelt wurde. Ob Sie DANE-EE zur direkten Anbindung an Serverzertifikate oder DANE-TA zur Verankerung des Vertrauens in einer internen Zertifizierungsstelle nutzen – die zugrundeliegende PKI-Architektur muss diese Anforderungen erfüllen. Wir gewährleisten dies mit FIPS 140-3-konformer HSM-Unterstützung, dokumentierten Zertifikatsrichtlinien und einer Implementierung, die auch kritischen Prüfungen standhält.

Für die anhaltende operative Herausforderung, die TLSA-Aufzeichnungen aufeinander abzustimmen:

Eines der größten Risiken bei der DANE-Implementierung ist die Inkonsistenz von TLSA-Einträgen bei der Zertifikatserneuerung. Stimmt das neue Zertifikat nicht mit dem veröffentlichten TLSA-Eintrag überein, schlagen Verbindungen fehl. CertSecure Manager überwacht alle Zertifikate in Ihrer Umgebung, kennzeichnet Zertifikate, deren Erneuerung bevorsteht, und bietet Ihrem Team die nötige Transparenz, um TLSA-Einträge zu aktualisieren, bevor eine Diskrepanz zu einem Ausfall führt. Dabei spielt es keine Rolle, welche Zertifizierungsstelle das Zertifikat ausgestellt hat oder wo es bereitgestellt ist – alle Informationen werden zentral angezeigt.

Für Organisationen, die DANE zur SMTP-Sicherheit einsetzen, wo die Server-zu-Server-E-Mail-Zustellung von korrekten und aktuellen TLSA-Einträgen abhängt, ist diese Art der proaktiven Zertifikatsverwaltung unerlässlich. Sie bildet die operative Ebene, die DANE nachhaltig und nicht anfällig macht.

Fazit

DANE- und TLSA-Einträge stellen einen bedeutenden Fortschritt für die TLS-Zertifikatsauthentifizierung in Unternehmen dar. Durch die Verankerung von Zertifikatserwartungen in DNSSEC-signierten DNS-Einträgen lässt sich striktes Certificate Pinning erzwingen, ohne sich vollständig auf das globale CA-System zu verlassen. Für Sicherheitsteams, die sich bisher unwohl dabei gefühlt haben, Hunderten von CAs zu vertrauen, die sie nicht kontrollieren können, ist DANE eine praktische und technisch ausgereifte Alternative.

DANE allein ist jedoch keine Komplettlösung. Für eine korrekte Implementierung sind ein solides DNSSEC-System, die sorgfältige Verwaltung von DNS-Einträgen, insbesondere bei Zertifikatserneuerungen, sowie das Wissen um die Verfügbarkeit von Client-Support unerlässlich. Für Organisationen, die sensible Kommunikation verarbeiten, insbesondere E-Mails oder Server-zu-Server-Datenverkehr, ist DANE als Teil eines mehrschichtigen Sicherheitskonzepts eine ernsthafte Überlegung wert.