MTA-STS (Strict Transport Security)

MTA-STS (Mail Transfer Agent-Strict Transport Security, kurz STS) ist es recht neues Werkzeug um den Mail Versand und Empfang etwas sicherer zu gestalten. MTA-STS wurde mittlerweile als RFC-8461 verabschiedet und kann somit eingesetzt werden. Ähnlich wie bei DANE, werden für STS Informationen im DNS hinterlegt. Der große Unterschied ist aber: Für STS ist kein DNSSEC erforderlich. Viele Hoster unterstützen aktuell noch kein DNSSEC, somit kann auch DANE nicht genutzt werden. Hier soll STS Abhilfe schaffen (zumindest übergangsweise bis sich DNSSEC und DANE flächendeckend durchgesetzt haben).

Funktionsweise

MTA-STS soll unterbinden, dass Mails unverschlüsselt zwischen Mailserver ausgetauscht werden, hierbei geht es explizit um die Kommunikation von Mailserver zu Mailserver, nicht um die Kommunikation zwischen Mailserver und Client. Der empfangene Mailserver kann dem sendenden Server via DNS mitteilen, dass er explizit TLS zur Transportverschlüsselung unterstützt. Der sendende Mailserver kann vor dem Versand einer E-Mail eine MTA-STS Policy von einem Webserver abrufen, in der definiert wird, welche Mailserver E-Mails per TLS entgegen nehmen. Der sendende Mailserver speichert die Policy für eine definierte Dauer und stellt Mails für diese Dauer nur noch via TLS zu. Auf diese Weise soll verhindert werden, dass eine Mail ohne Transportverschlüsselung gesendet wird, beispielsweise wenn per MITM-Attacke das StartTLS Kommando unterdrückt wird. Im Prinzip handelt es sich also um erzwungenes StartTLS für Mailserver ab der ersten Mail. STS ist zwar nicht so sicher wie DANE, ist aber einfacher umzusetzen, da es kein DNSSEC erfordert. Da es noch viele Domains gibt, meine eingeschlossen, die noch nicht via DNSSEC auflösbar sind, kann hier STS zumindest übergangsweise nützlich sein, bis DNSSEC und damit DANE implementiert ist.

In diesem Youtube Video ist MTA-STS und DANE ziemlich gut erklärt:

• SMTP STS (Strict Transport Security) vs. SMTP with DANE

Einrichtung

Die Einrichtung von STS ist denkbar einfach. Alles was benötigt wird, ist ein Mailserver der TLS (StartTLS) unterstützt, 3 DNS Namen und ein Webserver der via HTTPS erreichbar ist.

Webserver und MTA-STS Policy

Zunächst muss eine Policy erstellt werden, für den Testbetrieb könnte diese beispielsweise für die Domain frankysweblab.de wie folgt aussehen:

version: STSv1
mode: testing
max_age: 86400
mx: mail.frankysweblab.de
mx: *.frankysweblab.de

Die Policy enthält die STS Version (version), hier gibt es aktuell nur STSv1, den Modus in dem die Policy arbeitet (mode: testing für Tests mode: enforce für produktiv) und die Zeitspanne die ein Mailserver die Policy cachen darf (max_age in Sekunden). Zusätzlich werden innerhalb der Policy alle Mailserver angegeben die zwingend TLS erfordern und unterstützen. Diese können einzeln, sowie auch als Wildcard angegeben werden (mx).

Eine produktive Policy würde für die Domain frankysweblab.de in etwa so aussehen:

version: STSv1
mode: enforce
max_age: 15552000
mx: mail.frankysweblab.de
mx: *.frankysweblab.de

Gegenüber der Testpolicy oben hat sich nur den Modus geändert, sowie die maximale Cachedauer (mode: enforce und max_age: 6 Monate 15552000 Sekunden).

Die Policy wird nun als einfaches Textfile mit dem Namen mta-sts.txt gespeichert.Die Policy muss nun auf einen Webserver übertragen werden der via HTTPS erreichbar ist, nur http reicht an dieser Stelle nicht.

Zusätzlich muss der Webserver unter der Namen mta-sts.domain.de aufrufbar sein. Für die Domain frankysweblab.de, muss der Webserver also unter der Domain mta-sts.frankysweblab.de erreichbar sein. Die Policy wird nun im Verzeichnis .well_known gespeichert:

Somit ist die Policy für frankysweblab.de unter folgenden Link erreichbar: https://mta-sts.frankysweblab.de/.well-known/mta-sts.txt Die URL ist fix und kann nicht geändert werden, erforderlich ist immer der Domainname der E-Mail Adresse (frankysweb.de, gmail.com) und dann eben das Prefix mta-sts und der Order .well-known mit der Policy mta-sts.txt. Hier ein paar Beispiele:

• https://mta-sts.frankysweb.de/.well-known/mta-sts.txt
• https://mta-sts.gmail.com/.well-known/mta-sts.txt
• https://mta-sts.web.de/.well-known/mta-sts.txt

Auch das Zertifikat für den Webserver muss von einer vertrauenswürdigen CA stammen. Ein selbst signiertes Zertifikat funktioniert hier nicht. Kostenlose Zertifikate von Let’s Encrypt und Wildcard Zertifikate sind in Ordnung.

DNS Einträge

Zusätzlich zu dem DNS Eintrag für “mta-sts” für den Webserver, werden noch zwei TXT-Records benötigt:

• _mta-sts.domain.de
• _smtp._tls.domain.de (Dieser TXT Record wird nicht zwingend benötigt, ohne meckert allerdings der MTA-STS validator)

Der Eintrag _mta-sts.domain.de enthält als Wert nur die STS-Version (v=STSv1) und eine ID für die Policy als Zeitstempel (id=20181230231800Z). So ergibt sich für die Domain frankysweblab.de der folgende DNS TXT Record:

• Name: _mta-sts.frankysweblab.de
• Text: v=STSv1; id=20181230231800Z

Die ID muss dann entsprechend angepasst werden, wenn sich die Policy ändert.

Der zweite TXT Record dient der Fehleranalyse, Mailserver können an die Hinterlegte E-Mail Adresse Informationen zu Problemen senden, es kann also nicht schaden eine entsprechende E-Mail Adresse anzugeben. Für die Domain frankysweblab.de ergibt sich der folgende Eintrag (es muss wieder nur eine Version und eine entsprechende Mail Adresse angegeben werden):

• Name: _smtp._tls.frankysweblab.de
• Text: v=TLSRPTv1; rua=mailto:postmaster@frankysweblab.de

Test

Zunächst sollte einmal überprüft werden, ob alle Mailserver (MX-Record) entsprechend für TLS konfiguriert sind, dies lässt sich mit dem TLS Test von CheckTLS prüfen:

Der Mailserver muss für STS mindestens TLS 1.2 unterstützen.

Die STS Konfiguration lässt sich mit dem MTA-STS validator von Ayke van Laëthem prüfen. Für den Test muss nur die Domain eingetragen werden. Das Ergebnis sieht dann in etwa so aus:

In diesem Beispiel handelt es sich noch um eine Testpolicy (siehe Mode testing), diese hat daher eine kurze Zeitspanne (max_age). Wenn es im Testbetrieb keine Probleme gibt, kann die Policy in den Produktivbetrieb geschaltet werden (mode enforce), dann ist es auch nötig die Zeitspanne deutlich zu erhöhen (Beispielsweise 4 – 6 Monate für max_age).

Der Webserver der die Policy ausliefert, kann mit dem SSLTest von Qualys überprüft werden, der Webserver sollte hier auch ein ordentliches Ranking erreichen und das Zertifikat als Vertrauenswürdig angezeigt werden.

Fazit

MTA-STS ist an sich ein guter Ansatz, leider ist es aktuell noch wenig verbreitet. Mailserver und AntiSPAM Lösungen die STS bereits unterstützen, sind noch sehr rar. Da der Standard noch sehr jung ist, ist dies aber auch nicht sehr verwunderlich, man kann es ja aber schon einmal einrichten und dabei helfen, dass sich MTA-STS schneller durchsetzt. Wenn allerdings schon die Weichen für DNSSEC gestellt sind, dann sollte auch direkt über den Einsatz von DANE nachgedacht werden.

Noch ein Wort zu Exchange Server: Exchange (inkl. Exchange 2019) unterstützt kein STS. Hier muss man sich weiterhin auf alternative Lösungen hinsichtlich verlassen. Da Exchange Server aber hauptsächlich in internen Netzwerken zum Einsatz kommt und meist durch vorgelagerte E-Mail Security Produkte geschützt werden, kann man das Fehlen dieses Features auch vernachlässigen.