Geleitschutz: DANE verbessert sicheren Transport zwischen Mailservern

| 24.06.2015 16:24 Uhr Patrick Ben Koetter, Carsten Strotmann

Verschlüsselter Nachrichtentransport ist schon mal besser, als Mails wie eine Postkarte für alle lesbar zu übertragen. Doch auch mit dem jüngst bei Freenet, GMX, T-Online und Web.de aktivierten TLS zwischen Absender, Mailservern und Empfänger bleiben Lücken. DANE kann diese schließen.

Geleitschutz: DANE verbessert sicheren Transport zwischen Mailservern

Transport Layer Security (TLS) ist das Standardverfahren zum Verschlüsseln des Datentransports im Internet, nicht nur für vertrauliche Webseiten wie von Online-Banken, sondern auch für Mails, Downloads oder Updates des in der Cloud gelagerten Familienkalenders. Leider hat TLS Schwächen, weil die Authentizität der verwendeten Zertifikate nicht immer gewährleistet ist.

Hier soll DANE (DNS-based Authentication of Named Entities) in die Bresche springen. Es setzt auf DNSSEC auf [1], das im Prinzip eine eigene PKI (Public Key Infrastructure) ist, deren Hauptschlüssel (Root DNSSEC Key) die Non-Profit-Organisation ICANN verwaltet (Internet Corporation for Assigned Names and Numbers).

Man-in-the-Middle: Ein Angreifer in der Mitte fängt das STARTTLS-Angebot des SMTP-Ziels ab und bietet dem Absender nur offene Übertragung an. Die Mail läuft anschließend ungeschützt über die Leitung.

Dank der Trusted Community Representatives, die die ICANN in Sachen DNSSEC beaufsichtigen, kann man den Hauptschlüssel und damit die DNSSEC-PKI als vertrauenswürdig ansehen. Das erlaubt, Zusatzinformationen in die DNS-Zone-Files zu packen, die der DNS-Server als zusätzliche Records ausliefert. So eignet sich DNSSEC auch gut zum Absichern anderer Protokolle. Doch der Reihe nach.

Das früher als SSL (Secure Sockets Layer) geläufige TLS macht den Mailtransport tatsächlich sicherer. Aber garantiert frei vom Zugriff durch externe Lauscher ist der Weg damit noch längst nicht. Denn es gibt eine Reihe von Schwachstellen, über die Verschlüsselung verhindert oder die Mail sicher in falsche Hände gelangen kann: Zertifikatsaussteller, Zertifikatprüfung, Man-in-the-Middle-Angriffe (MITM) und DNS-Cache-Poisoning (Einschleusen falscher Informationen in den Zwischenspeicher des Domain Name System).

Vertrauen ist gut …

Die erste Schwachstelle liegt bei den Zertifikatsausstellern. TLS arbeitet mit PKIX-Zertifikaten (Public Key Infrastructure X.509, RFC 5280). Diese Zertifikate werden von derzeit über 200 verschiedenen Zertifikatsstellen (Certification Authority, CA) weltweit ausgegeben. Jede dieser CAs kann Zertifikate für jeden beliebigen Hostnamen ausstellen; auch können verschiedene CAs Zertifikate für denselben Host ausgeben.
Wenn eine dieser CAs nachlässig bei der Systemsicherheit oder bei der Prüfung des Antragstellers ist, kann ein Angreifer ein gültiges Zertifikat für einen Host erstellen, dessen Besucher er ausnutzen möchte. Das ist schon mehrfach vorgekommen.

Umleitungsangriff: Durch Fluten des DNS-Cache mit falschen Antworten (DNS-Cache-Poisoning) können Angreifer den Mailverkehr auf sich umleiten. Der Sender hält wegen der falschen DNS-Antwort aus dem Cache den Server des Angreifers für das eigentliche Ziel.

Der zweite wunde Punkt ist die Prüfung der Zertifikate im Mailserver. Der richtige Weg wäre, die Zertifikate aller Server einzeln zu checken, die Verschlüsselung anbieten. Damit wären die Kommunikationspartner eindeutig festgestellt („Identifiziertes TLS“).

Alltag ist aber, dass Server in der Regel völlig autonom und unbeobachtet arbeiten. Sie nutzen TLS, wenn es möglich ist und machen sich nicht die Mühe der Identitätsprüfung („Opportunistisches TLS“). Hauptsache, die Nachricht wird verschlüsselt übertragen.

… Kontrolle ist besser

Wer konsequent sicherheitsgerichtet denkt, weist seinen Server an, die Kommunikation bei Unregelmäßigkeiten wie einem abgelaufenen Gültigkeitszeitraum, einem nicht zum Namen im Zertifikat passenden Hostnamen des Zielservers oder einer unterbrochenen Vertrauenskette zum CA-Root-Zertifikat abzubrechen.

Meist werden die Server aber so konfiguriert, dass sie derlei nach dem Motto „Wird schon gut gehen“ ignorieren und dennoch eine verschlüsselte Verbindung aufbauen. Nun kann der Sender aber nicht mehr sicherstellen, dass er wirklich mit dem richtigen Ziel spricht (Authentizität).

„E-Mail made in Germany“ könnte sicherer sein: Bei Redaktionsschluss dieses Artikels war von DANE-geschütztem TLS-Mailtransport bei den vier Providern noch nichts zu entdecken.

Zwar könnte ein Admin die öffentlichen Schlüssel von Gegenstellen manuell in die Konfiguration seines Servers eintragen. Aber dieses Vorgehen skaliert nicht: Selbst kleinere Firmen müssen mit Dutzenden bis Hunderten externer Server kommunizieren. Manuell eine dedizierte Vertrauensbeziehung zwischen Allen zu konfigurieren ist offensichtlich illusorisch.

Diese beiden Schwachstellen eliminiert DANE: Statt mehrerer CA-Stellen gibt es nur einen Ort, der ein gültiges Zertifikat benennen kann, nämlich das DNS der Empfängerdomain. Über die dort veröffentlichte Prüfsumme des Server-Zertifikats kann der sendende Server das Ziel zweifelsfrei identifizieren.

Sicherheitsunterdrückung

Die dritte TLS-Schwachstelle offenbart sich bei Man-in-the-Middle-Angriffen: Jeder Verbindungsaufbau startet unverschlüsselt. Über den unsicheren Kanal vereinbaren die Kommunikationspartner per STARTTLS-Befehl das Chiffrieren. Unterstützt einer der beiden Server kein TLS, so müssen die E-Mails zwischen ihnen unverschlüsselt fließen.

DANE schützt Mailtransport: Bei DANE prüft ein Mailserver zunächst über eine mit DNSSEC gesicherte DNS-Abfrage, ob sein Gegenüber TLS unterstützt. Mit der Antwort bekommt er auch gleich den öffentlichen Schlüssel für eine sichere Verbindung. Damit sind MITM- und Umleitungsangriffe ausgeschlossen.

Schaltet sich ein Angreifer zwischen die Server, kann er schlicht den STARTTLS-Befehl herausfiltern und damit offenen Mailtransport erzwingen. Den Angriff, also das Filtern, erleichtert, dass Standarddienste immer dieselben Ports benutzen: 80 für HTTP, 443 für HTTPS, 143 für IMAP (Internet Message Access Protocol, Mailabfrage), 993 für IMAPS (verschlüsseltes IMAP).

Für verschlüsselte Mailweiterleitung per SMTP (Simple Mail Transport Protocol) ist dagegen kein separater Port festgelegt, SMTP und SMTP über TLS laufen in der Praxis beide über Port 25. Für verschlüsseltes SMTP war ursprünglich Port 465 vorgesehen. Doch das wurde nie zum Standard und wird daher selten benutzt.

Server mit Siegel

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.

Selbstsignierte Zertifikate ausdrücklich erlaubt

Verderbliche Ware

DANE ist nicht PGP

Um ein Missverständnis auszuschließen: Auch mit DANE lagern Ihre E-Mails unverschlüsselt auf den Servern der Provider. Und auf die Provider-Server haben nicht nur deren Administratoren, sondern mittelbar auch Ermittlungsbehörden Zugriff. Den gibt es zwar nur mit einem Gerichtsbeschluss, aber der darf bei Gefahr im Verzug auch innerhalb von drei Werktagen nachgeholt werden. Im Zweifel müssen die Admins Ihre Nachrichten also erstmal rausrücken.

Wenn Sie also sichergehen wollen, dass Ihre Mail unverfälscht und vor fremden Augen geschützt beim richtigen Empfänger ankommt, müssen Sie sie nach wie vor schon auf Ihrem PC mit PGP oder S/MIME verschlüsseln. Wie man die Techniken einsetzt, erklären beipielsweise die beiden Artikel "Privatsache E-Mail" (kostenpflichtiger Download [2]) und "Autonomes Verschlüsseln" (kostenpflichtiger Download [3]). Ist der PC frei von Trojanern oder anderer Malware, dann geht ein nach heutigem Wissen nicht knackbares Chiffrat auf den zusätzlich mit TLS gesicherten Weg.

Dieser verifizierte Transport per TLS funktioniert freilich nur, wenn für alle Mailserver auf dem Weg vom Absender bis zum Empfänger TLSA-Records existieren. Ähnlich wie bei der Kühlkette vom Hersteller bis in den Supermarkt kann die Ware unbemerkt verderben, wenn auch nur eine Zwischenstelle patzt. Denn dann müssen die Kommunikationspartner auf ungeprüftes TLS zurückfallen oder gar unverschlüsselt kommunizieren.

Das Mailserver-Programm Postfix eignet sich für DANE bereits seit Anfang 2014 (ab der Version 2.11). Es gilt als Referenzimplementierung.

Validieren in Postfix

Damit beim Ausliefern einer Mail seine Gegenstelle per DANE und DNSSEC selbsttätig authentisiert, genügen zwei einfache Änderungen in der Haupt-Konfigurationsdatei main.cf:

smtp_dns_support_level = dnssecsmtp_tls_security_level = dane

smtp_tls_loglevel = 1

Auch beim Mailserver Exim ist die Implementierung mittlerweile weit fortgeschritten. Als weitere Zutaten brauchen Admins eine DNS-Domain mit DNSSEC-signierter Zone und einen passenden TLSA-Record für den Mailserver, einen lokalen, DNSSEC-fähigen DNS-Resolver und TLS-Zertifikate für die Server.

DNSSEC ist zwar schon seit Langem verfügbar, hat aber bisher in Deutschland keine weite Verbreitung gefunden. Das könnte sich mit DANE als Killerapplikation ändern. Dann können die vier Provider der E-Mail-made-in-Germany-Gruppe nicht nur untereinander, sondern auch mit dem Rest der Welt sicher und identifiziert kommunizieren. (dz [4])

URL dieses Artikels:
https://www.heise.de/-2626378

Links in diesem Artikel:
[1] https://www.heise.de/ratgeber/Domain-Name-System-absichern-mit-DNSsec-903318.html
[2] http://www.heise.de/artikel-archiv/ct/2013/22/136_Privatsache-E-Mail
[3] http://www.heise.de/artikel-archiv/ct/2012/22/160_Autonomes-Verschluesseln
[4] mailto:dz@ct.de