DANE Grundlagen und Funktionsweise

Diese Seite beschäftigt sich mit DANE - Domain name system based Authenticated Entities - und seiner Abhängigkeit von der DNS-Authentizierung mit DNSSEC. Letztere ist Voraussetzung, um DANE einsetzen zu können.

Diese Seite soll einen Schnelleinstieg in die Grundlagen hinter DANE bieten, kann aber nicht alle Protokolloptionen und Konfigurationsmöglichkeiten darlegen. Hierfür wird auf die folgenden RFCs verwiesen, die diese im Detail beschreiben:

The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA (RFC 6698)
Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE) (RFC 7218)
The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance (RFC 7671)
SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) (RFC 7672)
Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE) (RFC 6394)

Die Motivation hinter DANE liegt in den Schwachpunkten eines rein CA-basierten Vertrauens ("chain-of-trust") in die Gültigkeit von Zertifikaten und deren rechtmäßiger Zugehörigkeit zu einem Server- bzw. Domainbetreiber (also einer "Named Entity"). Dies wird ebenfalls in RFC 6394, "Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)" dargelegt.

Warum brauchen wir (unbedingt) DANE?

TLS-Zertifikate

TLS-Zertifikate (RFC 4346) ermöglichen seit 1999 "Transport layer security" gemäß dem x.509 Standard (RFC 5280), das heißt, sie verschlüsseln den Übertragungskanal von ansonsten unsicheren, öffentlichen Verbindungen im Internet (unter anderem http, smtp, u.a.).

Der Server, zu dem eine TLS-verschlüsselte Verbindung aufgebaut werden soll, hält das Zertifikat vor und ein Client, der eine Verbindung aufbauen will, lädt das Zertifikat herunter. Das Zertifikat enthält Meta-Information (z.B. Herausgeber, Firma, Land, Stadt über den Betreiber und den Hostnamen des Servers bzw. Dienstes). Der Client muss allerdings diesen Informationen vertrauen, da er nicht sicher gehen kann, dass das Zertifikat auch wirklich dem Betreiber des Dienstes gehört.

CAs und RootCA

Da dieses Vertrauen in einen bestimmten Serverbetreiber nur sehr selten direkt sicher gestellt werden kann, wurde ein System an vertrauenswürdigen Zertifizierungsstellen eingeführt.

Es gibt noch eine Reihe von dazwischen gelegenen vertrauenswürdigen Zertifierungsstellen, sogenannte Certificate Authorities (CA), die digitale Zertifikate ausgeben, mit denen ein Serverzertifikat signiert wird.

Um das Vertrauen in diese zu gewährleisten, gibt es übergeordnete, bekannte, und damit als letztendlich vertrauenswürdig angesehene Zertifizierungsstellen (z.B. DFN, Symantec), die ihrerseits ein Zertifikat einer CA signieren. Diese bezeichnet man als Root-Certification Authority (Root CA).

Vertrauenskette ("Chain of Trust")

Um das Vertrauen in ein bestimmtes Serverzertifikat auszusprechen, stellt die CA ein CA-Zertifikat aus. Sie läßt dieses von der RootCA signieren, und das CA-Zertifikat erlaubt als "signing certificate", das Zertifikat eines Serverbetreibers bzw. Dienstes zu signieren. Dadurch bildet sich eine durchgehende Vertrauenskette, die sogenannte "chain of trust".

Damit die Signaturen überprüft werden können, wird dem jeweiligen Zertifikat der öffentliche Schlüssel ("public key"), der zum privaten Schlüssel ("private key") mit dem die (Root)CA das Zertifikat signiert hat, hinzgefügt.

Überprüft man dann das LRZ-Zertifikat, sieht man die Signatur und den Public Key der DFN-CA und der RootCA, als Garant für die Authentizität.

Probleme mit CAs

Wenn also so das Vertrauen authentifiziert werden kann, wo ist das Problem? Das Problem ist, dass

die CAs zu nachlässig mit der Überprüfung der Identität von Zertifikatsantragstellern umgehen,
Sicherheitslücken in automatisierten Überprüfungen bestehen,
gestohlene "zerfitfizierende CA-Zertifikate" im Umlauf sind, mit denen dann beliebige Zertifikate in Namen dieser CA zertifiziert werden konnten
alle als vertrauenswürdig eingestuften CA-Zertifikate im Browser oder OS vorzuhalten sind

Damit wird eine Vertrauensbildung heutzutage quasi unmöglich gemacht. Jeder kann vorgeben, ein (scheinbar) authentisches Zertifikat für eine beliebige Domäne zu besitzen.

DANE - DNS based Authentification of Named Entities

DANE bietet hier eine Alternative. Es soll nicht CAs komplett ersetzen, sondern bietet eine zusätzliche Möglichkeit, die Authentizität eines (selbst-signierten) Zertifikats sicher zu stellen.

Ein Hostname oder Domäne stellt eine "Named Entity" dar. Durch Ablegen des

vollständigen Zertifikats
Hash des Zertifikats
(öffentlichen) Schlüssels, mit dem das Zertifikat signiert wurde
Hash des (öffentlichen) Schlüssels, mit dem das Zertifikat signiert wurde

im DNS kann der Betreiber eines Servers oder Domäne ein Serverzertifikat, das auf einem zu dieser Domäne oder Zone gehörenden Server liegt, als zu diesem realen Objekt/Person (der "Entitled Entity") gehörig authentifizieren. Ein entsprechender Zoneneintrag verknüpft den Port und den Servernamen mit dem dort abgelegten Zertifikat, z.B.:

_25._tcp.dnssec-ws01.ws01.ws.dnssec.bayern. 300    IN TLSA    3 0 1 013027A95A04392917A68B48F9620DBC78783AC6

25 (Port), tcp (Protokoll) dnssec-ws01.ws01.ws.dnssec.bayern. (Hostname des Servers) 300 (TTL in Sekunden) IN TLSA (DNS TLSA-RR) 3 (Certificate Usage: DANE-Entitled Entity) 0 (Selector: Hash des Zertifikats) 1 (Matching Type: RSASHA256) 013027A95A04392917A68B48F9620DBC78783AC6 (Hash)

Vor dem Aufbau einer TLS-verschlüsselten Verbindung liest ein Anfrager dann zuerst über DNS diesen Eintrag aus, empfängt regulär das Zertifikat vom Server, und vergleicht den Hash (oder das vollständige Zertifikat bzw. vollständigen öffentlichen Signer-Schlüssel) mit dem Zertifikat des Servers.

DANE setzt DNSSEC voraus

DANE benutzt sogenannte TLSA-Einträge ("TLS Association Resource Records", siehe RFC 7671) in der Zone im DNS, um Vertrauen in TLS-Zertifikate zu gewährleisten, unabhängig von der "chain-of-trust" durch verschiedene CAs, die ein bestimmtes Zertifikat signiert haben. Dazu muss aber natürlich wiederum der DNS-Antwort vertraut werden.

Dies wird aber durch DNSSEC gelöst. Einer durchgehend DNSSEC-authentifizierten DNS-Antwort von einem (vertrauswürdigen) Resolver, kann (anhand des AD bits - oder über VPN) vertraut werden.

So bietet DANE eine vom Zertifikatsvertrauen unabhängige Überprüfung der Authentizität des Servers, mit dem eine TLS-Verbindung aufgebaut werden soll.

DANE-Abfrage im Detail

Wie läuft also eine DANE-authentifizierte Abfrage ab? Da wie oben geschrieben das Zertifikat mit dem TLSA-Eintrag aus dem autoritativen Nameserver verglichen werden muss, läuft dem Aufbau einer TLS-Verbindung eine DNSSEC-Abfrage voraus.

Die durch einen Client initierten Schritte zum Aufbau einer DANE-authentifizierten Verbindung werden in folgendender Grafik dargestellt. Man spricht hier auch davon, dass Zertifikat mit DANE "gepinnt" wird.

NB: Die Grafik ist mit einer Video-Animation verlinkt.

DANE-authentifiziertes TLS-gesichertes SMTP

DANE-Verbindungen können mit beliebigen Ports erfolgen, und damit jegliche Art von TLS-gesicherten Verbindungen mittels DANE-pinning authentifiziert werden.

Für das "DNSSEC/DANE in Bayern"-Projekt soll dies für die SMTP-Verbindungen zwischen Mailserver an Bayerischen Universitäten und Hochschulen geschehen. Die DANE-gepinnte SMTP-Verbindung ist zwar nur der Spezialfall für Port 25, wird aber etwas komplizierter durch die Tatsache, dass vor der DNS-Abfrage der IP des Mailservers, zuerst die MX-Einträge mit der Liste der Mailserver erfragt werden müssen.

Diese Abfrage muss auch DNSSEC-authentifiziert werden, um die Vertrauenskette nicht zu brechen, und kann noch dadurch komplizierter ausfallen, wenn die MX-Einträge auf Mailserver einer dritten Partei verweisen. Beispielsweise wickelt die TU München ihren Mailverkehr über Mailserver des LRZ ab.

Dadurch ergibt sich für eine TLS-gesicherte SMTP-Verbindung zu einem empfangenden Mailserver mit DANE-Authentifizierung ("Zertifikat-Pinning") folgendes Bild:

NB: Das Bild ist mit einer Animation der Abfragen verlinkt, die diese mehrstufige Abfrage etwas klarer darstellt.

Die Konfiguration des Mailservers, um bei TLS-Verbindungen eine DANE-Authentifizierung durch Auslesen des TLSA-Eintrages durchzuführen, haben wir in unseren Howtos für DANE beschrieben.