DANE - DNS-Based Authentication of Named Entities

Mails werden per SMTP zwischen Servern übertragen, wobei der Absender den Zielserver anhand des MX-Record findet und über Port 25/TCP die Mail überträgt. Lange Zeit wurden alle Mails generell unverschlüsselt übertragen, obwohl mit TLS/SSL/STARTTLS schon lange ein Standard existiert, um Mails zumindest auf dem Transportweg zu verschlüsseln. für diese Verschlüsselung sind natürlich Zertifikate erforderlich.

Diese Seite ist noch im Aufbau. DANE erlaubt das Zertifikat des Zielsystems über DNSSEC zu prüfen. Leider ist keine Verifikation des Senders vorgesehen. Ein Spamfilter wird es daher leider nicht.

Exchange Online

Exchange Online unterstützt DANE mittlerweile sowohl eingehend als auch ausgehend.

Zertifikate im Einsatz

Zertifikate sind an sich nichts Schlechtes, erlauben Sie doch eine recht sichere Übertragung von Mails, von der beide Seiten profitieren:

  • Der Absender...
    .. kann sicher sein, dass er auch den richtigen Zielserver erreicht hast. Das ist vergleichbar zum Zugriff auf ihr Homebanking. Sie geben oben einen Namen ein und das Zertifikat muss diesen Namen auch enthalten. Ansonsten sind sie woanders gelandet
  • Der Empfänger...
    ... kann optional über das Zertifikat des Senders den Rechner identifizieren.

Auf dem Papier sieht dieses Prinzips sehr elegant und wasserdicht aus, aber ist es nicht. Mehrere Dinge sind dabei zu bedenken:

  • Keine Selbstzertifikate -> Kosten
    Ein Problem hierbei ist, dass zumindest der Empfänger ein "Vertrauenswürdiges Zertifikat" vorweisen muss. Wird ein Selbstzertifikat zugelassen, dann kann auch ein Angreifer in der Mitte einfach ein Zertifikat vorweisen und die Sicherheit ist nicht gewährleistet.
  • DNS-Spoofing
    Weiterhin könnte ein Angreifer dem Versender einfach einen anderen Server bei einer MX-Anfrage unterjubeln, zu dem der Angreifer ein korrektes Zertifikat hat. Dass die Mail einen "Umweg" nimmt, wird kaum jemand bemerken, wenn das Ziel nicht den Absender prüft. Der Empfänger muss auch den Absender "prüfen" können. Fälschungen bei DNS-Anfragen lassen sich z.B. mit DNSSEC verhindern.
  • CA-Vertrauen
    Natürlich muss auch gewährleistet sein, dass die ausstellende CAs, denen die Partner vertrauen, ihr Vertrauen auch verdienst haben. Es wäre leider nicht das erste Mal, dass eine CA ein Zertifikat fälschlich ausstellt und viele CAs sind in Ländern, bei denen man nicht sicher sein kann, dass Ermittlungsbehörden und Geheimdienste nicht ein Zertifikat für einen interessanten Namen erhalten können.

Insofern ist TLS/SSL/STARTTLS ein Anfang, um die Kommunikation zu verschlüsseln aber erst der halbe Weg, solange die Partner nicht ihre Identität sicher nachweisen.

Absenderverifizierung und IPv6

Gerade beim Thema SPAM werden wir mit der Zunahme von IPv6-Verbindungen immer mehr Probleme mit den klassischen Blocklisten bekommen. Heute besteht das Internet aus maximal  255*255*255*255 Adressen. Das ist heute "überschaubar" und entsprechende Datenbanken und Dienste können ziemlich zuverlässig eine Liste der "unerwünschten Systeme" pflegen, die als Spamversender, Virenschleuder oder sonstiger Schädling zu erkennen sind.

Mit IPv6 wird dies ungleiche schwerer. Klassische Blocklisten werden hier an ihre Grenzen kommen, da Spammer theoretisch für jede Mail eine eigene IP-Adresse verwenden können. Sicher wird es auch hier wieder Möglichkeiten geben, Teilnetze o.ä. zu gruppieren aber so einfach und effektiv wie heute wird eine Filterung auf IP-Level nicht mehr funktionieren. Kann ein Spamfilter aber erst während der eigentlichen Mailübertragung mit der Filterung anfangen. Das ist schon recht spät.

Ein Weg, wie Firmen mithelfen können, ist die Publizierung ihrer ausgehenden Mailserver, z.B. per DNS. SenderID oder SPF. Der Empfängerserver schaut sich bei einer eingehenden Mail den Absender an, fragt per DNS den "ausgehenden Server" ab und wenn die Source-IP übereinstimmt, dann kann er die Mail annehmen. für den "normalen Angreifer" ist es zwar relativ einfach die Source-IP eines Pakets zu fälschen aber um die Rückpakete einzusammeln, muss ein Angreifer schon die Leitwege im Internet verändern. für staatliche Organisationen (Geheimdienste etc.) dürfte es aber entsprechend einfach sein, wenn das Ziel so infiltriert werden kann.

Solange die DNS Abfragen selbst nicht "gesichert" sind, kann natürlich auch die Antwort auf eine RBL-Anfrage durch einen Angreifer gefälscht oder vernichtet werden. Solange RBL u.a. nicht "verpflichtend" sondern nur optional ist, reicht dies aus um die Prüfung beim Empfänger zu übergehen.

Zielverifizierung mit TLS und DNSSEC

Deutlich vorteilhafter wird es, wenn wir erwünschte Transport-Verschlüsselung Signierung mit in die Absenderprüfung einbeziehen. Ein entsprechender Vorschlag ist in der "RFC 6698 DNS-Based Authentication of Named Entities" beschrieben, der in der Einleitung auch darauf eingeht, dass die Zertifikat zwar nett sind, aber jede "vertrauenswürdige" CA kann für jeden Namen einen Key ausstellen. Dies kann verbessert werden, wenn der Domaininhaber z.B. die Information über die verwendeten Zertifikate per DNS veröffentlicht. Damit aber genau diese Information nicht durch Angreifer verändert wird, muss die DNS-Übertragen zumindest signiert sein. Dazu dient DNSSEC, wobei die darüber liegende Zone dann die Information über die Signatur der Subzone bereit stellt.

Über den Weg kann ein Server, der per TLS mit einer Gegenstelle spricht, über DNSSEC die Auskunft erhalten, welche Zertifikat zu erwarten ist. So ist es letztlich nur noch eine Abstimmung des Betreibers des Service und des DNS-Administrators, die richtigen Daten korrekt einzutragen. Genau genommen müsste das Zertifikat dann nicht einmal von einer öffentlichen CA ausgestellt sein, sondern könnte ein Selbstzertifikat sein.

Schade nur, das DNSSEC noch am Anfang steht und ein Exchange Server sein "Selbstzertifikat" nicht gleich automatisch per DynDNS in der DNS-Zone eintragen kann. Dynamische Updates von Zertifikateinträgen im DNS wird es wohl auch aus Sicherheitsgründen nicht geben. Beim Windows DNS kann eine per DNSSEC gesicherte Zone nicht mehr für dynamische Updates genutzt werden.

DANE einrichten

DANE wird aktuell immer auf dem Zielsystem eingerichtet bzw. der Empfängerserver kann per DANE seine Information veröffentlichen und der Sender kann, sollte, muss aber nicht, diese Information nutzen. Folgende Voraussetzungen sind erforderlich.

  • Ziel-Domäne per DNSSEC gesichert
    Nur dann macht es überhaupt Sinn, Informationen zur Verifikation zu hinterlegen.
  • Ziel-Server muss SSL/TLS machen
    Die Datenverbindung muss per SSL/TLS möglich sein. Nur dann wird der Sender vom Ziel ein Zertifikat bekommen und entsprechend etwas zur Überprüfung haben
  • Client/Sender muss DNSSEC auflösen können
    Das Hostsystem muss per DNS natürlich ausgehend von der Root-Zone und den Registrar den Weg bis zum Kundenserver auflösen und verifizieren können, d.h. die DNS-Server und Resolver müssen DNSSEC bereitstellen
  • Client/Sender Applikation muss DANE unterstützen
    Zuletzt muss natürlich die Anwendung selbst noch DANE nutzen wollen.

Dennoch lohnt sich schon der Aufwand, die Information über das verwendete Zertifikat zu veröffentlichen. In der ersten Stufe werden es wohl Browser-Add-ons sein, die den Mehrwert nutzen. Mittelfristig werden Proxy und Relay-Systeme bei Firmen dem Anwender diese Arbeit abnehmen, d.h. ein Mailserver sendet die Mail nicht, wenn das erhaltene Zertifikat nicht mit dem im DNS hinterlegten Zertifikatinformationen übereinstimmt. Irgendwann wird es vielleicht zur Standardausstattung von Betriebssystemen bzw. dem TLS-Modul.

Die Einrichtung erfolgt in mehrere Schritten:

  • DNS-Zone per DECSEC sichern
    Das ist selbst Mitte 2014 noch nicht so einfach einen Provider zu finden, der zum einen seinen Kunden die Sicherung der Zone per DNSSEC erlaubt und dann noch die zusätzlichen neuen Resource Records im DNS erlaubt. Große Provider wie z.B. 1und1 erlauben Mittel 2014 noch nicht mal TXT oder SRV-Records im Kunden-DNS. Wie sollen da dann TLSA-Einträge den Weg finden ?.
  • Zertifikat auf dem Dienst
    Der zu sichernde Mailserver, Webserver oder andere Dienst braucht natürlich ein Zertifikat. Aktuell wird man hier auch weiterhin ein Zertifikat einer offiziellen CA einsetzen. Wenn die Clients aber irgendwann die DNSSEC Information für vertrauenswürdiger halten als die RootCA, dann ist das nicht mehr erforderlich
  • PublicKey oder HashWert
    Im DNS wird ein 32bit Kennzeichen des Zertifikats hinterlegt. Ich hole mir diesen einfach, indem ich per OpenSSL das Zertifikat abholen. Der Text inklusive dem "BEGIN" und "END" Certificate übertrage ich in Notepad uns speichere es als CER-Datei
REM Zertifikat mit OpenSSL abrufen
openssl.exe s_client -connect nawmgw1.netatwork.de:25 -starttls smtp

REM in der Ausgabe steckt dann irgendwo etwas in der Form

-----BEGIN CERTIFICATE-----
MIIEhTCCA22gAwIBAgISESE3X5vkDBKiZtfwOS8F/UF/MA0GCSqGSIb3DQEBBQUA
MC4xETAPBgNVBAoTCEFscGhhU1NMMRkwFwYDVQQDExBBbHBoYVNTTCBDQSAtIEcy
...
H1PbfkSF6hw8cQsTeCBWf/fObwSg3b/GIcGfVWkFlpUtbUW+smP3uALaBJRffhY/
A/D+ntfucqVe
-----END CERTIFICATE-----
  • Fingerprint Zertifikat umrechnen
    Nun muss man aus dem Zertifikat den Fingerprint ermitteln, denn der ist für gewöhnlich im DNS hinterlegt. Es gibt mittlerweile auch Webseiten, in welche sie das Zertifikat eingeben um den DNS-Eintrag zu erhalten. Das "| tr -d :" am Ende ersetz die Doppelpunkte.
C:\Program Files\OpenSSL-Win64\bin\openssl x509 -noout -fingerprint -sha256 -in c:\temp\gate.cer | tr -d :
SHA256 Fingerprint=50CF1FAF1D6E295A54118CD253573285A9269DFE04A1BD03EB41D644B5DC761E
  • DNS Eintrag setzen
    Nun muss man diesen Eintrag im DNS hinterlegen. Gut ist, wenn man den TLSA-Eintrag direkt selbst machen kann. Die drei Nummern vor dem Fingerprint haben auch eine Bedeutung. Kniffliger wird es, wenn der TLSA-Eintrag nicht durch den DNS-Server unterstützt wird. Einige Server (z.B. BIND) erlaube aber eine generische binäre Eingabe. Hier ist die erste Nummer dann die Länge der binären Werte und die weiteren 3 Zahlen müssen immer zweistellig sein.
_25._tcp.msxfaq.de. IN TLSA 3 0 1 50cf1faf1d6e295a54118cd253573285a9269dfe04a1bd03eb41d644b5dc761e

_25._tcp.msxfaq.de. 3600 IN TYPE52 \# 35 03 00 01 50cf1faf1d6e295a54118cd253573285a9269dfe04a1bd03eb41d644b5dc761e

Das Beispiel hier zeigt den MX-Record für eine Domäne. Wenn Sie einen Hosteintrag wie z.B. "www.msxfaq.de" haben, dann lautet der DANE-Eintrag auf "_443.tcp.www  IN TLSA" oder mit voll angegebenem Host _443.tcp.www.msxfaq.de.  IN TLSA". Beachten Sie den kleinen "Punkt" hinter der "de", ansonsten versteht der DNS-Server ein "_443.tcp.www.msxfaq.de.msxfaq.de" daraus.

Die Bedeutung der Nummern ist:

Nummer Wert Bedeutung

1 - usage

0

PKIX-TA: Certificate Authority Constraint

1

PKIX-EE: Service Certificate Constraint
Der Fingerprint wurde anhand des Host Zertifikate errechnet

2

DANE-TA: Trust Anchor Assertion
Der Fingerprint wurde anhand des "Upstream" Zertifikats ermittelt

3

DANE-EE: Domain Issued Certificate
Der Fingerprint wurde anhand des verwendeten Zertifikats ermittelt

2 - Selector

0

Volles Zertifikat wurde genutzt

1

Nur der "Subject Public Key" wurde genutzt

3 - Matching Type

0

Volles Zertifiat, kein Hash

1

SHA-256 Hash

2

SHA-512 Hash

Da "DE-Domains" nicht viel Geld kosten, habe ich die ein oder andere Domain bei verschiedenen Providern, um immer mal wieder deren Verwaltungsoberfläche zu sehen. die frankcarius.de liegt z.B. bei OVH.DE. Im Oktober 2014 konnte ich diese Domäne schon mit DNSSEC aktivieren und die TLSA-Einträge zumindest manuell in der Zonendatei einrichten.

Achtung:
Mittlerweile hat OVH eine neue Verwaltungslösung umgesetzt und dieser alte Zugang wird in 2016 abgeschaltet. Damit ist aktuell keine Pflege von TLSA-Records mehr möglich.

Wichtig war hier die Aktivierung des "Fortgeschrittenen Mode", über den ich die Einträge manuell durchführen konnte. Ich leite den MX-Record auf einen Host in der gleichen Domäne, den ich per A-Record zum Mailserver verweise, auf dem dann das Zertifikat liegt.

Wenn die Mail-Domäne und der Mailserver unterschiedliche Domänen nutzen, dann muss die Domäne des Mailserver mit dem Namen des Mailservers per DNSSEC übereinstimmen.

Das Prinzip ist ja noch einfach, wenn Maildomäne und Mailserver in der gleichen DNS-Domäne sind. Wenn Sie aber z.B. bei einem Provider ihren Mailserver betreiben dann reicht es nicht, dass sie ihre Maildomäne per DNSSEC sichern. Das Zertifikat für dem Mailserver ist ja auf den FQDN des Mailservers ausgestellt und daher muss die Server-Domäne mit DNSSEC gesichert sein und der Mailserver als Host einen TLSA-Eintrag haben auf den dann die Maildomäne per MX-Record verweisen kann.

Trick: Verweisen Sie nicht auf den Namen des Mailservers, sondern auf die IP-Adresse. Die DANE Prüfung kann dann dennoch funktionieren. Allerdings werden die meisten Mailserver vielleicht kein TLS machen, weil das empfangene Zertifikat sicher nicht die IP-Adresse im CN oder SAN hat.

SMIMEA-RR

Übrigens kann man auch SMIME-Zertifikate per DNS publizieren. Auch hierzu muss natürlich ein geeigneter Eintrag im DNS vorgenommen werden, der allerdings auch kein TXT-Record ist. Aktuell (Ende 2014) ist ein eigener Eintrags-Typ hierzu vorgesehen.

DANE Testen

Ob die Implementierung per DANE erfolgreich war, können Sie natürlich per NSLOOKUP und OpenSSL machen aber viel einfacher sind entsprechende Webseiten, die solche Dienste von extern bereits anbieten.

Ich habe neben einigen "msxfaq.*"-Domänen auch die ein oder andere Domäne, die ich für solche Tests bei verschiedenen Providern hin und her ziehen. So habe ich "frankcarius.de" dazu zu OVH umgezogen. So konnte ich diese für DNSSEC aktivieren und einen TSLA-Eintrag anlegen, der auf einen SMTP-Server mit Zertifikat verweist, der interessanterweise noch nicht mal einen Namen "mx.frankcarius.de" enthält.

https://www.tlsa.info/detail/frankcarius.de

Der korrekte Eintrag dieser Werte ist natürlich nur der eine Teil. Erst wenn entsprechende Mailserver diese Information auch auswerten, hat der Eintrag auch eine Funktion. Ein DANE-Eintrag wird aus meiner Sicht interessant, wenn die Browser der Welt langsam diesen Wert überprüfen und so belegen, dass die gerade per SSL angesprochene Webseite auch das Zertifikat nutzt, welche im DNS hinterlegt ist. VeriSign hat entsprechende Testeinträge schon bereit gestellt

Sie brauchen halt nur noch einen Browser, der diese Daten abfragt und entsprechend anzeigt. Bis diese Funktion in den Standard übergeht, müssen interessierte Anwender entsprechende Add-ons installieren

Absenderverifizierung - offen ?

Für den Empfänger ist es aber auch wichtig, den Absender zu können. Auch hier kann dieses Verfahren helfen, da bei STATTLS der Empfänger fordern kann, dass der Sender sich mit einem Clientzertifikat ausweist. In dem Fall kann dann der Empfänger rückwärts den Namen aus diesem Clientzertifikat nutzen, um per DNSSEC die Information gegen zu prüfen. Damit können Absender anhand ihres Zertifikats eindeutig identifiziert und anhand des DNS-Eintrags als autoritativ erkannt werden. Damit wäre dann auch ein wirksamer Hebel gegen Spammer zu finden, zumindest wenn es ihnen nicht gelingt, ihren Versender zugleich auch in einer DNS-Zone mit einer gültigen Signatur zu versehen.

Leider habe ich in den RFCs aber diesbezüglich noch nichts gelesen, wie ein Absender ein Clientzertifikat im DNS hinterlegen kann. Interessant wäre die Definition eines solchen Eintrags z.B. bei der Reverse Lockup-Zone an die IP-Adressen. Allerdings muss der Betreiber des sendenden Mailservers natürlich mit dem DNS-Administrator zusammen arbeiten, um den Eintrag zu addieren. Server hinter dynamischen Adressen wird es so nicht geben können.

Ein anderer Weg wäre, dass der Empfänge einfach den Namen im Zertifikat des Absenders heranzieht und über den Hostname per DNSSEC überprüft, ob das im DNS-Eintrag angegebene Zertifikat übereinstimmt. Das scheitert aber aus meiner Sicht aktuell daran, dass der DNS-Eintrag mit dem Zertifikat nicht nur den Host, sondern auch das Protokoll und den Port enthält. Ausgehende Verbindungen nutzen aber in der Regel dynamische Port. Hier würde es dann nur helfen, mit einem "Wildcard"-Eintrag dies zu definieren

*._tcp.www.example.com.    IN TLSA 1 1 1 aabbccddee...

Sicherheit schwächen ?

Wenn der Server, welcher die Verbindung initiiert, das Zertifikat erhalten hat und per DNSSEC prüfen will, muss eine DNS-Abfrage an einen DNSSEC-Server senden. Wenn es für den angefragten Namen kein TLSA-Eintrag gibt, dann kann der Server der Zertifikat nicht verifizieren und wird auf andere Prüfverfahren schwenken. Ein Angreifer könnte z.B. diese Anfrage einfach unterdrücken. Dazu müsste dieser diese Anfrage aber erst einmal "sehen" können.

Per Default werden DNSSEC-Anfragen nur über "gesicherte Verbindungen" übertragen. Die RFC schreibt dazu:

The application can communicate through a secured channel (such as requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local DNS resolver that does DNSSEC validation
Quelle: https://tools.ietf.org/html/rfc6698

Damit sollte es natürlich sehr schwer werden, hier auf dem Abfragepfad verändernd einzugreifen. Denkbar ist natürlich den DNS-Server zu stören oder jede IPSEC/TLS-Verbindung zu verhindern, so dass der Anfragende Prozess keine DANE-Abfragen per DNSSEC machen kann.

Es wird nach meiner Einschätzung noch sehr lange so sein, dass ein Client dann letztlich die Mail doch unterschlüsselt sendet. Es würde nicht mal reichen, wenn der Empfänger diese Option abschaltet, denn ein Angreifer macht sich die Mühe sowieso nur, wenn er einen eigenen Mailserver dazwischen stellen kann.

Um eine Verschlüsselung zu erzwingen ist also der Absender gefordert, ein Fallback auf "unverschlüsselt" zu unterlassen.

Leider habe ich noch keine Beschreibungen gefunden, wie ein Spamfilter auch den Absender verifizieren kann.

Weitere Links