MTA-STS: sichere Verschlüsselung zwischen Mailservern

Bei der E-Mail-Verschlüsselung bewegt sich etwas: Die IETF hat mit MTA-STS einen Standard zum Absichern von Verbindungen zwischen Mailservern per TLS und Zertifikaten geschaffen. Damit wird ein aktiver Schutz vor „Man-in-the-Middle-Angriffen“ gewährleistet.

Warum „Man-in-the-Middle-Angriffe“ problematisch sind

Schon heute lassen sich Verbindungen zwischen Mailservern mit STARTTLS verschlüsseln. Jedoch hat dieses Verfahren diverse Probleme. STARTTLS ist optional. Mittels Man-in-the-Middle-Attacke lässt sich recht leicht verhindern, dass die verschlüsselte Verbindung aufgebaut wird. Es muss dafür lediglich der STARTTLS-Befehl aus der Verbindung gefiltert werden.

Hinzu kommt, dass Zertifikate bei Verbindungen via E-Mail nicht überprüft werden. Oftmals verwenden Mailhoster eigens signierte, abgelaufene oder sonstig ungültige Zertifikate. Es würde nicht viel bewirken, die Zertifikate zu überprüfen. Mailserver laufen häufig auf einem anderen Host. Dieser wird per DS und einem MX-Record signalisiert. Angreifer können die E-Mails einfach auf einen eigenen Server umleiten, um dort ein gültiges Zertifikat vorzuzeigen.

STARTTLS verhindert also das Mitlauschen von Nachrichten, jedoch keine Man-in-the-Middle-Angriffe. In aller Regel finden Verbindungen zwischen Usern und Servern mittlerweile verschlüsselt statt. Oft über TLS-gesicherte Varianten von POP3, IMAP sowie SMTP oder aber über HTTPS-Interfaces. Nach wie vor sind jedoch die Verbindungen zwischen den Servern weitgehend ungeschützt. Genau das soll sich mit MTA-STS ändern.

Mailserver-Betreiber definieren eine Policy, die per HTTPS publiziert wird. MTA-STS bringt HSTS und HTTPS auf die Mail-Server.

Mögliche Sicherheitslücken beim Mail-Versand

Zum Auslesen von E-Mails haben sich für Cyberkriminelle drei sehr häufige Man-in-the-Middle-Angriffe bewährt:
• DNS-Spoofing: Angreifer können die DNS-Antworten des Absender-Servers derart verändern, dass Nutzer nicht ans richtige Ziel gelangen. Sie sprechen mit einem anderen Server und die E-Mails werden dort abgelegt. Sogar STARTTLS könnte der Server anbieten. Auf dem Server läge die unverschlüsselte E-Mail, sie kann mitgelesen und weitergeleitet werden.
• STARTTLS unterdrücken: Kann ein System auf die Verbindung zugreifen, kann die Antwort auf eine EHLO-Anfrage derart verändert werden, dass der Absender gar nicht erfährt, dass die Gegenseite STARTTLS unterstützt. Die E-Mail wird dann unverschlüsselt gesendet.
• Falsches Zertifikat: Mailserver nutzen in aller Regel STARTTLS, versäumen es jedoch, das Zertifikat zu verifizieren. Oftmals besitzen Server nicht mal ein „öffentliches“ Zertifikat, und wenn doch, so muss es nicht mit dem Mailserver-Namen übereinstimmen.

MTA-STS: der neue Standard zur Verschlüsselung von Mailservern

Die E-Mail hinkt – verglichen mit anderen Kommunikationskanälen – schon lang in Sachen Verschlüsselung hinterher. Zwar ist eine Ende-zu-Ende-Verschlüsselung möglich, wird jedoch leider kaum genutzt. MTA-STS soll eine praktikable Möglichkeit bieten, den Transportweg zwischen Mailservern zu sichern.

Standardisiert wurde der RFC 8461 zu SMTP Mail Transfer Agent Strict Transport Security – kurz MTA-STS – von der IETF. Beteiligt an der Entwicklung waren jedoch auch die großen Mailserver-Betreiber, unter anderem Google, Microsoft oder Oath. Ein Mailserver signalisiert mit MTA-STS, dass TLS-gesicherte Verbindungen unterstützt werden. Der anfragende Mailserver wird angewiesen, künftig ausschließlich verschlüsselte Verbindungen zu akzeptieren. Über DNS und HTTPS werden die STS-Informationen bereitgestellt.

Funktionsweise von MTA-STS

Mailserver-Betreiber definieren eine Policy, die via HTTPS publiziert wird. Der Betreiber legt zunächst im DNS-Server einen TXT-Record an. Dieser signalisiert, dass eine Policy vorhanden ist. Unter der Subdomain „mta-sts“ wird die eigentliche Policy dann über HTTPS publiziert. So ist gewährleistet, dass diese Policy ausschließlich von einem Inhaber eines gültigen Zertifikats publiziert wurde. Analog zum DNS-Record gibt man eine Version an. Außerdem einen „mode“, in dem „enforce“, „testing“ oder „none“ angegeben werden kann.

Um vor Angriffen und unberechtigten Verbindungen geschützt zu sein, muss der „enforce“-Modus aktiviert werden. Im „testing“-Modus soll ein Fehlerreporting realisiert werden, jedoch ist diese Funktion optional und es bleibt noch abzuwarten, ob dieser Modus in der Praxis überhaupt implementiert wird.

Die Angabe „mx“ erlaubt das Eintragen aller gültigen Mailserver. Die Angaben stimmen idealerweise mit den MX-Records im DNS-Server überein. Mit „max_age“ wird zu guter Letzt angegeben, wie lange die Policy gilt. Man gibt diese Gültigkeit in Sekunden an; 1209600 wären etwa zwei Wochen. Je länger die Gültigkeit, umso sicherer ist das Verfahren. So kann die Policy für example.org unter https://mta-sts.example.org/.well-known/mta-sts.txt beispielsweise aussehen:

version: STSv1
mode: enforce
mx: mail1.example.org
mx: mail2.example.org
max_age: 1209600