Wer heute eine E-Mail verschickt, kann ziemlich sicher sein, dass sie verschlüsselt übertragen wird. Zwischen großen Anbietern läuft praktisch aller Verkehr über TLS. Was dabei gern übersehen wird: diese Verschlüsselung ist eine Höflichkeit, keine Bedingung. Sie lässt sich von außen abschalten, und in der Grundeinstellung merkt das niemand.
Warum SMTP-Verschlüsselung nachgeben darf
SMTP ist älter als die Verschlüsselung, die es heute benutzt. Sie wurde nachträglich eingebaut, über ein Kommando namens STARTTLS: Der empfangende Server nennt beim ersten Kontakt seine Fähigkeiten, darunter — vielleicht — STARTTLS. Der Absender greift zu, wenn das Angebot da ist.
Aus dieser Reihenfolge folgen zwei Eigenschaften, die zusammen das ganze Problem ergeben:
- Die Aushandlung findet im Klartext statt. Wer die Verbindung kontrolliert, kann die Zeile mit dem Angebot einfach herausstreichen. Der Absender sieht dann einen Server, der kein TLS kann — und liefert im Klartext aus, weil die Alternative wäre, gar nicht zuzustellen.
- Zertifikate werden in der Grundeinstellung nicht geprüft. Im Web bricht der Browser bei einem falschen Zertifikat ab. Im SMTP-Verkehr zwischen Servern wird üblicherweise alles akzeptiert: abgelaufen, selbst ausgestellt, auf einen ganz anderen Namen. Die Verbindung ist dann verschlüsselt, aber niemand hat geprüft, mit wem.
Diese Nachgiebigkeit war Absicht. Als TLS eingeführt wurde, konnte die Mehrheit der Server es nicht, und eine strenge Regel hätte die Zustellung zerlegt. Der Preis ist, dass die Verschlüsselung genau dann verschwindet, wenn jemand aktiv daran interessiert ist.
MTA-STS: die Richtlinie über HTTPS
MTA-STS schließt die Lücke mit einem Mittel, das ohnehin überall vorhanden ist: einem Webserver mit gültigem Zertifikat. Die Domain hinterlegt zwei Dinge.
Einen DNS-Eintrag unter _mta-sts.firma.de, der nur sagt, dass es eine Richtlinie gibt, und eine Versionskennung trägt:
_mta-sts.firma.de. TXT "v=STSv1; id=20260903120000"Die Richtlinie selbst, abrufbar unter einer festen Adresse, https://mta-sts.firma.de/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mail.firma.de
mx: mail2.firma.de
max_age: 604800Der sendende Server holt diese Datei über HTTPS — also über eine Verbindung mit echter Zertifikatsprüfung — und merkt sie sich für die angegebene Dauer. Ab dann gilt: dieser Empfänger kann TLS, sein Zertifikat muss auf einen der genannten Namen lauten, und wenn beides nicht zutrifft, wird nicht zugestellt.
Der Angreifer aus dem Bild kann die SMTP-Verbindung weiterhin manipulieren. Er kann nur nichts mehr damit anfangen, weil der Absender bereits weiß, was er zu erwarten hat.
Der Modus ist dabei entscheidend. testing meldet Verstöße nur, enforce lehnt ab. Der Weg führt über testing, bis die Berichte sauber sind — sonst schaltet man sich die eigene Zustellung ab.
DANE: die Richtlinie im DNS
DANE löst dasselbe Problem anders. Statt einer Datei auf einem Webserver liegt der Fingerabdruck des erwarteten Zertifikats direkt im DNS, als TLSA-Eintrag neben dem MX-Namen:
_25._tcp.mail.firma.de. TLSA 3 1 1 <Fingerabdruck des Schlüssels>Die Angabe bindet die Verbindung an genau diesen Schlüssel. Ein anderes Zertifikat, gleich von welcher Zertifizierungsstelle ausgestellt, wird abgelehnt.
Das funktioniert allerdings nur unter einer Bedingung: die Zone muss mit DNSSEC signiert sein. Ohne DNSSEC ließe sich der TLSA-Eintrag auf demselben Weg fälschen wie alles andere im DNS, und die ganze Übung wäre wirkungslos. DANE ohne DNSSEC gibt es nicht — das ist keine Empfehlung, sondern Voraussetzung.
Die beiden im Vergleich
| MTA-STS | DANE | |
|---|---|---|
| Vertrauensanker | Zertifizierungsstellen (wie im Browser) | DNSSEC |
| Abruf über | HTTPS, dazu ein DNS-Eintrag | ausschließlich DNS |
| Voraussetzung | Webserver mit gültigem Zertifikat | signierte Zone |
| Erste Verbindung | ungeschützt, bis die Richtlinie geholt ist | ab der ersten Verbindung geschützt |
| Zwischenspeicherung | ja, bis max_age abläuft | nein, gilt die DNS-Gültigkeitsdauer |
| Typische Fehlerquelle | abgelaufenes Webzertifikat, vergessene id | Schlüsselwechsel ohne neuen TLSA-Eintrag |
Die Verfahren schließen einander nicht aus. Wer beides hinterlegt, wird von jedem Absender geschützt, der eines von beiden beherrscht — und das sind zusammen deutlich mehr als bei jedem einzeln.
Der unauffällige Teil: die Berichte
Beide Verfahren scheitern still. Bricht eine Verbindung ab, weil ein Zertifikat abgelaufen ist, bleibt die Nachricht in der Warteschlange des Absenders — Sie erfahren davon nichts, bis jemand nachfragt, warum keine Post mehr kommt.
Dagegen gibt es TLS-RPT, einen weiteren DNS-Eintrag:
_smtp._tls.firma.de. TXT "v=TLSRPTv1; rua=mailto:tls-berichte@firma.de"Sendende Server schicken dann täglich eine Zusammenfassung: wie viele Verbindungen zustande kamen, wie viele scheiterten und woran. Das ist der Teil, den man am liebsten weglässt und am ehesten braucht. Eine Richtlinie ohne Rückmeldekanal ist eine Falle, die irgendwann zuschnappt.
Was das nicht leistet
Beide Verfahren sichern den Transport zwischen zwei Servern. Am Ziel liegt die Nachricht wieder unverschlüsselt, der Betreiber des Zielservers kann sie lesen, und über den zweiten und dritten Zwischenschritt sagen sie nichts. Wer den Inhalt vor dem Anbieter schützen will, braucht eine Verschlüsselung, die über den ganzen Weg reicht — worin sich diese Verfahren unterscheiden und warum E-Mail von Haus aus nicht Ende zu Ende verschlüsselt ist, steht in einem eigenen Artikel.
MTA-STS und DANE lösen ein enger gefasstes Problem, und das lösen sie gut: sie nehmen einem Angreifer die Möglichkeit, Verschlüsselung durch bloßes Stören verschwinden zu lassen.