SMTP MTA STS (Strict Transport Security)

Es ist ja nicht so, dass es mit DANE, DMARC, STARTTLS, PGP, SMIME u.a. nicht schon genug SMTP-Abkürzungen geben würde. Aber Anfang 2016 haben ein paar große Provider (Microsoft, Google, Yahoo, Comcast, LinkedIn und 1&1) einen Vorschlag zur besseren Sicherung der Übertragung von Mails per SMTP beim IETF eingereicht. .

RFC 8461 wurde verabschiedet: SMTP MTA Strict Transport Security (MTA-STS)
https://tools.ietf.org/html/rfc8461

Das Problem

Die meisten Mailserver lauschen auf Port 25 um eingehende Mails anzunehmen. Der MX-Eintrag im DNS teilt der Welt mit, wo dieser Server zu suchen ist und der "Erstkontakt" findet immer erst einmal unverschlüsselt statt. Ein Absender, der im Prinzip Verschlüsselung per TLS unterstützt, erfragt dies durch eine "EHLO"-Anfrage und wertet die Antwort aus. Sie könne das einfach mit einem TELNET ausprobieren.

Da ich leider kein fließend TLS per Telnet spreche, komme ich hier erst mal nicht weiter aber ab dem Moment ist alles verschlüsselt. Aber es gibt hier gleich mehrere Probleme:

  • DNS-Spoofing und Verifikation des "Richtigen Server"
    Ein Angreifer könnte die DNS-Antworten an meinen Absende-Server verändern, so dass ich gar nicht an das richtige Ziel sondern mit einen anderen Server spreche und dort meine Mails ablegen. Der Server könnte sogar STARTTLS anbieten, muss es aber nicht. Auf jeden Fall hätte der Server meine unverschlüsselte Mail und kann sie mitlesen und an den richtigen Server weiterleiten. Wenn ich meine Domäne nicht per SPF, SenderID gesichert hätte, würde der Empfänger diese Mail auch von dem unautorisierten Relay annehmen und niemand würde etwas merken. Wer schaut schon die Header-Zeilen an und prüft den vorherigen Hop?
    Die DNS-Fälschungen kann man nur z.B. mit DNSSEC verhindern aber das ist eine andere langwierige Story.
  • Unterdrücken von STARTTLS
    Ein System, welches auf der Verbindung eingreifen kann, kann die Antwort auf die EHLO-Anfrage so ändern, dass der Absender gar nicht mit bekommt, dass die Gegenseite STARTTLS unterstützt. Er wird die Mail dann auch unterschlüsselt senden
  • Opportunistisches TLS und falsches Zertifikat
    Die meisten Mailserver nutzen schon STARTTLS aber versäumen es dabei das Zertifikat zu verifizieren. Sehr viele Server haben gar kein "öffentliches" Zertifikat und selbst wenn, muss es nicht mit dem Namen des Mailservers übereinstimmen. Hier ist viel Unsicherheit zu finden aber Mailserver nutzen dennoch STARTTLS. Besser eine Mail ist auf dem Teilstück vielleicht unsicher verschlüsselt als gar nicht verschlüsselt. Aber sicher ist das nicht

Es sind noch weitere fortschrittlichere Angriffsszenarien denkbar aber belassen wir es dabei.

Funktionsweise

Die Idee hinter MTA_STS basierte ist nun wieder, dass ein Empfängersystem sicher veröffentlicht, dass es auf jeden Fall Mails per STARTTLS mit einem bestimmten Zertifikaten annimmt. Wenn der Empfänger diese Informationen so veröffentlicht, dass ein Absender diese auslesen und verifizieren kann, kann er bei einer Verbindung zum Mailserver sicherstellt, dass keiner sich dazwischen geschaltet hat.

Hinweis:
Der DNS-Eintrag lautet nicht mehr auf "_smtp_sts" sondern "_mta_sts".

So ein Verfahren gibt es schon unter dem Begriff DANE - DNS-Based Authentication of Named Entities, bei dem ein Administrator diese Informationen samt Zertifikat im DNS hinterlegt. Voraussetzung ist dabei aber die Nutzung von DNSSEC, denn ansonsten könnte ein Angreifer über DNS-Manipulationen diese Informationen natürlich auch fälschen. DNSSEC ist aber bei weitem noch nicht überall verfügbar und viele Administratoren werden sich auch damit schwer tun, die Informationen im DNS einzutragen.

MTA_STS nutzt aber ebenfalls DNS und veröffentlicht hierüber eine Information, die dem Absender mitteilt, welche Policy für den Versand an diese Zieldomäne gelten soll. Die Gültigkeit der Policy muss natürlich verifiziert werden. DNSSEC ist eine Option aber wenn dies nicht möglich ist, dann ist z.B. HTTPS eine alternative. Dazu wird eine URL veröffentlicht. Dies ist aber nicht mit HSTS (HTTP Strict Transport Security) zu vergleichen, bei dem Ein Webserver innerhalb einer bereits verschlüsselten HTTPS-Verbindung über einen zusätzlichen Header den Browser anweist, zukünftig nur noch verschlüsselt mit diesem Host zu kommunizieren, was ein unbemerktes Downgrade einer Verbindung auf http verhindern soll.

Die Einträge in der DNS-Zone sind einfache TXT-Records, wie wir sie schon häufiger kennen. In dem ersten Entwurf war noch von "smtp_sts" als Prefix geschrieben wurde. In der Versoin 11, die zum Zeitpunkt dieses Artikels aktuell war, wird der String "_mta-sts" genutzt. Dieser findet sich auch bei den ein oder andere Domains. Sie veröffentlicht GMAIL.COM den folgenden Eintrag

C:\Users\fcarius>nslookup -q=TXT  _mta-sts.gmail.com
Server:  fritz.box
Address:  192.168.178.1

Nicht autorisierende Antwort:
_mta-sts.gmail.com      text =

        "v=STSv1; id=20160707T010757;"

Als Version wird aktuell nur STSv1 unterstützt und die ID ist ein beliebiger String, den Sie nur ändern müssen, wenn Sie eine neue Policy veröffentlicht haben. Ein Mailserver fragt diesen Wert und kann ihn gegen die Daten in seinem Cache prüfen, ob er eine neue Policy laden muss.

Wenn ihre Maildomäne bei einem Provider gehostet wird, dann ist auch ein CNAME erlaubt. So muss ich mich nicht um die Einträge kümmern.

_mta-sts.msxfaq.de.  IN CNAME _mta-sts.1und1.com.

Der Validator sollte dann einen HTTPS-Request auf den "Well-known" Name ausführen. Er muss natürlich prüfen, ob das vom Webserver gelieferte Zertifikat den Namen (Wildcard geht auch) enthält, der Gültigkeitsbereich stimmt und von einer vertrauenswürdigen CA ausgestellt ist. Ein Zugriff per HTTP muss nicht funktionieren und macht auch keinen Sin. Schließlich möchte ich ja sicherstellen., dass ich eine verschlüsselte und vor allem verifizierbare Verbindung per HTTPS zu einem Webserver mit einem "öffentlichen Zertifikat" erreiche. So sollte ich dann sicher sein, dass die erhaltene Information auch zutreffend ist. ein Sender darf bei einer Subdomains nicht die Policy einer darüber liegenden Domain abfragen.

https://mta-sts.<maildomain>/.well-known/mta-sts.txt"

Der WebServer liefert dann ein 200OK "Text/Plain"-Dokument aus, welches z.B. folgende Information enthält. Umleitungen (3xx) o.ä. sind  nicht erlaubt. Bei Google sieht das wie folgt aus:

Die Abfrage ist auch per PowerShell schnell ausgeführt:

PS C:\> (Invoke-WebRequest  "https://mta-sts.gmail.com/.well-known/mta-sts.txt").content
version: STSv1
mode: report
policy_id: 1503837332
mx: gmail-smtp-in.l.google.com
mx: .gmail-smtp-in.l.google.com
max_age: 86400

Die Einträge hinter dem "mx" sind die Namen der Mailserver, die in den Zertifikaten auftauchen. Damit der Absender aber überhaupt ein Zertifikat sieht, muss die Gegenseite natürlich STARTTLS unterstützen und der Absender auch STARTTLS anfordern und erzwingen. Der Mailserver muss dazu auch mindestens TLS 1.2 bereitstellen.

Schwäche

Die sicherlich größte Schwäche ist, dass die DNS-Abfrage nicht per DNSSEC gesichert und und nicht erzwungen werden kann. Wenn ich also Mails an ihre Domain mitlesen möchte, dann muss ich nur dafür sorgen, dass der absendende Server per DNS gar keine Antwort auf eine Anfrage nach einem TXT-Record "_mta-sts.<domain>" bekommt und der absendende Server noch keine Information darüber im Cache hat. Dann sieht er keinen Eintrag und erzwingt kein STARTTLS mit dem richtigen Zertifikat. Auch die anderen möglichen Angriffe sind in der RFC schön beschrieben.

Zwischenstand

Wenn MTA_STS wirklich eingeführt wird, dann wäre es eine Verbesserung aber keine Lösung denn:

  • Die Mailserver müssten es unterstützen
    Ich kenne aktuell noch keine Pläne bei Exchange aber auch nicht bei anderen Relays. Sicher hilft es den großen Anbietern wie MSN, GMX, Google, Outlook.com, über die Millionen private Konten gefahren werden und wenn Office 365 auch SMTP_STS unterstützt, dann haben mehr und mehr Firmen auch was davon. Aber dennoch gibt es noch viel viel mehr kleine Mailserver, Relays etc., die alle erst mal ertüchtigt werden müssten. Es wird also dauern
  • Keine Ende zu Ende-Verschlüsselung
    SMTP_STS zielt allein darauf ab die Verbindung zwischen zwei Mailservern zu härten, damit sich niemand anderes als Empfängerserver ausgeben kann. Auf dem Server selbst sind die Mails aber weiterhin unverschlüsselt

Wann wäre ja auch mal wichtig, welche Firmen schon einen entsprechenden "_mta_sts.example.com"-Record veröffentlicht haben. Ich hätte ja erwartet, dass zumindest die Autoren der Studie schon damit arbeiten. Also habe ich mal schnell ein paar NSLOOKUP-Anfragen gemacht:

nslookup -q=TXT _mta-sts.<domain>
Resolve-DnsName _mta-sts.gmx.com -Type TXT

Name                         Type   TTL   Section    Strings
----                         ----   ---   -------    -------
_mta-sts.gmx.com             TXT    86400 Answer     {v=STSv1;id=20180928194800Z;}

Die Ergebnisse sind überschaubar um nicht ernüchternd oder verheerend zu sagen. Selbst von den Domänen der Autoren selbst ist nur Google dabei und zwei weitere unvollständig. Als wenn Yahoo und web.de damals mitgemacht aber eine Umstellung des WebServers nicht überlebt hätte.

Eine Stichprobe vom Stand Oktober 2018.

Domain _mta_sts-Eintrag https-Antwort auf GET https://mta-sts.<hostname>/.well-known/mta-sts.txt

gmail.com

 

{v=STSv1; id=20171114T070707;}

 

(Invoke-WebRequest https://mta-sts.gmail.com/.well-known/mta-sts.txt).content
version: STSv1
mode: testing
mx: gmail-smtp-in.l.google.com
mx: *.gmail-smtp-in.l.google.com
max_age: 86400

Yahoo.com

 

"v=STSv1; id=20161109010200Z;"

 

(Invoke-WebRequest https://mta-sts.yahoo.com/.well-known/mta-sts.txt).content
version: STSv1
mode: testing
mx: *.am0.yahoodns.net
mx: *.mail.gm0.yahoodns.net
mx: *.mail.am0.yahoodns.net
max_age: 86400

gmx.com

 

{v=STSv1;id=20180928194800Z;}

 

(Invoke-WebRequest https://mta-sts.gmx.com/.well-known/mta-sts.txt).content
version: STSv1
mode: testing
mx: mx00.emig.gmx.net
mx: mx01.emig.gmx.net
max_age: 604800

gmx.net

 

{v=STSv1;id=20180928194800Z;}

 

(Invoke-WebRequest https://mta-sts.gmx.net/.well-known/mta-sts.txt).content
version: STSv1
mode: testing
mx: mx00.emig.gmx.net
mx: mx01.emig.gmx.net
max_age: 604800

gmx.de

Kein Eintrag

404 not found

web.de

 

"v=STSv1;id=20170124174800Z;"

 

PS C:\> (Invoke-WebRequest https://mta-sts.yahoo.com/.well-known/mta-sts.txt).content
version: STSv1
mode: testing
mx: *.am0.yahoodns.net
mx: *.mail.gm0.yahoodns.net
mx: *.mail.am0.yahoodns.net
max_age: 86400

mail.de

 

{v=STSv1; id=0000001;}

 

(Invoke-WebRequest https://mta-sts.mail.de/.well-known/mta-sts.txt).content
version: STSv1
mode: testing
mx: mx01.mail.de
mx: mx02.mail.de
max_age: 86400

comcast.com

Kein Eintrag

404 not found

microsoft.com

Kein Eintrag

404 not found

outlook.com

Kein Eintrag

404 not found

1und1.de

Kein Eintrag

404 not found

1and1.com

Kein Eintrag

404 not found

linkedin.com

Kein Eintrag

404 not found

Über den ersten Draft vom Mai 2016 hinaus hat nun zumindest auch Yahoo Einträge addiert. ist auch noch nichts weiter passiert. Ich habe den Eindruck, als wenn ein Tiger hier dann doch wieder als Bettvorleger landet. Allerdings wird auch an vielen Stellen geschrieben, dass diese Technik gar nicht für jeden und alle Firmen und Domänen gedacht ist sondern primär für die "Massenprovider" eine Absicherung bieten soll. Das macht es aber nicht besser.

Weitere Links