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:

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:

MTA-STS (Strict Transport Security)

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:

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

MTA-STS (Strict Transport Security)

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

MTA-STS (Strict Transport Security)

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:

MTA-STS (Strict Transport Security)

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:

MTA-STS (Strict Transport Security)

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.

MTA-STS (Strict Transport Security)

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.

15 Gedanken zu „MTA-STS (Strict Transport Security)“

  1. Man sollte nicht jeden Blödsinn mitmachen. Zeitstempel im DNS, Datei auf Webserver, der widerum ein separates Zertifikat braucht… und das nur um eine Art E-Mail-HSTS zu erreichen? Ich habe selten so viel Murks auf einem Haufen gesehen.

    Antworten
  2. Es gibt ein Typo:
    Falsch: „Die Policy wird nun im Verzeichnis .well_known gespeichert:“
    Richtig: „Die Policy wird nun im Verzeichnis .well-known gespeichert:“
    Vorsicht also mit Copy & Paste.

    Gruß
    Intercepta

    Antworten
  3. @Federick
    mit Lets Encrypt und entsprechenden Skripten lässt sich das eigentlich vollständig automatisieren.

    Es sind zwei DNS-Einträge:
    _mta-sts.kunde1.de
    mta-sts.kunde1.de

    Ein CNAME-Eintag würde bei _mta-sts problemlos umsetzbar sein. Setzt allerdings voraus, dass der Webhoster auch von Kunde1 die E-Mails verwaltet. Hostet er diese wo anders, muss der Eintrag vom Kunde anpassbar sein.

    Ein CNAME Eintrag für mta-sts wird ein SSL-Fehler hervorrufen, da das SSL-Zertikat aller Voraussicht nach nicht die entsprechende Subdomain enthält. Aber auch hier sehe ich eine Möglichkeit dies zu automatisieren. Wobei auch der Inhalt der Datei für den Kunden editierbar sein muss.

    Antworten
  4. Erstmal vielen Dank für den super Blog-Beitrag!! Sehr gut beschrieben :)

    Es muss doch eine einfachere Lösung für Provider gehen die einen Shared-Mailserver für viele hunderte Kunden betreiben. Bei allen Kundendomains ein SSL-Zertifikat und dazugehörigen Webserver zu schalten ist unverhältnismäßig hoher Aufwand.

    _mta-sts.user.example. IN CNAME _mta-sts.provider.example.

    ^^ in dem Fall müsse ein SSL Schutz nur am Endpoit (mta-sts.provider.example) geschaltet werden was den Aufwand für Provider erheblich reduziert.

    In der RFC bin ich hierzu auf folgenden Punkt „8.2. Policy Delegation“ gestoßen, demnach ist eine Weiterleitung per CNAME möglich wenn am Endpoint ein valider SSL-Schutz besteht. Sofern ich den Teil nicht missverstehe sollte es also auch mit weniger Aufwand für Provider möglich sein.
    https://datatracker.ietf.org/doc/rfc8461/?include_text=1

    Antworten
  5. Hallo Franky,

    erst einmal vielen Dank für diesen ausführlichen Blogbeitrag. Wieder mal sehr ausführlich und sehr aufschlussreich.

    Bei mir stellt sich die Frage, was ich an der Konfiguration falsch eingestellt habe, bzw. wo der Fehler zu suchen ist.
    Der von dir durchgeführte Test über Checktls.com zeigt bei mir an das TLS/Cert/Secure – FAIL ist. Auf die UTM sind die Ports 25 und 465 von extern erreichbar.

    Antworten
  6. Wie sieht es eigentlich aus, wenn man viele verschiedene Domains hat, jedoch alle auf die gleichen MX zeigen, muss man dann für alle auch die Eintrage erstellen oder genügt es, nur für diejenige Domain, welche die MX hosted?

    Antworten
    • Für die beiden DNS-Einträge _mta-sts.domain.de und _smtp._tls.domain.de kannst du auf DNS CNAME-Einträge zurückgreifen. Bezüglich der Adresse für die Textdatei funktioniert dies nicht. Sprich du brauchst dedizierte Adressen, welche über das jeweilige SSL-Zertifikat verfügen. Daher haben wir uns einen kl. Server mit Administrationspanel zugelegt, gehärtet und dort alle Subdomains entsprechend angelegt und anschließend mit LE versehen. Weil alles andere sprengt den Kostenrahmen auf Dauer.

      Antworten
      • Danke für deine Antwort. Eigentlich meinte ich es so rum:
        Provider X betreibt einen Mailserver, welcher unter domain1.de erreichbar ist.
        Domain2.de, domain3.de etc senden über diesen Mailserver:
        domain2.de. 21599 IN MX 10 mx1.domain1.de.
        domain3.de. 21599 IN MX 10 mx1.domain1.de.
        domain4.de. 21599 IN MX 10 mx1.domain1.de.

        Müssen die Domänen domain2, domain3 etc nun auch über ssl erreichbar sein oder nur die Domäne, auf welcher der Mailserver läuft? Weil eigentlich müsste ja nur domain1.de abgesichert werden… (da ist dnssec mit dane logischer und einfacher :) )

        Antworten
        • Genau dieses Szenario habe ich beschrieben. Für jede E-Mail muss es diese DNS-Einträge und Subdomain mit der Textdatei geben.

Schreibe einen Kommentar