DANE (DNS-Based Authentication of Named Entities, RFC 6698) verankert die Authentifizierung von TLS-Verbindungen im Domain Name System. Über spezielle DNS-Einträge (TLSA) wird festgelegt, welches Zertifikat ein Dienst verwenden darf. Da die Einträge mit DNSSEC signiert sind, kann ein Angreifer sie nicht fälschen — die Kette aus Zertifikaten, wie sie klassische Zertifizierungsstellen aufbauen, wird ergänzt oder ersetzt.
TLSA-Einträge
Ein TLSA-Record besteht aus vier Feldern: Usage (0 = PKIX-TA, 1 = PKIX-EE, 2 = DANE-TA, 3 = DANE-EE), Selector (0 = komplettes Zertifikat, 1 = öffentlicher Schlüssel SPKI), Matching Type (0 = volle Daten, 1 = SHA-256, 2 = SHA-512) und den eigentlichen Zertifikatsdaten. Für SMTP erlaubt RFC 7672 nur die Werte 2 und 3. Die empfohlene Konfiguration ist 3 1 1: DANE-EE mit gehashtem öffentlichen Schlüssel (SHA-256).
Schutz vor STARTTLS-Stripping
Beim E-Mail-Versand sichert SMTP mit STARTTLS die Verbindung erst nach dem Verbindungsaufbau. Ein Angreifer kann das STARTTLS-Angebot entfernen und die Übertragung auf Klartext zurückstufen. DANE verhindert das: Hat der MX-Host der Empfängerdomain einen gültigen TLSA-Eintrag, akzeptiert der sendende Server nur noch TLS-Verbindungen mit dem passenden Zertifikat. Eine Verbindung ohne TLS oder mit fremdem Zertifikat wird abgebrochen.
Abhängigkeit von DNSSEC
DANE ist nur so stark wie DNSSEC: Ohne validierte Signaturkette ist ein TLSA-Eintrag nur ein Datensatz, den ein Angreifer umschreiben kann. DANE lässt sich aber mit klassischen Zertifikaten kombinieren (Usage 0/1) oder als reine DANE-Pinning-Lösung betreiben (Usage 2/3). Neben E-Mail wird DANE auch für andere Dienste genutzt, etwa XMPP und HTTPS.
Verwandte Grundlagen: SSL/TLS, TLS-Handshake, TLS 1.3, PKI, Zertifikat, SPF, DKIM, DMARC, WKD, Schlüsselwiderruf.