Nachdem im vergangenen Monat der Providerverbund „e-mail made in Germany“ bekannt gegeben hat, dass nunmehr alle Nutzeraccounts sukzessive bis zum Ende April auf eine SSL/TLS-Transportverschlüsselung umgestellt werden, hat am letzten Montag der Konkurrent Posteo Informationen zu der von ihm eingesetzten Transportverschlüsselung gegeben:
„Posteo hat seine Transportverschlüsselung auf DANE/TLSA umgestellt.“
Posteo hat damit im Wettbewerb um die Kundengunst wieder einmal die Nase vorne.
Der Inhalt im Überblick
Was ist DANE?
DANE steht für “DNS-based Authentication of Named Entities”. Hierbei handelt es sich um einen offenen Standard zur Transportverschlüsselung welches auf dem Internetstandard DNSSEC (Domain Name System Security Extensions) aufsetzt. DNSSEC wurde als Mittel gegen das sog. DNS-Cache-Poisoning entwickelt, und soll in dem durch DANE entwickelten Verfahren die Authentizität der für die Transportverschlüsselung verwendeten Schlüssel gewährleisten.
Beim DANE-Verschlüsselungsverfahren handelt es sich, ebenso wie beim bekannteren TLS/SSL-Verfahren um eine reine Transportverschlüsselung, bei der die zu versendende E-Mail auch weiterhin unverschlüsselt auf den Servern der E-Mail-Provider abgelegt werden. Anders als beim reinen TLS setzt DANE quasi auf eine eigene Public Key Infrastructure, die durch die non-profit Organization ICANN (Internet Corporation for Assigned Names and Numbers), welche auch für die Vergabe von Top-Level-Domains und IP-Adressen verantwortlich ist, verwaltet wird.
So wird sichergestellt, dass nur vertrauenswürdige Zertifizierungsstellen berechtigt sind, überhaupt Zertifikate zu erstellen.
Mit DANE werden die Verschlüsselungszertifikate sowie das TLSA-Record direkt im DNS auf den sog. DNS-Servern hinterlegt und können so vor Aufbau der verschlüsselten Verbindung vom DNS der Empfängerdomain authentifiziert werden. Eine gute und tiefergehende Auseinandersetzung mit der dahinter stehenden Technik und den Vorteilen von DANE hat Heise in der aktuellen c‘t (Heft 11, Seite 195) veröffentlicht.
Was ist der Vorteil zum herkömmlichen TLS?
Anders als beim DANE/TLSA-Verfahren arbeitet TLS nach Rechercheergebnissen von Heise mit sog. PKIX-Zertifikaten (Public Key Infrastructure X.509, RFC 5280) (vgl.: c’t Heft 11, Seite 195).
Diese Zertifikate werden, so Heise in der aktuellen c`t:
„von derzeit über 200 verschiedenen Zertifikatsstellen weltweit ausgegeben. Jede dieser Zertifikatsstellen kann Zertifikate für jeden beliebigen Hostnamen ausstellen.“
Fehlende Authentifizierung
Auch beim herkömmlichen TLS-Verfahren können die Zertifikate, mit denen eine Verschlüsselung erreicht wird, normalerweise von einer Gegenstelle authentifiziert werden. Eine genaue Überprüfung und damit Authentifizierung jedes Kommunikationspartners erfolgt hier zumeist jedoch aufgrund der Masse der Zertifikatsstellen nicht. Steht beim Verbindungsaufbau TLS zur Verfügung, wird die Verschlüsselung ohne weitere Prüfung auf Authentizität der Zertifikatsstelle aufgebaut. Steht TLS nicht zur Verfügung, wird (vorbehaltlich anderslauternder Einstellungen durch den Admin) unverschlüsselt übersandt.
Anfälligkeit für Man-in-the-middle-Attacken
Ein weiteres Manko ist die Anfälligkeit des TLS-Verfahrens für sog. Man-in-the-Middle-Attacken. Ob ein verschlüsselter Verbindungsaufbau möglich ist, wird durch das Senden des sog. STARTTLS-Befehls überprüft. Dies erfolgt in Klartext. Schaltet sich nun ein Angreifer, wie beim typischen Man-in-the-Middle-Attack zwischen die Server, braucht er lediglich den STARTTLS-Befehl abgreifen und kann damit einen unverschlüsselten Mailtransport erzwingen. Erleichtert wird dem Angreifer das Abfangen, da TLS standardmäßig die Ports 80 für http und 443 für https verwendet. Dies verhindert DANE nach Angaben von Posteo, indem das direkt auf dem Domainserver hinterlegte TLSA-Records das senden des STARTTLS-Befehls zwingend erwartet.
DNS-Cache-Poisoning
Schließlich birgt der Einsatz von TLS das Risiko des sog. DNS-Cache-Poisonings, also das Einschleusen von fehlerhaften DNS-Informationen, die die Zuordnung im DNS verändern und so die gesendeten Informationen umleiten können. Dies wird bei DANE dadurch verhindert, dass die Abfrage beim der Empfängerdomain mit DNSSEC gesichert wird und so über den Abgleich mit dem TLSA-Record ein Authentifizierung erreicht wird.
Welche Probleme gibt es bei der Umsetzung?
Auch wenn DANE/TLSA einige Risiken der TLS-Verschlüsselung reduzieren kann, ist eine Umsetzung in großem Umfang derzeit jedoch noch nicht möglich. Um DANE einsetzen zu können, müssen alle Mailserver vom Sender bis hin zum Empfänger TLSA-Records gespeichert haben, also DANE unterstützen. Derzeit ist diese Technologie jedoch nicht als Standard verabschiedet und daher auch noch nicht weit verbreitet.
Fazit
DANE/TLSA als Mittel zur Transportverschlüsselung bietet erhebliche Vorteile zum herkömmlichen TLS-Verfahren. Selbstverständlich darf bei aller Euphorie jedoch nicht vergessen werden, dass es sich hierbei ebenfalls nur um eine Transportverschlüsselung handelt. Weiterhin ist die Frage offen, wie ein Abgriff von E-Mails auf den Mailservern oder direkt bei den Providern verhindert werden kann.
Hierzu eine kleine Randnotiz:
Posteo hat angekündigt, zukünftig die E-Mail-Inhalte seiner Kunden kostenfrei mit AES auf den Servern verschlüsseln zu wollen.
Posteo ist eine der wenigen Firmen, wo Datenschutz nicht lästiges Übel, sondern Berufung und Überzeugung ist. Gäbe es Posteo nicht, müsste man es glatt erfinden.