Das Problem: STARTTLS ist opportunistisch
Der Großteil der E-Mails zwischen Servern wird mit STARTTLS verschlüsselt, einer SMTP-Erweiterung, die die Verbindung von Klartext auf TLS hochstuft. STARTTLS hat jedoch einen grundlegenden Mangel: Es ist opportunistisch. Scheitert die TLS-Aushandlung aus irgendeinem Grund — ein Angreifer, der den STARTTLS-Befehl blockiert, ein abgelaufenes Zertifikat, ein Konfigurationsfehler — fahren die meisten sendenden Server unverschlüsselt fort und senden die E-Mails ohne Verschlüsselung. Ein Angreifer, der sich im Netzwerk befindet (Man-in-the-Middle), kann den STARTTLS-Befehl einfach abfangen und die Verbindung unverschlüsselt erzwingen, sodass alle E-Mails im Transit mitgelesen werden können.
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) löst dieses Problem, indem es der Empfängerdomäne ermöglicht zu erklären: „E-Mails an meine Domäne dürfen nur über gültige TLS-Verbindungen zugestellt werden." Wenn der sendende Server MTA-STS unterstützt und die TLS-Aushandlung scheitert, wird die E-Mail nicht unverschlüsselt gesendet — sie wird zurückgehalten und der Absender wird benachrichtigt. Damit wird die Möglichkeit von Downgrade-Angriffen eliminiert.
Wie MTA-STS funktioniert
MTA-STS erfordert zwei Komponenten: einen DNS-TXT-Eintrag unter _mta-sts.domäne.com, der das Vorhandensein der Richtlinie signalisiert und eine eindeutige ID (typischerweise einen Zeitstempel) enthält, die bei jeder Änderung aktualisiert wird, sowie eine Richtliniendatei, die über HTTPS unter https://mta-sts.domäne.com/.well-known/mta-sts.txt bereitgestellt wird. Die Tatsache, dass die Richtlinie über HTTPS (nicht DNS) bereitgestellt wird, fügt eine zusätzliche Sicherheitsebene hinzu: Ein Angreifer müsste auch das HTTPS-Zertifikat kompromittieren, um die Richtlinie zu fälschen.
Die Richtlinie gibt an: die Version (STSv1), den Modus (testing oder enforce), die Hostnamen der autorisierten Mailserver (mx:) und die Cache-Dauer der Richtlinie (max_age in Sekunden). Der Modus testing meldet Probleme in den TLS-RPT-Berichten, ohne die Zustellung zu blockieren, sodass Probleme identifiziert und behoben werden können, bevor zu enforce gewechselt wird.
MTA-STS und TLS-RPT: das perfekte Duo
MTA-STS ohne TLS-RPT Lookup ist wie eine Alarmanlage ohne Benachrichtigung: Es blockiert Probleme, aber warnt Sie nicht. TLS-RPT (RFC 8460) liefert detaillierte Berichte über TLS-Fehler und ermöglicht es Ihnen zu überwachen, wie viele TLS-Verbindungen erfolgreich sind, wie viele scheitern und warum. Konfigurieren Sie TLS-RPT immer zusammen mit MTA-STS, um vollständige Transparenz über die Sicherheit der eingehenden E-Mail-Verbindungen zu erhalten.
Unser MTA-STS Lookup überprüft beide Komponenten: den DNS-Eintrag und die HTTPS-Richtlinie. Es kontrolliert, ob der Eintrag existiert und eine gültige ID hat, ob die Richtliniendatei über HTTPS mit einem gültigen Zertifikat erreichbar ist, ob die MX-Server in der Richtlinie mit den tatsächlichen MX-Einträgen der Domäne übereinstimmen, und ob Modus und max_age korrekt konfiguriert sind.
Schritt-für-Schritt-Implementierung
Die Implementierung von MTA-STS erfordert einen HTTPS-Webserver zur Bereitstellung der Richtlinie. Wenn Sie bereits eine Website für die Domäne haben, können Sie eine Subdomäne mta-sts.ihredomäne.com mit einem gültigen SSL-Zertifikat erstellen. Alternativ können Dienste wie Cloudflare Workers oder GitHub Pages die Richtliniendatei kostenlos hosten. Das HTTPS-Zertifikat muss gültig und von einer öffentlichen Zertifizierungsstelle ausgestellt sein — selbstsignierte Zertifikate werden nicht akzeptiert.
Beginnen Sie mit mode: testing, um Daten ohne Auswirkung auf die Zustellung zu sammeln. Überwachen Sie die TLS-RPT-Berichte mindestens 2 Wochen lang. Überprüfen Sie, ob Ihr Zertifikat SSL Check gültig ist und Ihre MX-Server TLS 1.2+ unterstützen. Sobald bestätigt ist, dass keine Probleme vorliegen, wechseln Sie zu mode: enforce. Aktualisieren Sie die ID im DNS-Eintrag bei jeder Änderung der Richtlinie, um die Cache-Aktualisierung der sendenden Server zu erzwingen.