TLSRPT -  SMTP TLS Reporting

Mit dem DMARC Standard hat sich im Internet ein Weg etabliert, wie Missbrauch von Mail-Domains an die Besitzer der Domains gemeldet werden. Wenn ich als Inhaber meine Mailserver per SPF/SenderID veröffentliche und meine Mails idealerweise auch noch per DKIM signiere, dann können Empfänger dies überprüfen und Missbrauch nicht nur durch eine Ablehnung der Mail bestrafen sondern auch mir als Inhaber einen Report dazu übergeben. Mit TLSRPT gibt es nun eine weitere Funktion, um die Verwendung von STARTTLS zu überwachen und insbesondere mit MTA-STS (Strict Transport Security) nützlich ist.

STARTTLS im echten Leben

Die Verschlüsselung von SMTP-Verbindungen ist nicht nur aus Gründen der Datensicherheit wünschenswert, wenn bessere Verfahren wie SMIME/PGP nicht zum Einsatz kommen. STARTTLS erlaubt es beim Einsatz von Client Zertifikaten (MTLS) auch, dass der Sender sich ausweist. Es gibt daher vier Fälle:

Szenario Ergebnis

Empfänger bietet kein STARTTLS an

Der Sender kann keine TLS-Verbindung starten und damit auch kein eigenes Zertifikat vorweisen. Die Verbindung ist aber unverschlüsselt. Je nach Einstellung des Absender kann dieser die Übertragung abbrechen, wenn der Sender z.B. STARTTLS erzwingt.

Empfänger bietet STARTTLS an Client liefert kein Zertifikat

Der Sender kann per STARTTLS die Verschlüsselung starten und bekommt das Zertifikat des Ziels. Abhängig vom Zertifikat kann der Sender nun entscheiden, ob es die richtige Gegenstelle ist und er vorsetzt oder ob er unabhängig vom Ausgang der Verifikation weiter macht

Empfänger bietet STARTTLS an und fordert beliebiges Client-Zertifikat

Die Gegenstelle kann aber auch den Client anfordern, ein Zertifikat zu liefern. Beim TLS-Handshake kann er dazu eine Liste der "Trusted Root"-Certs senden. Damit kann der Empfänger zumindest bei "öffentlichen Zertifikaten" den einliefernden Mailserver identifizieren.

Empfänger bietet STARTTLS an und fordert bestimmtes Client-Zertifikat

Dies ist der sicherste Weg, bei dem der Empfänger auch den Absender verifiziert. Diese Verfahren sollte z.B. beim Exchange Hybrid Connector genutzt werden, um die Gegenstelle zu prüfen.

Was was wird davon nun per TLSRT erfasst?

Die richtige Richtung

Bei der Übertragung einer Mail sind immer zwei Systeme damit beschäftigt aber wenn es um "schlechte Mails" geht gibt es immer noch weitere Parteien:

  • Der legitime Absender
    Wenn ich z.B. als "carius.de" eine Mail an einen GMail -Empfänger sende, dann geht das über meinen Mailserver, die je nach Konfiguration sich per SPF über die IP-Adresse ausweist oder per DKIM-Signatur oder auch per MTLS-Zertifikat
  • Der legitime Empfänger
    Wenn der Absender sich korrekt am MX-Record orientiert, dann landet er beim richtige Ziel. Hier ist es schon deutlich kniffliger zwischen Richtig und Falsch zu bestimmen, denn DNS-Abfragen können verändert und IP-Adressen umgeroutet werden. Letztlich ist es ein Zertifikat beim STARTTLS, welches dem Absender besser Gewissheit geben kann, das richtige System erreicht zu haben.

Aber auch die bösen Jungs haben hier zwei Angriffsvektoren:

  • Spammer/Phishing
    Ein Angriff basiert darauf, dass jemand absichtlich mit einer "falschen Domain" sendet, um beim Empfänger einen gewissen Vertrauenslevel zu erhalten. Könnte der Empfänger beim Einsatz von STARTTLS samt Clientzertifikat auch den einliefernden Host qualifizieren und würde die Absenderdomain noch die entsprechenden Informationen zum Zertifikat bereitstellen, könne ein Spamfilter hier schnell zwischen Gültig und Ungültig unterscheiden
  • Umleitung/Abfangen
    Ein anderer Angriff ist kniffliger aber nicht unmöglich, So kann ein Mitspieler im Internet (DNS-Admin, Firewall, Provider etc), ob nun kriminell oder staatlich gefordert, die Verbindung anstatt auf den richtigen Server auf einen anderen umleiten um so die Mail entweder mit zu lesen oder sogar zu verändern.

Die Funktion TLSRPT sorgt nun dafür, dass der Absende-Server nicht nur die Mail an das Ziel sendet, sondern dass ich als Domaininhaber auch einen Report über den SMTP-Versand bekomme. Wenn Google eine Mail an meine Domain sendet, dann sendet Google später einen Report an die veröffentlichte Mailadresse. Natürlich muss Google dazu für die Zieldomains die DNS-Abfragen machen und niemand darf diese Abfrage verändern, was per DNS ohne DNSSEC nicht unmöglich ist. Ich kann also erkennen, wie gut meine Erreichbarkeit per STARTTLS ist, d.h. Konfigurationsfehler aber auch "Downgrade"-Veränderungen fallen vielleicht auf.

Der kompatible Sender einer Mail an eine Domain holt sich einen DNS-Eintrag um an den Admin des Empfängers einen Bericht zu senden.

Um Umkehrschluss bedeutet es aber, dass mein Versand zu anderen Diensten nicht berichtet wird. Wenn ich z.B. eine Mail zu Google sende und auf dem Weg jemand das STARTTLS-Angebot von Google unterdrückt, dann sendet mein Server unverschlüsselt aber ich bekomme keine Information darüber. Google kann ja nicht wissen, ob ich TLS könnte. Ich muss es ja annehmen. Hier müsste ich dann meinen eigenen Mailserver auf die Finger schauen, und die ausgehenden Verbindungen auswerten.

Praktische Anwendung

Am Beispiel von Net at Work beschreibe ich den Einsatzzweck. Zuerst muss der Inhaber der Domain einen DNS-Eintrag setzen. Das Ziel kann eine Mailadresse oder URL sein, über den die Rückmeldung erfolgt

C:\>nslookup -q=TXT _smtp._tls.netatwork.de

_smtp._tls.netatwork.de text =

"v=TLSRPTv1;rua=https://reporting.nospamproxy-staging.com/smtp-tls"

Alternativ auch eine Domain mit SMTP-Reporting

C:\>nslookup -q=TXT _smtp._tls.carius.de

_smtp._tls.carius.de    text =

        "v=TLSRPTv1;rua=mailto:tlsrptdemo@msxfaq.de"

Und nun kann jemand eine Mail an die Domain "netatwork.de" bzw. "carius.de2 senden. Der absendende Mailserver baut eine SMTP-Verbindung mit STARTTLS auf und meldet dann den Erfolg oder insbesondere Misserfolg an die Report-Adresse.

  • Der Absende-Server muss TLSPRT unterstützen
    Es ist seine Aufgabe für jede Ziel-Domäne den Eintrag abzufragen und den Report zu erstellen und zuzustellen
  • Kein Schutz gegen MX-Spoofing
    Es ist nur eine "Report-Funktion". Wenn Sie TLS erzwingen wollen, dann ist MTA-STS (Strict Transport Security) der Weg dies sicher zu stellen
  • Alarm bei "TLS-Enforce"
    Wenn ich als Empfänger z.B. SMTPTLS erzwingen und dies der Absender nicht kann, dann könnte er mir "Bescheid" geben, wenn der Sender TLSRPT unterstützt

Das Problem ist aktuell aber, dass es noch gar nicht so viele Mailserver gibt, die TLSRPT unterstützen.

TLSRPT Statistiken

Doch welche Informationen sendet der Absender mir über die SMTP/TLS-Verbindung? Wenn wir dann in der RFC stöbern, dann finden wir die verschiedenen Szenarien, die durch TLSRPT erfasst werden:

4.2. Delivery Summary
https://tools.ietf.org/html/rfc8460#section-4.2

Der Datensatz enthält den Zeitraum, über den der Bericht erfolgt und weist erst einmal aufsummierte Wert "total-successful-session-count" und "total-failure-session-count" aus. Im Idealfall sind alle Verbindungen "erfolgreich" und der Wert bei "total-failure-session-count" ist 0.

Zusätzlich kann der Absender auch noch ausführlichere Fehlermeldungen aufführen wie "

starttls-not-supported
certificate-host-mismatch
certificate-expired
certificate-not-trusted

Weiterhin kann der Absender noch spezifische Daten zu den DANE-Richtlinien  und MTA-STS-Richtlinien liefern.

DNS Einträge

Auch wenn aktuell nur ganz wenige Mailserver überhaupt TLSRPT unterstützen, müssen Sie auf ihrer Seite erst einmal nur einen DNS-Eintrag anlegen, damit Sie solche Reports erhalten. In der RFC 8460 ist die originale Beschreibung:

A domain publishes a record to its DNS indicating that it wishes to receive reports. These SMTP TLSRPT policies are distributed via DNS from the Policy Domain's zone as TXT records (similar to Domain-based Message Authentication, Reporting, and Conformance (DMARC) policies) under the name "_smtp._tls". For example, for the Policy Domain "example.com", the recipient's TLSRPT policy can be retrieved from "_smtp._tls.example.com".
Quelle: https://tools.ietf.org/html/rfc8460#section-3

Der TEXT-Record enthält dazu mehrere Einträge, die durch ein Semikolon ";" getrennt sind

  • v=TLSRPT
    Es gibt in einer Domain ja durchaus mehrere TXT-Records und damit kann der auswertende Code sicherstellen, dass er das Format versteht
  • rua
    Enthält die URL, an die der Bericht gesendet werden soll. Das kann eine Mailadresse sein. Anders als bei DMARC sind nun aber auch Webdienste möglich

Ich habe bei mir folgenden Eintrag gesetzt. Die "2" dürfen Sie wegnehmen aber man muss es Spammern ja nicht allzu einfach machen:

_smtp._tls.msxfaq.de. IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@msxfaq2.de"

Ich nutze hier lieber immer einen eigenen Mailalias mit Weiterleitung oder als Zusatzadrese und nicht meine persönliche Mailadresse. So kann ich die Mails einfacher weiter verarbeiten

Wenn Sie einen Webserver betreiben, können Sie dort natürlich auch eine Logik hinterlegen, um einen HTTPS-Post mit dem Report anzunehmen. Die URL ist dabei frei und der Server, der den Report zustellt, muss das Zertifikat nicht prüfen. In Zeiten von Let's Encrypt u.a. sollte es aber kein Problem sein, hier fehlerfrei zu arbeiten.

_smtp._tls.msxfaq.de. IN TXT "v=TLSRPTv1; \ rua=https://www.msxfaq.com/v1/tlsrpt"

Diesen Eintrag habe ich aber nicht gemacht, da ich keinen Webserver für die Annahme der Daten vorhalten will. Ich beschränke mich auf "Mail". Für Firmen kann es aber schon interessant sein, diese Reports quasi in "Echtzeit" auszuwerten und damit Fehler bei der TLS-Zustellung sofort zu erkennen.

Hinweis: Die URL kann HTTPS nutzen. Der Absender wird das Zertifikat aber nicht verifizieren.

Reports

Sie brauchen nun natürlich einen Empfänger, der nicht nur STARTTLS anbietet, sondern auch die Statistiken für ihre Domain über einen Tag hinweg sammelt und ihnen dann den Bericht zusendet. Die RFC schreibt dazu.

The report SHOULD cover a full day, from 00:00-24:00 UTC. This should allow for easier correlation of failure events. To avoid unintentionally overloading the system processing the reports, the reports should be delivered after some delay, perhaps several hours.
https://tools.ietf.org/html/rfc8460#section-4.1

Bislang bekomme ich von Google ab und an mal ein Report. Hier ein Beispiel:

{
   "organization-name":"Google Inc.",
   "date-range":{
      "start-datetime":"2020-11-22T00:00:00Z",
      "end-datetime":"2020-11-22T23:59:59Z"
   },
   "contact-info":"smtp-tls-reporting@google.com",
   "report-id":"2020-11-22T00:00:00Z_carius.de",
   "policies":[
      {
         "policy":{
            "policy-type":"no-policy-found",
            "policy-domain":"carius.de"
         },
         "summary":{
            "total-successful-session-count":5,
            "total-failure-session-count":1
         }
      }
   ]
}

So viel steht da nun gar nicht drin und vor allem keine Details, welche Übertragungen einen "failure-session-count" habe. Aber ich kenn sehen, welche Policies Google zu meiner Domain gezogen hat.

Weitere Links