Geleitschutz: DANE verbessert sicheren Transport zwischen Mailservern
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.
- Patrick Ben Koetter
- Carsten Strotmann
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, 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).
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.
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.
