© Liftarn, CC BY 2.0 (Wikimedia)

Wer glaubt, STARTTLS im Mailclient zu aktivieren, mache seinen Mailverkehr in jedem Fall sicherer, der irrt. Erst wer auf DANE setzt, kann sicher sein, dass ein Mailserver oder eine Firewall auf dem Transportweg nicht jede Verschlüsselung ausknipst.

Kommunikation braucht Privatsphäre. Sie bildet die Grundlage für vertraulichen und verbindlichen Austausch. Eine normale E-Mail bietet keine Privatsphäre, denn sie passiert das Netz im Klartext. Wer den Netzwerkverkehr mitliest, hat vollen Zugriff auf den Inhalt der Nachricht. Wer Privatsphäre will, muss also verschlüsseln, das schützt private Informationen und Firmengeheimnisse. PGP und S/MIME beziehungsweise SSL und STARTTLS sind geeignete Methoden zur Verschlüsselung von E-Mail. Die ersten beiden verschlüsseln die Nachricht, die anderen den Transport.

Nicht immer sicherer Transport

Transportverschlüsselung (Transport Layer Security, TLS) ist attraktiv. Sie ermöglicht ein brauchbares Schutzniveau und ist für Anwender transparent. Das ist gut, denn es spart Supportkosten, die Anwender können sich auf ihr eigentliches Ziel, die Inhalte der Kommunikation, konzentrieren.

Viele Admins glauben, es genüge, die für Verschlüsselung erforderlichen Zertifikate zu erzeugen und STARTTLS im SMTP-Server und -Client (Abbildung 1) zu aktivieren, dann sei der Transport fortan sicher. Sie irren. Transportverschlüsselung hat einige prinzipbedingte Schwachstellen, die dieser Artikel bespricht und begründet.

Abbildung 1: Es reicht nicht, im Mailclient SSL/TLS zu aktivieren, weil standardmäßig alle Beteiligten verschlüsselungsfreie Kommunikation als Fallback nutzen – und der lässt sich provozieren.

Session Downgrade

STARTTLS ist eine Protokollerweiterung des ursprünglichen SMTP. Zwei Voraussetzungen müssen gegeben sei, um eine TLS-geschützte Verbindung aufzubauen. Der Server muss ESMTP (Extended SMTP) sowohl beherrschen als auch anbieten und die Erweiterung STARTTLS muss im Server aktiviert sein.

Ob diese Voraussetzungen gegeben sind, erkennt ein Client erst nach dem Verbindungsaufbau, wenn der Server zur Begrüßung des Clients sein “SMTP Banner” sendet. Im Banner etabliert der Server seinen aktuellen Status durch einen Statuscode, oft gefolgt von seinem Namen und – wichtig – dem String »ESMTP« (Listing 1).

01 $ telnet mail.sys4.de 25
02 220-mail.sys4.de ESMTP Postfix
03 EHLO client.example.com
04 250-mail.sys4.de
05 250-PIPELINING
06 250-SIZE 40960000
07 250-ETRN
08 250-STARTTLS
09 250-ENHANCEDSTATUSCODES
10 250-8BITMIME
11 250 DSN

Sendet der Server kein »ESMTP« im Banner, dann beherrscht er (oder gibt es zumindest vor) kein ESMTP und die Kommunikation kann nur ohne Transportverschlüsselung stattfinden. Fehlt der String oder sendet der Server »SMTP« , dann muss der Client davon ausgehen, dass der Server keine SMTP-Erweiterungen beherrscht.

Die SMTP-Clients in gängigen Mailservern sind grundsätzlich bedingungslos auf Transport eingestellt. Sie führen “Opportunistische TLS” durch. Bietet der Server STARTTLS an, versuchen sie verschlüsselten Transport herbeizuführen. Fehlt ESMTP im Banner des Servers, schalten sie auf herkömmliches SMTP zurück. Sie verzichten auf Transportverschlüsselung, weil es keine Gelegenheit (lat.: opportunitas) dazu gibt.

Anbieter von Sicherheitslösungen machen sich dieses Verhalten ebenso zunutze wie auch einige Accessprovider. Sie filtern SMTP-Verbindungen in der Firewall (bei Cisco schick SMTP Fixup genannt), im Desktop-SMTP-Proxy (McAfee) oder auf WAN-Strecken [1] und entfernen das »ESMTP« im Banner.

Gezielt unsicher

Durch dieses bewusst herbeigeführte Session Downgrade erhalten sie Zugriff auf die Sessiondaten und den Inhalt der Nachricht. Eine Nachricht, so ihr Argument, kann nur unverschlüsselt auf schädlichen Inhalt (Malware, Spam) geprüft werden. Dabei ist dieses Argument gar nicht haltbar: Nachrichten lassen sich auch verschlüsselt zum Server transportieren und anschließend unverschlüsselt im Server auf unerwünschte Inhalte prüfen. Genau das findet heute millionenfach tägliche Anwendung.

Verwschwörungstheoretiker mögen vor dem Hintergrund der NSA-Affäre über mögliche Gründe spekulieren, Tatsache ist: Transportverschlüsselung bietet einen Angriffsvektor, der beispielsweise bei der STRIPTLS-Attacke [2] zur Anwendung kam. Derlei Angriffe sind möglich, weil herkömmliche TLS keine Policy-Komponente bietet. Der Server verfügt nicht über einen fälschungssicheren Kanal, über den er dem Client signalisieren kann, dass er STARTTLS beherrscht. Abhilfe bieten hier nur eine eigene TLS-Policy und die Aktivierung einer weiteren SMTP-Erweiterung.

Manuell und automatisch

Eine TLS-Policy definiert Voraussetzungen für eine SMTP-Session mit einem SMTP-Server. Die grundlegende Anforderung, der Transport muss TLS-verschlüsselt stattfinden oder unterbleiben, verhindert effektiv ein Session Downgrade. Sind die Transportbedingungen nicht gegeben, verbleibt die E-Mail in der Queue des sendebereiten Servers, bis sie nach Ablauf der Wartezeit bounct.

Sender-seitige TLS-Policies kommen nur selten zum Einsatz. Die Vielzahl der Kommunikationspartner macht eine lückenlos gesicherte Verschlüsselung zu aufwändig. Eine lokale Policy, die zusätzlich zu der Anforderung “Muss TLS anbieten” auch noch Bedingungen wie “Muss sich mit einem bestimmten Fingerprint im Zertifikat auszeichnen” definiert, steht auf wackligen Beinen. Sobald die entfernte Gegenstelle eine Bedingung ändert, greifen die lokalen Anforderungen ins Leere und der Transport kommt zum Stillstand.

Die Protokollerweiterung DANE SMTP befreit den Admin aus der Zwangslage. Aktiviert er DANE SMTP, dann prüft sein SMTP-Client fortan, ob sich das Ziel in einer DNSsec-signierten Domain befindet und ob ein TLSA Ressource Record (RR) für den anzusteuernden MX existiert. Der Client soll die Existenz eines TLSA RR wie eine Policy werten. Bietet der im TLSA RR referenzierte Server kein STARTTLS an, dann ist das ein Policy-Verstoß. Der Transport muss unterbleiben.

Schutz vor MITM

DANE SMTP schützt auch vor Man-in-the-Middle-Attacken (MITM). Eine erfolgreiche MITM-Attacke vergiftet beispielsweise das DNS des Opfers mit gefälschten Ressource Records (DNS Poisoning). Gefälschte MX-Einträge verweisen dann auf den SMTP-Server des Angreifers. Dessen Server gibt vor, für die angeblich korrekte Zieldomain Nachrichten anzunehmen. Er kann sogar STARTTLS mit einem gültigen Zertifikat anbieten.

Ein unkontrollierter SMTP-Client wird das Zertifikat akzeptieren und dem Angreifer arglos die schützenswerten Nachrichten über eine verschlüsselte Verbindung in den Rachen werfen. Das ist möglich, weil die meisten MTAs zur Identitätsüberprüfung nur den Common Name (CN) des Zertifikats überprüfen.

Zertifizierte Täuschung

Ein Angreifer, der ein Zertifikat mit einem passenden CN besitzt, kann den Client einfach täuschen. Er muss sich nicht anstrengen, ein selbst signiertes Zertifikat genügt. Die meisten Clients akzeptieren selbst signierte Zertifikate, ohne mit der Wimper zu zucken. Solange der CN stimmt, wird verschlüsselt, egal wer sich hinter dem Zertifikat verbirgt. Davor schützen auch von öffentlichen Certification Authorities (CA) signierte Zertifikate nicht, denn die Clients prüfen standardmäßig nur den CN und nicht, wer das Zertifikat ausgestellt hat.

Ein Designfehler verschlimmert das Ganze noch: CAs können unabhängig voneinander gültige Zertifikate für dieselbe Domain erstellen. Diese Schwachstelle haben sich Angreifer zunutze gemacht, als sie in die Zertifizierungsstellen Diginotar und Türktrust eindrangen und dort Zertifikate für Domains bekannter Unternehmen ausstellten.

Nachdem die Vorfälle bekannt geworden waren, wurden eiligst die Root-Zertifikate der kompromittierten CAs deaktiviert. Bis zum Zeitpunkt der Entdeckung verfügten die Angreifer über “amtliche” Zertifikate. Sie konnten selbst jene SMTP-Clients täuschen, die nur Zertifikate bekannter CAs akzeptieren.

Identifikationskriterien

Die Kriterien, die zur Identifikation des Gegenüber herangezogen werden, bilden das Problem. Wer nur auf den Hostnamen achtet, abgebildet im CN des Zertifikats, kann leicht Opfer einer Täuschung werden. Namen sind sozusagen Schall und Rauch. Der Fingerprint eines Zertifikats ist hingegen einmalig. Er lässt sich – Stand Ende 2014 – nicht fälschen. Ein SMTP-Client, der auf den Fingerprint achtet, kann einer MITM-Attacke nicht auf dem Leim gehen.

Ein SMTP-Client, der opportunistische TLS durchführt, verbindet den Fingerprint eines Zertifikats nicht mit einer konkreten Identität. Das geschieht erst dann, wenn der Administrator in einer TLS-Policy der Zieldomain ein oder mehrere (SMTP-Cluster) Fingerprints zuordnet (Certificate Pinning).

Certificate Pinning

Wer Certificate Pinning wirklich ernst nimmt, fixiert nicht einfach den Fingerprint. Er stellt vorher die Identität sicher und besorgt sich zuerst den Fingerprint der Gegenstelle. Anschließend sucht er sich einen geeigneten Ansprechpartner in der Zieldomain. Von dieser Person lässt er sich den Fingerprint des eingesetzten Zertifikats vorlesen. Dann vergleicht er beide Fingerprints. Stimmen sie überein, darf er den Fingerprint fixieren. Reichlich kompliziert und arbeitsaufwändig.

DANE SMTP nimmt sich auch dieses Problems an: Es automatisiert die Identifizierung. Der TLSA Ressource Record publiziert den Fingerprint des verwendeten Zertifikats samt einiger beschreibender Aussagen über das Zertifikat. Ein DANE-fähiger SMTP-Client kann diese Informationen vertrauenswürdig über eine DNSsec-signierte Domain beziehen und sie selbstständig mit dem Fingerprint des Gegenüber vergleichen.

Sogar an den Rollover eines Zertifikats haben die RFC-Autoren gedacht. Wer ein neues Zertifikat mit neuem Fingerprint einsetzen möchte, veröffentlicht zeitweise zwei TLSA RRs für dieselbe Ressource (ein RR-Beispiel zeigt Listing 2). Für den SMTP-Client zählt nur, dass einer der veröffentlichten TLSA RRs passt. Der alte TLSA RR lässt sich entfernen, sobald seine DNS TTL abgelaufen ist.

01 $ dig TLSA _25._tcp.mail.sys4.de +short
02 3 0 1 9273B4E9040C1B9EE7C946EFC0BA8AAF2C6E5F05A1B2C960C41655E3 2B15CBE

Wer angesichts der erwähnten CA-Schwachstellen auf selbst signierte Zertifikate umsteigen möchte, der findet ein weiteres Mal bei DANE SMTP Unterstützung. Ein TLSA RR gestattet es, den Fingerprint für ein selbst signiertes Zertifikat zu veröffentlichen oder einfach nur den Verweis auf das Root-Zertifikat einer eigenen CA. Die signierte DNSsec-Domain bürgt in beiden Fällen.

DANE SMTP benutzen

Ein DNSsec-verifizierender DNS-Resolver ist Voraussetzung für DANE SMTP. Er sollte auf demselben Host arbeiten, auf dem auch der DANE-fähige MTA betrieben wird. Hat eine DNSsec-aktivierte Domain Probleme beispielsweise mit ihrer Signatur, ist dies ein Indiz für ein Sicherheitsproblem. Auskünfte einer solchen Domain dürfen Clients konsequenterweise nicht verwenden, weil die Vertrauenswürdigkeit der ganzen Domain in Frage gestellt ist.

Herkömmliche Resolver erkennen derartige Probleme nicht, nur DNSsec-fähige bemerken DNSsec-Fehler und unterdrücken die Antwort. Listet »/etc/resolv.conf« mehrere Resolver, dann müssen alle DNSsec-fähig sein, damit ein lückenloser Trust gewährleistet ist.

Ein abschließender Test stellt sicher, dass alles geklappt hat. Den Transport einer E-Mail an »sink@dane.sys4.de« sollte der eigene Postfix als »Verified TLS …« protokollieren:

Dec  9 13:44:23 mail postfix/smtp[14944]: Verified TLS connection established to dane.sys4.de[194.126.158.134]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Um dieses Protokoll zu erhalten, sollte der Admin den Parameter »smtp_tls_loglevel« auf »1« setzen.

Der DNS-Resolver Unbound

Unbound [3] ist ein guter DNSsec-fähiger Resolver. Er ist leicht eingerichtet, schnell und cacht DNS-Anfragen. Nach der Installation genügt es in der Regel, »unbound-anchor« auszuführen, um Root-Zertifikate für die DNSsec Trust Chain zu laden. Der zusätzliche Aufruf von »unbound-control-setup« generiert lokale Zertifikate für die sichere Kommunikation des Kommandozeilen-Kontrollprogramms »unbound-control« , das Unbound bequem verwaltet.

Nach dem Start bindet Unbound sich standardmäßig an die Adresse des Localhost. Die Dig-Abfrage einer DNSsec-aktivierten Domain (Listing 3) stellt sicher, dass Unbound DNSsec erkennen und verifizieren kann. Das zusätzliche Flag »ad« (Authenticated Domain) im Headerbereich der Antwort kennzeichnet eine erfolgreiche Abfrage.

01 $ dig @localhost +dnssec sys4.de
02
03 ; <<>> DiG 9.9.5-3-Ubuntu <<>> @localhost +dnssec sys4.de
04 ; (1 server found)
05 ;; global options: +cmd
06 ;; Got answer:
07 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15587
08 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 3
09 [...]

Bis zum Erscheinen dieses Artikels bietet nur Postfix vollständigen DANE-SMTP-Support. Das liegt vor allem daran, dass Viktor Dukhovni, einer der Autoren des DANE-SMTP-RFC, zugleich einer der führenden Autoren von Postfix ist. Seine Überlegungen zu DANE SMTP sind in Postfix eingeflossen, seine Erfahrungen hat er in das RFC zurückgeführt.

Nur Postfix ab Version 2.11.1

Für DANE SMTP bedarf es mindestens Postfix 2.11.1. Nachdem der SMTP-Client grundsätzlich für TLS konfiguriert ist, genügen wenige Handgriffe, und Postfix kann mit DANE-SMTP-Servern umgehen. Der Parameter »smtp_dns_support_level« weist Postfix dazu an, DNSsec-validierende Anfragen an den Resolver zu stellen. Die Option »dane« für »smtp_tls_security_level« (Listing 4) setzt die neue TLS-Policy. Ab sofort fragt Postfix über DNSsec ab, ob die MX(e) der Zieldomain TLSA RRs besitzen, und prüft, ob deren Fingerprints mit denen der Server übereinstimmen.

01 smtp_dns_support_level = dnssec
02 smtp_tls_security_level = dane

TLS-Policies aktivieren

Wer eine TLS-Policy publizieren möchte, muss seine Domain für DNSsec aktivieren. Gut ein Drittel der deutschen Registrare bietet derzeit die Infrastruktur, um eine Domain DNSsec-aktiviert zu hosten. Wer einen eigenen DNS-Server laufen hat, kann seine Domains natürlich auch selbst DNSsec-aktiviert betreiben.

Welche Schritte dazu erforderlich sind, variiert je nach eingesetztem Produkt: DNSsec mit aktuellem Bind funktioniert problemlos. Ältere NS-Server, beispielsweise Djbdns, haben jedoch noch Probleme. In jedem Fall ist es wichtig, die Signaturen einer DNSsec-aktivierten Domain innerhalb ihrer TTL penibel zu erneuern. Laufen diese ohne Erneuerung ab, gilt die Domain als nicht mehr vertrauenswürdig, DNSsec-fähige Resolver ignorieren dann alle Anfragen.

TLSA RR

In der signierten Zone des MX muss der Administrator noch einen passenden TLSA RR eintragen. Ein TLSA-Generator [4] hilft beim Erstellen des Ressource Record. Wer ein CA-signiertes Zertifikat besitzt, der wählt die Optionsfelder »3« , »1« sowie nochmals »1« und kopiert das eigenen Zertifikat in das dafür vorgesehene Eingabefeld und gibt anschließend noch an, wie der damit verbundene Service zu erreichen ist (Abbildung 2).

Abbildung 2: Der TLSA-Generator erzeugt TLSA-RRs bequem im Browser.

Die generierte Ausgabe kann er dann in die Zonen-Datei übernehmen. Nach einem Update der Serial Number und einem Reload steht der neue Eintrag für Abfragen bereit. Damit ist die Policy scharfgeschaltet. Der Sys4-DANE-Validator [5] vom E-Mail-Spezialisten Patrick Koetter hilft, indem er gewissenhaft prüft, ob die veröffentlichte TLS-Policy ohne Mängel ist.