Verschlüsselt zustellen: TLS, MTA-STS und DANE

Modul 5: Reputation und die großen Empfänger · Lesezeit: 10 Minuten

Lernziel: Nach dieser Lektion können Sie erklären, wie Mailserver untereinander verschlüsseln, warum das standardmäßig nicht erzwingbar ist, und was MTA-STS, TLS-RPT und DANE daran ändern. Sie können die Records nachschlagen und lesen.

Kernbegriffe: STARTTLS zwischen Servern, opportunistische Verschlüsselung, Downgrade-Angriff, MTA-STS (RFC 8461), _mta-sts-Record, Policy-Datei, Modus testing/enforce/none, TLS-RPT (RFC 8460), _smtp._tls-Record, DANE für SMTP (RFC 7672), TLSA-Record, DNSSEC

Zwei Arten von Verbindungen

In Lektion 1.4 ging es um die Verbindung zwischen Ihrem E-Mail-Programm und dem Mailserver Ihres Anbieters: Port 587 mit STARTTLS, oder 465 mit direktem TLS, mit Anmeldung. Dort haben Sie selbst die Kontrolle. Ihr Programm weiß, welchen Server es erwartet, prüft das Zertifikat und verweigert die Verbindung, wenn etwas nicht stimmt.

Diese Lektion behandelt den Schritt danach: die Verbindung zwischen dem versendenden Server und dem empfangenden Server, auf Port 25. Die läuft anders ab.

Opportunistisch: verschlüsseln, wenn es geht

Wenn ein Server Mail zustellt, verbindet er sich mit dem MX des Empfängers. Nach EHLO prüft er, ob der empfangende Server STARTTLS anbietet. Wenn ja, wechselt er zu einer verschlüsselten Verbindung. Wenn nein, stellt er die Mail einfach unverschlüsselt zu.

Das nennt man opportunistische Verschlüsselung: verschlüsseln, wenn es geht, sonst nicht. Und meistens prüft der versendende Server das Zertifikat nicht streng. Ein abgelaufenes oder selbst erstelltes Zertifikat ist dann kein Grund, abzubrechen.

Warum ist das so? Weil Mail immer funktionieren muss, auch mit alten Servern. Ein Absender kann nicht wissen, ob ein Empfänger TLS unterstützen sollte. Das ermöglicht zwei Angriffe:

1. Downgrade. Jemand, der den Datenverkehr unterwegs verändern kann, entfernt das Wort STARTTLS aus der Antwort des Empfängers. Der Absender denkt, es gebe keine Verschlüsselung, und stellt unverschlüsselt zu. Der Angreifer liest mit.
2. Falscher MX. Jemand, der DNS-Antworten fälschen kann, gibt einen eigenen Server als MX an. Da das Zertifikat nicht geprüft wird, bemerkt der Absender nichts.

Heutzutage verschlüsseln fast alle großen Mailserver, und Gmail verlangt von Absendern die Verwendung von TLS (Lektion 5.3). Aber „meistens verschlüsselt“ ist etwas anderes als „immer und mit dem richtigen Server“. Dafür gibt es zwei Lösungen: MTA-STS und DANE. Beide werden vom Empfänger eingerichtet: Sie teilen damit mit, dass Mail an Ihre Domain immer verschlüsselt erfolgen muss, bei einem Server mit gültigem Zertifikat.

MTA-STS: Policy über eine Webseite

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) besteht aus zwei Teilen.

Ein TXT-Record, der angibt, dass eine Policy existiert:

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261108T120000;"

Und eine Policy-Datei an einem festen Ort, über https mit gültigem Zertifikat:

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

Das Clevere daran: Ein Absender merkt sich die Policy für die Dauer von max_age. Ein Angreifer, der später das Wort STARTTLS entfernt oder einen falschen MX vorgibt, fliegt dann auf: Die Policy sagt, dass Verschlüsselung verpflichtend ist und welche Server gültig sind. Bei der allerersten Verbindung (bevor die Policy bekannt ist) schützt MTA-STS nicht; das ist die bekannte Schwachstelle.

Ein echtes Beispiel ist gmail.com: Der TXT-Record _mta-sts.gmail.com existiert, und die Policy-Datei unter https://mta-sts.gmail.com/.well-known/mta-sts.txt steht auf mode: enforce.

TLS-RPT: Berichte über fehlgeschlagene Verschlüsselung

Mit MTA-STS auf enforce kann Mail hängen bleiben, wenn etwas mit Ihrem Zertifikat nicht stimmt. Das wollen Sie wissen. Dafür gibt es TLS-RPT (RFC 8460):

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"

Absender, die TLS-RPT unterstützen (unter anderem Google und Microsoft), senden dann täglich einen Bericht im JSON-Format: wie viele Verbindungen erfolgreich waren und welche fehlgeschlagen sind, mit dem Grund (zum Beispiel ein abgelaufenes Zertifikat oder ein Name, der nicht in der Policy steht). Wie bei DMARC-Berichten (Lektion 4.5) können Sie diese von einem Berichtsdienst auswerten lassen.

Reihenfolge bei der Einführung: zuerst TLS-RPT, dann MTA-STS auf testing, einige Wochen Berichte lesen, und erst danach enforce. Das ähnelt der schrittweisen Vorgehensweise bei DMARC: erst beobachten, dann streng werden.

DANE: das Zertifikat im DNS, abgesichert mit DNSSEC

DANE (DNS-based Authentication of Named Entities) geht anders vor. Sie setzen im DNS einen TLSA-Record bei jedem MX-Server, mit einem Fingerabdruck des Zertifikats oder des Schlüssels:

_25._tcp.mx1.example.com.  3600  IN  TLSA  3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5

_25._tcp bedeutet: für SMTP auf Port 25. Die drei Zahlen geben an, wie der Wert zu lesen ist. Bei Mailservern ist 3 1 1 am gebräuchlichsten: „dies ist der SHA-256-Fingerabdruck des öffentlichen Schlüssels genau dieses Servers“. Auch 2 1 1 kommt vor: dann steht der Fingerabdruck eines Zwischenzertifikats darin.

Ein Absender, der DANE unterstützt, sieht den TLSA-Record, verlangt Verschlüsselung und prüft, ob das Zertifikat des Servers passt. Passt es nicht, erfolgt keine Zustellung.

Warum ist DANE sicher gegen gefälschte DNS-Antworten? Weil es nur mit DNSSEC (DNS-Kurs Lektion 8.1) funktioniert. Ohne gültige DNSSEC-Kette werden TLSA-Records ignoriert. Das ist zugleich die Hürde: sowohl Ihre Domain (für den MX) als auch die Zone des Mailservers müssen signiert sein.

DANE hat keine „Erstmals“-Schwäche wie MTA-STS, und es ist in den Niederlanden und in Deutschland weit verbreitet. internet.nl testet darauf. Microsoft unterstützt DANE für eingehende Mail in Exchange Online. Auch die MX-Server von internet.nl haben TLSA-Records.

Stolperfalle: Ersetzen Sie das Zertifikat eines Mailservers mit DANE durch einen neuen Schlüssel, muss der TLSA-Record mitgeändert werden, und zwar vorher: erst den neuen Record hinzufügen, warten, bis die TTL abgelaufen ist, dann erst den neuen Schlüssel verwenden. Andernfalls weisen DANE-Absender Ihre Mail zurück. Bei 3 1 1 spielt das nur eine Rolle, wenn sich der Schlüssel ändert, nicht bei jeder Verlängerung mit demselben Schlüssel.

MTA-STS oder DANE?

Sie dürfen beide nebeneinander verwenden. RFC 8461 besagt, dass ein Absender, der DANE unterstützt, DANE bevorzugt, wenn gültige TLSA-Records vorhanden sind.

Wer regelt das?

Dies richten Sie für eingehende Mail an Ihre Domain ein. Läuft Ihre Mail über ein Hosting-Unternehmen oder einen Maildienst, hängt es von diesem Anbieter ab:

• DANE funktioniert nur, wenn der Anbieter TLSA-Records für seine Mailserver veröffentlicht und Ihre Domain DNSSEC verwendet. Bei WebOké können Sie DANE zum Beispiel an derselben Stelle aktivieren wie DNSSEC (siehe den internet.nl-Artikel unten); bei anderen Anbietern funktioniert es ähnlich oder ist standardmäßig geregelt.
• MTA-STS können Sie manchmal selbst einrichten, aber dann muss mta-sts.example.com eine Website mit gültigem Zertifikat sein, und Sie müssen die MX-Namen Ihres Anbieters kennen.
• TLS-RPT können Sie immer selbst einrichten: Es ist nur ein TXT-Record mit einer Berichtsadresse.

Für Ihre ausgehende Mail müssen Sie nichts tun: Der Server Ihres Anbieters entscheidet, ob er MTA-STS und DANE von Empfängern berücksichtigt.

Zusammenfassung

• Zwischen Mailservern ist TLS standardmäßig opportunistisch: verschlüsselt, wenn es geht, ohne strenge Zertifikatsprüfung. Das ermöglicht Downgrade und falsche MX-Angaben.
• MTA-STS: TXT _mta-sts plus Policy-Datei unter https://mta-sts.<domain>/.well-known/mta-sts.txt; Modus testing oder enforce.
• TLS-RPT: TXT _smtp._tls mit einer Berichtsadresse, für tägliche Berichte über fehlgeschlagene Verschlüsselung.
• DANE: TLSA-Record unter _25._tcp.<mx-server>, funktioniert nur mit DNSSEC und schützt auch die erste Verbindung.
• Führen Sie es wie DMARC ein: erst Berichte (TLS-RPT, testing), dann streng werden.

Quiz

Aufgabe

Aufgabe Z5.4: MTA-STS, TLS-RPT und DANE nachschlagen. Suchen Sie bei gmail.com den MTA-STS-Record und den TLS-RPT-Record, öffnen Sie die Policy-Datei und tragen Sie den Modus ein (enforce, testing oder none). Suchen Sie danach bei einem MX-Server von internet.nl den TLSA-Record unter _25._tcp.<mx-server> und tragen Sie die ersten drei Zahlen eines der Records ein. Optional: dieselben Fragen für Ihre eigene Domain (dort darf die Antwort „keiner“ lauten). Das Programm fragt alles live ab und vergleicht.

Weiterführende Informationen

Die Schritte in diesen Artikeln gelten für die Panels von WebOké; bei anderen Anbietern funktioniert es ähnlich.

• Internet.nl-Checkliste
• Was ist DNSSEC?
• Kostenloser DNS-Kurs 8.1: DNSSEC in einfacher Sprache
• internet.nl, testen Sie Ihre E-Mail (unabhängiger Test von STARTTLS, DANE und mehr): https://internet.nl/
• RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE für SMTP)