MTA-STS gestaltet Mail-Versand und -Empfang sicherer

Schon seit mehreren Jahren wurde am Standard MTA-STS gearbeitet, jüngst wurde er von der IETF als RFC 8461 veröffentlicht. In unserem Beitrag „MTA-STS: sichere Verschlüsselung zwischen Mailservern“ können Sie dies nachlesen.

Heute erläutern wir Ihnen die Funktionsweise und geben Hilfestellung bei der Konfiguration.

MTA-STS – Was ist das?

MTA-STS ist die Abkürzung für „Mail Transfer Agent – Strict Transport Security“. Seit Anfang 2016 setzen sich diverse große Unternehmen wie Yahoo, Google, Microsoft, Comcast, 1&1 oder LinkedIn für die Entwicklung eines Standards ein, der die Übertragung von E-Mails sicherer gestalten soll.

Dieser Vorschlag wurde bei der Internet Engineering Task Force (IETF) eingereicht, die den Standard ihrerseits weiterentwickelte, bis er als RFC 8461 veröffentlicht werden konnte.

Funktionsweise von MTA-STS

Zugegeben: Mit STARTTLS, S/MIME, PGP, DANE oder DMARC gibt es schon genügend SMTP-Abkürzungen. Sie alle haben ihre Stärken und Schwächen. Letztere sollen mithilfe von MTA-STS deutlich minimiert werden, indem MTA-STS den unverschlüsselten E-Mail-Versand zwischen zwei Mailservern unterbindet. Es geht also explizit um die Kommunikation zwischen Mailservern.

Mithilfe von MTA-STS ist es dem empfangenden Mailserver möglich, dem versendenden Mailserver per DNS mitzuteilen, dass dieser TLS zur Transportverschlüsselung nutzen soll (Achtung: Damit lautet der DNS-Eintrag nicht mehr auf „_smtp_sts“, sondern auf „_mta_sts“). Der Versand-Mailserver wird vor dem E-Mail-Versand in die Lage versetzt, eine MTA-STS-Policy von einem Webserver abzurufen. Hierin wird definiert, welche E-Mail-Server die E-Mails per TLS entgegennehmen.

Der Versand-Server speichert eben diese Policy für eine Dauer, die definiert werden kann. Innerhalb dieses Zeitraums werden E-Mails ausschließlich per TLS zugestellt.

Durch diesen Vorgang werden beispielsweise Man-in-the-middle-Attacken (MITM-Attacken) effektiv verhindert. Im Prinzip handelt es sich bei MTA-STS also um eine erzwungene Verschlüsselung für Mailserver.

Ist MTA-STS nun der Durchbruch?

E-Mail-Anbieter versuchen schon seit Jahrzehnten, die Kommunikation ihrer Kunden vor Lauschangriffen sowie Manipulation zu schützen. Mit STARTTLS fand man eine flexible Möglichkeit für verschlüsselte, aber auch für Klartextverbindungen. Jedoch musste man bald feststellen, dass sich STARTTLS zu einfach unterbinden lässt. Ein „Man in the Middle“ ist in der Lage, die Kommunikation abzuhören und/ oder zu manipulieren.

Mit DANE für SMTP wurde im Jahr 2015 ein offenes Verfahren standardisiert. Basis dafür jedoch ist eine Namensauflösung per DNSSEC. Es gibt große Provider, die DANE zügig implementiert hatten. Jedoch ist DANE für zahlreiche Administratoren bis heute nicht umsetzbar, da sich nicht jede Domain per DNSSEC auflösen lässt. DANE konnte sich deshalb nie richtig durchsetzen.

Die Brücke zwischen dem als unzureichend sicher eingestuften STARTTLS und dem häufig nicht realisierbaren DANE soll MTA-STS schlagen. Vielfach wird MTA-STS als eine Art DANE ohne DNSSEC beschrieben.

MTA-STS: Hilfe bei der Konfiguration

Das Einrichten von MTA-STS ist denkbar einfach. Sie benötigen einen Mailserver, der TLS unterstützt, drei DNS-Namen sowie einen Webserver, der per HTTPS erreichbar ist. Um zu starten, müssen Sie eine Policy einrichten. Das könnte für die Domain psw-group.de so aussehen:

version: STSv1
mode: testing
max_age: 86400
mx: mail.psw-group.de
mx: *.psw-group.de

In dieser Beispiel-Policy ist die STS-Version enthalten; aktuell gibt es nur die Version STSv1. Bei „mode“ entscheiden Sie sich für „testing“, wenn Sie testen möchten, oder „enforce“, wenn Sie bereits produktiv arbeiten. „max_age” definiert den Zeitraum, über den der Mailserver die Policy cachen darf. Die Angabe erfolgt in Sekunden. Geben Sie in der Policy außerdem alle Mailserver an, die TLS zwingend anfordern und unterstützen müssen. Sie können diese einzeln oder als Wildcard angeben (mx).

Haben Sie Ihre Policy erstellt, sichern Sie diese als Textdatei mit dem Namen mta-sts.txt. Übertragen Sie die Policy auf einen Webserver. Wichtig: Dieser Webserver muss per HTTPS erreichbar sein! Das Zertifikat für den Webserver muss von einer vertrauenswürdigen Zertifizierungsstelle stammen; selbstsignierte Zertifikate funktionieren nicht. Daneben muss der Webserver unter dem Namen mta-sts.domain.de aufrufbar sein. Für unsere Beispiel-Domain hieße das also, dass der Webserver unter mta-sts.psw-group.de erreichbar sein muss. Speichern Sie die Policy im Verzeichnis .well_known.

Ihre Policy sollte nun unter folgendem Link erreichbar sein: https://mta-sts.domain.de/.well-known/mta-sts.txt.

Neben dem DNS-Eintrag für den Webserver benötigen Sie zwei weitere TXT-Records: _mta-sts.domain.de sowie _smtp._tls.domain.de. Der letzte TXT-Record ist zwar nicht zwingend notwendig, jedoch könnte der MTA-STS validator ohne ihn ins Stolpern kommen.

Im Eintrag _mta-sts.domain.de sind die STS-Version sowie eine Policy-ID zu vergeben, die als Zeitstempel fungiert. Ändert sich die Policy, muss die ID entsprechend angepasst werden.

Zur Fehleranalyse dient der zweite TXT-Record. Hinterlegen Sie hier eine E-Mail-Adresse, sendet Ihnen der Mailserver Informationen zu etwaigen Problemen.

Um zu testen, ob die Mailserver für TLS konfiguriert sind, bietet sich der TLS-Test von CheckTLS an. Für MTA-STS muss der Mailserver TLS mindestens in der Version 1.2 unterstützen. Der MTA-STS validator von Ayke van Laëthem erlaubt es, die MTA-STS-Konfiguration zu prüfen. Geben Sie für den Test einfach die Domain ein.

Ergeben sich im Testbetrieb keinerlei Probleme, lässt sich die Policy in den Produktivmodus schalten (mode: enforce). Dann kann auch die Zeitspanne (max_age) erheblich erhöht werden, beispielsweise auf 4 – 6 Monate.