DANE Unchained

DANE soll die Sicherheit des Absenders erhöhen, den richtigen Empfänger zu erreichen. MITM-Attacken auf gefälschte Zertifikate oder gar gefakte Empfänger-Mailserver sollen ausgeschlossen werden.

Übersicht

Postfix selbst stellt einen DNS-Resolver (stub resolver), der dnssec-aware ist - aber selbst nicht validiert. Die dnssec-awareness muss zudem aktiv eingeschaltet werden.
Bei der Signaturprüfung verlässt sich postfix auf einen validierenden DNS-Resolver. Die Entscheidung, ob MX- und TLSA-Daten (für DANE) akzeptiert werden, basiert auf dem AD-Flag in DNS-Antworten. Dieses wird vom Resolver gesetzt, wenn eine Antwort erfolgreich DNSSEC-validiert wurde.

Angriffsszenario

Selbst wenn ein Angreifer in der Lage wäre, dem MTA (z. B. Postfix) eine gefälschte MX-Antwort unterzuschieben (mit gesetztem AD-Flag), würde der anschließende Versuch, passende TLSA-Daten (für DANE) zu liefern, ohne gültige DNSSEC-Signaturen scheitern. Die Kette aus Zone-Signierung und TLSA-Datensatzprüfung kann nicht so einfach durchbrochen werden.

Der Ablauf

Der folgende Ablauf beschreibt, wie Postfix im DANE-Modus arbeitet, wenn es eine Mail zustellen will:

  1. MX-Lookup für Empfängerdomain
    Postfix fragt den Resolver: "Was ist der MX für example.com?"
    Wird beantwortet mit einem MX-Record. Diese Antwort enthält idealerweise das AD-Flag (authenticated data), das anzeigt: „Dieser Eintrag ist DNSSEC-validiert“. 
    smtp_dns_support_level = dnssec
  2. Ermittlung des TLSA-Records
    Postfix fragt dann: „Welche TLSA-Einträge gibt es für mail.example.com:25?“
    Diese Antwort muss ebenfalls das AD-Flag tragen, sonst wird sie von Postfix ignoriert. 
    smtpd_tls_security_level = dane
  3. Überprüfung der TLS-Verbindung
    Wenn die TLSA-Antwort als DNSSEC-validiert angesehen wird, vertraut Postfix dem enthaltenen Zertifikat (bzw. dem Hash) und verlangt, dass genau dieses Zertifikat beim TLS-Handschlag präsentiert wird.
  4. Wenn kein AD-Flag vorhanden ist
    → Postfix verwirft den TLSA-Datensatz. Es wird keine DANE-basierte TLS-Verbindung aufgebaut. Bei dem setting dane-only ist hier die Verbindung zu Ende; ansonsten wird das fallback-Szenario getriggert. (etwa mta-sts oder sogar Klartext)

Konfigurationstipp

Damit das wirklich sicher funktioniert, empfehlen DANE-Experten und die Postfix-Dokumentation: 

# Verwende einen lokalen validierenden Resolver (z. B. Unbound)
# und stelle sicher, dass Postfix nur diesen nutzt
/etc/resolv.conf:
  nameserver 127.0.0.1
Wichtig: Postfix prüft nicht selbst DNSSEC-Signaturen. Es vertraut ausschließlich auf das AD-Flag des Resolvers.

Somit bietet DANE selbst bereits den Schutz, den DANE-STS erreichen wollte – allerdings auf technischer Ebene und ohne zusätzlichen Policy-Layer.

Fazit

Einschalten von "dane" in den tls_policy settings in postfix ist nicht ausreichend; die dnssec-awareness von postfix muss ebenfalls aktiv enabled werden. lokal validierende Resolver nutzen und sich auf das DANE-Modell verlassen. (wobei "lokal" sicherlich dynamisch betrachtet werden kann; ein DNS-Server im gleichen VMWare-Cluster kann vermutlich als ausreichend lokal angesehen werden.