DANE - DNS-based Authentication of Named Entities
Die Hauptaufgabe von DANE (DNS-Based Authentication of Named Entities) ist das Verteilen und Prüfen der öffentlichen Schlüssel bzw. der TLS-Zertifikate mit Hilfe des Domain Name System (DNS). Damit beseitigt DANE verschiedene Schwachstellen von SSL bzw. TLS bei der Authentisierung und erhöht die Sicherheit beim verschlüsselten Transport von E-Mails und dem Zugriff auf verschlüsselte Webseiten.
Prinzipiell können DANE alle Protokolle nutzen, die verschlüsselte Verbindungen ermöglichen.
- HTTPS / HTTP Secure
- SSH - Secure Shell
- S/MIME
- PGP - Pretty Good Privacy (OpenPGP)
- IPsec - Security Architecture for IP
Warum DANE?
SSL bzw. TLS ist das Standardverfahren zum Verschlüsseln des Datentransports im Internet. Leider hat TLS einige Schwachstellen. Insbesondere lässt sich die Authentizität der verwendeten Zertifikate, die von den Servern genutzt werden, nicht immer gewährleisten. Beispielsweise kann jede Zertifizierungsstelle für jeden beliebigen Domain-Namen ein Zertifikat ausstellen, was für Identitätsdiebstahl und Man-in-the-Middle-Angriffe verwendet werden kann. Bisher war man beim Prüfen von Zertifikaten darauf angewiesen, dass die Zertifizierungsstellen bei der Zertifizierung und Validierung von Zertifikaten vertrauenswürdig sind, was aber nicht gewährleistet werden kann. DANE schafft hier Abhilfe, in dem es eine eigene Public-Key-Infrastructure (PKI) auf Basis von DNS mitbringt. Das bedeutet, ein Domain-Inhaber ist beim Erstellen eines Zertifikats nicht mehr auf eine Zertifizierungsstelle angewiesen. Gleichzeitig kann jeder Client ein Zertifikat beim Domain-Inhaber prüfen und ist nicht mehr von Erreichbarkeit und Vertrauenswürdigkeit der Zertifizierungsstelle abhängig.
Wie funktioniert DANE?
DANE verhindert Angriffe auf verschlüsselte Verbindungen, die auf unrechtmäßig ausgestellten Zertifikaten beruhen. Unrechtmäßige Zertifikate können Angreifer bspw. nach einem Einbruch in eine Zertifizierungsstelle (Certification Authority, CA) erzeugen. Das Problem dabei ist, dass unrechtmäßig erstellte Zertifikate aus technischer Sicht einwandfrei sind. Nur dass sie einen anderen Fingerabdruck als das Original haben.
Bei DANE hinterlegt der Server-Betreiber oder Domain-Inhaber den originalen Fingerabdruck seines TLS-Zertifikats (mit dem öffentlichen Schlüssel) als TLSA-Eintrag im Domain Name System (TLSA-Eintrag in der DNS-Zone). Da der Server-Betreiber seine Domain selbst verwaltet, ist er auch der einzige, der den Fingerabdruck im DNS hinterlegen kann. Hier ist die Manipulation durch einen Angreifer nur unter erschwerten Bedingungen möglich.
Der TLSA-Eintrag dient unter anderem auch als Absichtserklärung eine verschlüsselte Verbindung anzunehmen. Das bedeutet, wenn der Server trotz TLSA-Eintrag eine verschlüsselte Verbindung nicht annimmt, dann muss der Client davon ausgehen, dass etwas nicht stimmt. Entweder weil der Verschlüsselungswunsch unterwegs herausgefiltert wurde, oder vielleicht weil der Server falsch konfiguriert ist. Der TLSA-Eintrag wäre so etwas wie eine Absprache, die dann nicht eingehalten wird. In diesem Fall kann die Verbindung oder die Gegenstelle nicht vertrauenswürdig sein. Die Verbindung sollte (muss) dann abgebrochen werden.
Bei DANE wird zum Prüfen von Zertifikaten nicht wie üblich die CA kontaktiert, sondern der DNS des Host- bzw. des Domain-Namens. Die Herausgabe erfolgt über eine per kryptografisch gesicherte DNS-Anfrage (DNSSEC). Bei dieser Gelegenheit bekommt der Client auch gleich den öffentlichen Schlüssel für eine sichere Verbindung.
An dieser Stelle gewährleistet DNSSEC die Authentizität des Absenders der DANE-Informationen und macht Manipulationen vom DNS-Server zum Client sichtbar. Auf diese Weise werden Man-in-the-Middle-Angriffe und Umleitungen verhindert.
Das heißt, der Client kann auf eine sichere Weise auf eine vertrauenswürdige Quelle für die Prüfung der Zertifikate und deren Authentizität zurückgreifen. Um diese Quelle zu manipulieren müsste der Angreifer DNSSEC unter seine Kontrolle bringen, was momentan als fast unmöglich angesehen wird. Das bedeutet, dass durch DANE eine mit TLS verschlüsselte Verbindung sicherer wird, aber immer noch nicht 100%ig sicher ist.
Beim Prüfen des Zertifikats berechnet der Client aus dem Public Key, den er vom Server beim Verbindungsaufbau über das Zertifikat bekommen hat, einen Hash. Den Hash vergleicht er mit dem Fingerabdruck aus dem DNS-Eintrag. Nur wenn beide übereinstimmmen, dann ist der Server authentisiert und eine Vertrauensstellung zwischen Client und Server geschaffen.
Auf diese Weise wird sicher gestellt, dass nur das Original-Zertifikat und kein anderes für gültig erklärt werden kann. Anschließend ist es möglich, eine Verbindung aufzubauen, die dann sicher(er) verschlüsselt ist.
In der Konsequenz ist ein Server-Betreiber nicht mehr auf eine externe Zertifizierungsstelle (CA) angewiesen, sondern kann auch ein selbst signiertes Zertifikat verwenden. Nur für DNSSEC ist noch eine externe Vertrauensstelle notwendig, damit man feststellen kann, dass die DNS-Antwort unverfälscht ist.
Wie sicher ist DANE?
DANE ist ein weiterer Baustein, der dabei hilft, dass Vertrauensmodell von SSL/TLS zu verbessern. Dabei darf man nicht vergessen, dass ein sicherer verschlüsselter Datenaustausch über den gesamten Teil einer Übertragungsstrecke verschlüsselt sein muss. Bei E-Mail ist es zum Beispiel so, dass die Mails unverschlüsselt auf den Servern liegen. Um diese Lücke abzusichern, müssen die Nutzer ihre Mails selbst verschlüsseln. Zum Beispiel mit PGP.
Momentan ist die Unterstützung für DANE auf den Clients und den Servern noch begrenzt. Für alle gängigen Browser gibt es DANE-Addons, mit denen der Nutzer verschlüsselte Verbindungen verifizieren kann. Für Server-Betreiber fehlen entsprechende Domain-Angebote der Webhosting-Provider. Nur wer seinen Server selber betreibt und Zugriff auf seine DNS-Zone hat, kann DANE implementieren.