SMTP-Downgrade-Angriffe: Funktionsweise und wirksamer Schutz

⚡TL;DR

• SMTP überträgt E-Mails standardmäßig im Klartext. STARTTLS fügt Verschlüsselung hinzu, bleibt aber anfällig für Downgrade-Angriffe (STARTTLS-Stripping)
• Ein Netzwerkangreifer kann die STARTTLS-Option aus der Serverantwort entfernen und so den Klartextversand erzwingen, ohne dass der Absender es bemerkt
• MTA-STS (RFC 8461) und DANE/TLSA (RFC 7672) erzwingen die verpflichtende TLS-Verschlüsselung und blockieren diese Angriffe
• Hosten Sie Ihre MTA-STS-Richtlinie kostenlos mit CaptainDNS: Zwei DNS-Einträge genügen, um Ihre Domains in weniger als 5 Minuten zu schützen

Jeden Tag werden Milliarden von E-Mails zwischen SMTP-Servern übertragen. Die Mehrheit nutzt STARTTLS zur Verschlüsselung der Verbindung. Doch diese Verschlüsselung ist opportunistisch: Wenn der Zielserver nicht auf die Verschlüsselung antwortet, wird die Nachricht im Klartext gesendet. Ein Netzwerkangreifer kann dieses Verhalten mit einem einzigen Netzwerkpaket erzwingen.

SMTP-Downgrade-Angriffe, auch STARTTLS-Stripping genannt, nutzen diese Schwachstelle aus. Sie ermöglichen das Abfangen von E-Mails im Klartext, selbst wenn beide Server TLS-Verschlüsselung unterstützen. Das Problem: Weder Absender noch Empfänger werden über den Angriff informiert.

Dieser Artikel erläutert den technischen Mechanismus dieser Angriffe, ihre Varianten, ihre realen Auswirkungen laut Google-Daten und konkrete Lösungen zum Schutz Ihrer Domains. Wenn Sie E-Mail-Server verwalten oder für die Sicherheit einer Domain verantwortlich sind, ist dieser Leitfaden für Sie.

Wie SMTP Ihre E-Mails überträgt

SMTP (Simple Mail Transfer Protocol, RFC 5321) ist das Protokoll zur Weiterleitung von E-Mails zwischen Servern. Es wurde 1982 entworfen und sieht keine native Verschlüsselung vor. Jede Nachricht wird im Klartext zwischen dem sendenden und dem empfangenden Server übertragen.

STARTTLS: eine opportunistische Verschlüsselung

Im Jahr 2002 führte RFC 3207 STARTTLS ein. Dieser Mechanismus ermöglicht es zwei SMTP-Servern, eine TLS-Verbindung nach dem Aufbau der initialen Klartextverbindung auszuhandeln.

Der Ablauf ist wie folgt:

1. Der sendende Server öffnet eine TCP-Verbindung auf Port 25
2. Der empfangende Server antwortet mit seinen Fähigkeiten, darunter 250 STARTTLS
3. Der sendende Server sendet den Befehl STARTTLS
4. Beide Server handeln eine TLS-Verbindung aus
5. Die E-Mail wird verschlüsselt übertragen

S: 220 mx.captaindns.com ESMTP
C: EHLO mail.captaindns.com
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250-STARTTLS        ← Der Server signalisiert TLS-Unterstützung
S: 250 OK
C: STARTTLS            ← Der Client fordert Verschlüsselung an
S: 220 Ready to start TLS
[TLS-Aushandlung]
C: EHLO mail.captaindns.com
[Verschlüsselte E-Mail-Übertragung]

Warum "opportunistisch" problematisch ist

Das Schlüsselwort ist opportunistisch. Wenn der Befehl STARTTLS fehlschlägt oder nicht angeboten wird, sendet der Server die E-Mail im Klartext, ohne jemanden zu benachrichtigen. Dies ist eine bewusste Designentscheidung: RFC 3207 priorisiert die Zustellung der Nachricht über deren Vertraulichkeit.

Diese Entscheidung schafft die Schwachstelle, die von Downgrade-Angriffen ausgenutzt wird.

Anatomie eines SMTP-Downgrade-Angriffs

Ein SMTP-Downgrade-Angriff (STARTTLS-Stripping) besteht darin, die TLS-Aushandlung zwischen zwei E-Mail-Servern zu verhindern. Der Angreifer erzwingt die Rückkehr zu einer Klartextverbindung.

Wie funktioniert STARTTLS-Stripping?

Der Angreifer muss sich im Netzwerkpfad zwischen den beiden Servern positionieren (Man-in-the-Middle). Er fängt die TCP-Pakete ab und modifiziert die Antwort des empfangenden Servers:

1. Der sendende Server sendet EHLO an den empfangenden Server
2. Der empfangende Server antwortet mit 250 STARTTLS in seinen Fähigkeiten
3. Der Angreifer fängt diese Antwort ab und entfernt die Zeile 250 STARTTLS
4. Der sendende Server erhält eine Antwort ohne Erwähnung von STARTTLS
5. Der sendende Server folgert, dass der Empfänger keine Verschlüsselung unterstützt
6. Die E-Mail wird im Klartext gesendet
7. Der Angreifer liest den Nachrichteninhalt

[Originalantwort des empfangenden Servers]
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250-STARTTLS        ← vorhanden
S: 250 OK

[Vom Angreifer modifizierte Antwort]
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250 OK              ← STARTTLS entfernt

Der Angriff ist für beide Server unsichtbar. Der sendende Server denkt, der Empfänger unterstütze kein TLS. Der empfangende Server weiß nicht, dass ihm eine E-Mail im Klartext gesendet wurde.

Wer kann diesen Angriff durchführen?

Jede Instanz, die sich im Netzwerkpfad befindet:

• Internetdienstanbieter (ISP): kontrollieren das Routing des Datenverkehrs
• Betreiber von Zwischennetzwerken: Internet-Austauschpunkte (IXP)
• Angreifer im lokalen Netzwerk: öffentliches WLAN, kompromittiertes Unternehmensnetzwerk
• Staatliche Akteure: dokumentierte Massenüberwachung in bestimmten Ländern

Angriffsvarianten auf den E-Mail-Transport

STARTTLS-Stripping ist die bekannteste Variante, aber auch andere Angriffe zielen auf den E-Mail-Transport ab.

DNS-Spoofing der MX-Einträge

Der Angreifer fälscht die DNS-Antwort für die MX-Einträge der Ziel-Domain. Der sendende Server leitet die E-Mail dann an einen vom Angreifer kontrollierten falschen Server weiter.

; Legitime DNS-Antwort
captaindns.com. MX 10 mx.captaindns.com.

; Vom Angreifer gefälschte DNS-Antwort
captaindns.com. MX 10 mx.angreifer.com.

DNSSEC schützt gegen diesen Angriff, indem es DNS-Antworten kryptografisch signiert.

Angriff auf das TLS-Zertifikat

Selbst wenn STARTTLS ausgehandelt wird, validiert SMTP standardmäßig nicht das Zertifikat des empfangenden Servers. Ein Angreifer kann ein selbstsigniertes oder ungültiges Zertifikat präsentieren, und der sendende Server akzeptiert die Verbindung ohne Überprüfung.

MTA-STS und DANE erzwingen die Zertifikatsvalidierung und blockieren diese Variante.

BGP-Hijacking

Ein Angreifer kündigt falsche BGP-Routen an, um den Netzwerkverkehr auf seine eigene Infrastruktur umzuleiten. Dieser Angriff zielt auf die Netzwerkinfrastruktur ab und kann den gesamten Datenverkehr betreffen, nicht nur E-Mails.

Reale Auswirkungen: Wer ist betroffen?

Die Zahlen von Google

Der Google Transparency Report zur E-Mail-Verschlüsselung im Transit liefert konkrete Daten:

• Über 90 % der eingehenden E-Mails bei Gmail sind mit TLS verschlüsselt
• Über 90 % der ausgehenden E-Mails von Gmail verwenden TLS
• Bestimmte Regionen und Anbieter liegen unter 70 %

Diese Zahlen zeigen, dass die SMTP-Verschlüsselung Fortschritte gemacht hat, aber Lücken bestehen. Jede unverschlüsselte E-Mail stellt eine Gelegenheit für einen Downgrade-Angriff dar.

Am stärksten betroffene Branchen

Branche	Risiko	Grund
Gesundheitswesen	Hoch	Patientendaten, HIPAA-/DSGVO-Konformität
Finanzwesen	Hoch	Sensible Finanzinformationen
Rechtswesen	Hoch	Berufsgeheimnis, Mandantenvertraulichkeit
Verwaltung	Mittel	Bürgerdaten, interne Prozesse
KMU	Mittel	E-Mail-Infrastruktur oft unzureichend konfiguriert

Dokumentierte Angriffe

Von der EFF und APNIC veröffentlichte Forschungen haben Fälle von STARTTLS-Stripping im großen Maßstab durch Netzwerkbetreiber in mehreren Ländern dokumentiert. Diese Angriffe zielen nicht auf eine bestimmte Domain ab: Sie fangen den gesamten SMTP-Verkehr ab, der über die kompromittierte Infrastruktur geleitet wird.

Schutz gegen Downgrade-Angriffe

Vier ergänzende Mechanismen ermöglichen die Absicherung des E-Mail-Transports.

MTA-STS (RFC 8461): verpflichtende TLS-Verschlüsselung

MTA-STS ermöglicht es einer Domain, eine Richtlinie zu veröffentlichen, die sendende Server zur TLS-Verschlüsselung verpflichtet. Die Richtlinie wird auf einem HTTPS-Server gehostet, einem separaten und authentifizierten Kanal, den der Angreifer nicht durch STARTTLS-Stripping kompromittieren kann.

Funktionsweise:

1. Der sendende Server entdeckt den TXT-Eintrag _mta-sts.captaindns.com
2. Er lädt die Richtlinie von https://mta-sts.captaindns.com/.well-known/mta-sts.txt herunter
3. Die Richtlinie gibt die autorisierten MX-Server und den Modus (testing/enforce) an
4. Im Enforce-Modus verweigert der Server den Versand im Klartext

Vorteil: Erfordert kein DNSSEC. Funktioniert mit jedem Registrar.

Einschränkung: Die erste Anfrage (vor dem Caching) bleibt verwundbar (TOFU, Trust On First Use).

DANE/TLSA (RFC 7672): das im DNS verankerte Zertifikat

DANE veröffentlicht den Fingerabdruck des TLS-Zertifikats direkt in einem TLSA-Eintrag im DNS. Der sendende Server überprüft, ob das präsentierte Zertifikat mit dem im DNS deklarierten übereinstimmt.

Vorteil: Kein TOFU. Die Überprüfung erfolgt sofort bei der ersten Verbindung.

Einschränkung: Erfordert DNSSEC über die gesamte DNS-Kette, was die Verbreitung einschränkt.

TLS-RPT (RFC 8460): Sichtbarkeit bei Fehlern

TLS-RPT blockiert keine Angriffe, macht sie aber sichtbar. Sendende Server, die TLS-RPT unterstützen, senden tägliche Berichte über TLS-Aushandlungsfehler.

Diese Berichte ermöglichen die Erkennung von:

• Downgrade-Versuchen
• Abgelaufenen oder ungültigen Zertifikaten
• Konfigurationsproblemen auf Ihren MX-Servern

Konfigurieren Sie TLS-RPT mit unserem TLS-RPT-Generator, um diese Berichte zu erhalten.

DNSSEC: der DNS-Schutz

DNSSEC signiert DNS-Antworten kryptografisch und verhindert das Spoofing von MX-Einträgen. Es bildet die Grundlage für DANE, stärkt aber auch die Sicherheit von MTA-STS, indem es die Auflösung des _mta-sts-Eintrags schützt.

🎯 Empfohlener Aktionsplan

1. Überprüfen Sie Ihre aktuelle Konfiguration: Verwenden Sie den MTA-STS-Prüfer, um den Status Ihrer Domain zu analysieren
2. Aktivieren Sie MTA-STS im Testing-Modus: Hosten Sie Ihre Richtlinie kostenlos mit CaptainDNS und überwachen Sie die TLS-RPT-Berichte 1 bis 2 Wochen lang
3. Konfigurieren Sie TLS-RPT: Erhalten Sie TLS-Fehlerberichte, um Probleme zu erkennen, bevor sie Ihre E-Mails beeinträchtigen
4. Wechseln Sie in den Enforce-Modus: Wenn die Berichte bestätigen, dass alles funktioniert, aktivieren Sie den Enforce-Modus, um unverschlüsselte Verbindungen zu blockieren
5. Evaluieren Sie DANE: Wenn Ihr Registrar und Ihr DNS-Hoster DNSSEC unterstützen, fügen Sie TLSA-Einträge für einen Schutz ohne TOFU hinzu

---

Schützen Sie Ihre E-Mails jetzt vor Downgrade-Angriffen: Hosten Sie Ihre MTA-STS-Richtlinie kostenlos mit CaptainDNS. Zwei DNS-Einträge, kein Webserver zu verwalten.

---

FAQ

Was ist ein SMTP-Downgrade-Angriff?

Ein SMTP-Downgrade-Angriff (oder STARTTLS-Stripping) verhindert die TLS-Verschlüsselungsaushandlung zwischen zwei E-Mail-Servern. Der im Netzwerk positionierte Angreifer entfernt die STARTTLS-Option aus der Antwort des empfangenden Servers. Der sendende Server sendet die E-Mail dann im Klartext, wodurch der Angreifer den Nachrichteninhalt lesen kann.

Wie erkennt man einen Downgrade-Angriff auf meine E-Mails?

Konfigurieren Sie TLS-RPT (RFC 8460) für Ihre Domain. Kompatible sendende Server senden tägliche Berichte, die TLS-Aushandlungsfehler auflisten. Ein plötzlicher Anstieg der Fehler kann auf einen Downgrade-Versuch hinweisen. Aktivieren Sie auch MTA-STS im Testing-Modus, um Berichte zu erhalten, ohne die Zustellung zu blockieren.

Schützt MTA-STS vor allen Downgrade-Angriffen?

MTA-STS schützt vor STARTTLS-Stripping und Angriffen auf TLS-Zertifikate. Es schützt nicht vor DNS-Spoofing der MX-Einträge (verwenden Sie dafür DNSSEC) oder vor BGP-Hijacking. Für einen vollständigen Schutz kombinieren Sie MTA-STS mit DNSSEC und, wenn möglich, DANE/TLSA.

Was ist der Unterschied zwischen MTA-STS und DANE?

MTA-STS veröffentlicht eine Richtlinie über HTTPS und funktioniert ohne DNSSEC. DANE verankert das TLS-Zertifikat im DNS über TLSA-Einträge und erfordert DNSSEC. MTA-STS leidet unter dem TOFU-Problem (die erste Anfrage ist nicht geschützt). DANE bietet eine sofortige Überprüfung. Beide ergänzen sich.

Ist STARTTLS ausreichend, um meine E-Mails zu sichern?

Nein. STARTTLS verschlüsselt die Verbindung opportunistisch, schützt aber nicht vor Downgrade-Angriffen oder ungültigen Zertifikaten. Ein Netzwerkangreifer kann die STARTTLS-Option entfernen oder ein falsches Zertifikat präsentieren. MTA-STS oder DANE sind erforderlich, um die TLS-Verschlüsselung zu erzwingen.

Sind große Anbieter wie Gmail und Outlook verwundbar?

Gmail und Microsoft 365 unterstützen MTA-STS als sendende Server: Sie überprüfen und respektieren die MTA-STS-Richtlinien der Ziel-Domains. Wenn Ihre Domain eine MTA-STS-Richtlinie im Enforce-Modus veröffentlicht, verweigern Gmail und Outlook den Klartextversand an Ihre Server, selbst bei einem Downgrade-Versuch.

Sollte man MTA-STS und DANE gleichzeitig aktivieren?

Das ist nicht zwingend erforderlich, wird aber empfohlen, wenn Ihre Infrastruktur es erlaubt. MTA-STS ist einfacher bereitzustellen (kein DNSSEC erforderlich) und deckt die Mehrheit der sendenden Server ab. DANE bietet zusätzliche Sicherheit (kein TOFU) für Server, die es unterstützen. Beide Mechanismen koexistieren ohne Konflikte.

📖 Glossar

• STARTTLS: SMTP-Erweiterung (RFC 3207), die die Aushandlung einer TLS-Verbindung nach dem Aufbau einer Klartextverbindung auf Port 25 ermöglicht.
• STARTTLS-Stripping: Angriff, bei dem die STARTTLS-Ankündigung aus der Serverantwort entfernt wird, um die Verschlüsselung zu verhindern.
• MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). HTTPS-Richtlinie, die die TLS-Verschlüsselung für den E-Mail-Empfang erzwingt.
• DANE: DNS-Based Authentication of Named Entities (RFC 7672). Mechanismus, der das TLS-Zertifikat über TLSA-Einträge im DNS verankert.
• TLS-RPT: SMTP TLS Reporting (RFC 8460). Berichtsmechanismus über TLS-Aushandlungsfehler zwischen E-Mail-Servern.
• TOFU: Trust On First Use. Sicherheitsmodell, bei dem die erste Verbindung nicht überprüft wird, nachfolgende Verbindungen aber anhand der ersten validiert werden.
• DNSSEC: DNS Security Extensions. System kryptografischer Signaturen, das DNS-Antworten authentifiziert und deren Fälschung verhindert.

📚 Verwandte Leitfäden zur E-Mail-Transportsicherheit

• MTA-STS vs. DANE: Welches Protokoll für die Absicherung des E-Mail-Transports? (demnächst)
• Von Testing zu Enforce: Progressive MTA-STS-Bereitstellungsstrategie (demnächst)

Quellen

• RFC 5321 - Simple Mail Transfer Protocol
• RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security
• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities
• Google Transparency Report - E-Mail-Verschlüsselung im Transit