Seite 3: Server mit Siegel

Inhaltsverzeichnis

Auch der DNS-Eintrag fürs Mail-Routing (MX-Record) besagt nur, dass ein Server zum Mailaustausch bereitsteht, nicht aber, ob er die Nachrichten im Klartext oder verschlüsselt entgegennehmen möchte.
Der Sender muss deshalb davon ausgehen, dass das Ziel auch unverschlüsselten Transport akzeptiert. Das kann ein Angreifer durch eine Man-in-the-Middle-Attacke ausnutzen. DANE behebt dieses Problem, denn die Tatsache, dass für das Ziel ein TLSA-Eintrag im DNS existiert, soll als Absichtserklärung gewertet werden, dass der empfangende Server STARTTLS erwartet.

Server mit Siegel

Der Hauptzweck der DANE-Technik ist damit das automatische Verteilen und Prüfen von TLS-Zertifikaten über das Domain Name System, und zwar nicht nur für Mail, sondern prinzipiell auch alle anderen Dienste, die auf Verschlüsselung setzen. DANE wird beispielsweise schon für SSH eingesetzt. Weitere Protokolle sind für PGP, S/MIME und IPSec in Arbeit. Zwar ist DANE für HTTPS schon seit 2012 standardisiert, wird aber noch von keinem Browser umgesetzt. Bei den gängigen Browsern kann man DANE mit einem Add-on nachrüsten.

Damit sein Zertifikat prüfbar wird, trägt ein Server-Betreiber einen Fingerabdruck (Hash) davon – genauer, vom zugehörigen Public Key – selbst in seine DNS-Zone ein. Der Sender einer Verbindungsanfrage bekommt dann bei der mit DNSSEC gesicherten DNS-Abfrage den zugehörigen TLSA-Record frei Haus. Zum Prüfen des Zertifikats berechnet der Sender aus dem vom Empfänger beim TLS-Verbindungsaufbau vorgelegten Public Key den Hash. Stimmt der mit dem aus der DNS-Abfrage überein, ist die Vertrauensstellung geschaffen.

So löst DANE nebenbei das Problem der automatisierten Schlüsselverteilung und klärt auch die Frage, wer für welchen Server Zertifikate ausstellen darf: nur der Betreiber selbst und nicht etwa mehrere öffentliche CAs.

Damit ist der Betreiber nicht mehr auf eine externe Zertifizierungsstelle angewiesen. DANE erlaubt ausdrücklich selbstsignierte Zertifikate, auch wenn das Protokoll nicht mit dem Ziel geschaffen wurde, öffentliche CAs überflüssig zu machen. Denn es muss für DNSSEC mindestens einen externen Trust Anchor geben, damit sich nachvollziehen lässt, dass die DNS-Antworten unverfälscht sind. Der gesamte Ablauf beim Mailtransport sieht damit so aus:

– Das E-Mail-Programm liefert eine Mail an benutzer@example.de beim lokalen Mailserver an.

– Der erfragt per DNS die Mailserver der Empfängerdomäne (MX-Records) und löst die Hostnamen aus den MX-Records in IPv4- und/oder IPv6-Adressen auf.

– Der lokale Server wählt einen der entfernten Server aus und erfragt per DNSSEC dessen TLSA-Record.

– Nun fragt der Sender beim Ziel eine TLS-Verbindung an.

– Lehnt das Ziel TLS ab, bricht der Sender je nach vorgegebener Policy den Übermittlungsversuch ab oder fällt auf unverschlüsselten Transport zurück, was aber niemand will.

– Der Sender prüft das vorgelegte TLS-Zertifikat gegen den Hash aus dem TLSA-Record.

– Stimmt alles, liefert der Sender die Mail aus, sonst bricht er die Übertragung ab.