Kurz gesagt, MTA-STS ist ein Verfahren zur zusätzlichen Sicherung von E-Mails gegen Abfangen (d.h. Man-in-the-Middle-Angriffe) während der Übertragung zwischen Mail-Servern. Es adressiert teilweise ererbte architektonische Probleme der E-Mail-Protokolle und ist in dem relativ neuen Standard RFC 8461 beschrieben. Mail.ru war der erste große E-Mail-Dienst im russischen Internet, der diesen Standard implementiert hat. Weitere Details sind weiter unten zu finden.

Welche Probleme löst MTA-STS?

Historisch betrachtet übertrugen E-Mail-Protokolle (SMTP, POP3, IMAP) Informationen im Klartext, was es ermöglicht, diese während des Zugriffs auf die Verbindung abzufangen.

So sieht der Mechanismus der Zustellung einer E-Mail von einem Benutzer zu einem anderen aus:

Historisch war ein MitM-Angriff an allen Orten möglich, wo E-Mail unterwegs war.

Der RFC 8314 Standard verlangt den obligatorischen Einsatz von TLS zwischen dem Mail-Client (MUA) und dem Mail-Server. Wenn Ihr Server und die verwendeten E-Mail-Anwendungen RFC 8314 entsprechen, haben Sie (in erheblichem Maße) die Möglichkeit von Man-in-the-Middle-Angriffen zwischen Nutzern und Mail-Servern beseitigt.

Die Einhaltung allgemein anerkannter Praktiken (standardisierte RFC 8314) verhindert Angriffe in der Nähe des Nutzers:

Die Mail.ru-Server entsprechen der RFC 8314 bereits seit der Einführung des Standards; sie dokumentiert größtenteils bereits etablierte Praktiken, sodass wir nichts zusätzlich konfigurieren mussten. Sollte Ihr Mailserver jedoch weiterhin Nutzer über unsichere Protokolle zulassen, setzen Sie unbedingt die Empfehlungen dieses Standards um, da sehr wahrscheinlich mindestens ein Teil Ihrer Nutzer unverschlüsselt auf ihre E-Mails zugreift, selbst wenn Sie diese Verschlüsselung unterstützen.

Ein E-Mail-Client arbeitet stets mit demselben E-Mail-Server einer Organisation. Es ist möglich, alle Benutzer dazu zu zwingen, sich sicher zu verbinden, wodurch eine unsichere Verbindung technisch unmöglich wird (dies erfordert genau RFC 8314). Das ist manchmal kompliziert, aber machbar. Der Datenverkehr zwischen E-Mail-Servern ist noch komplexer. Die Server gehören verschiedenen Organisationen und werden häufig im Modus „einrichten und vergessen“ betrieben, was einen gleichzeitigen Wechsel zu einem sicheren Protokoll ohne Unterbrechung der Konnektivität unmöglich macht. Im SMTP-Protokoll gibt es seit langem die Erweiterung STARTTLS, die es Servern ermöglicht, die Verschlüsselung unterstützen, auf TLS zu wechseln. Ein Angreifer, der Einfluss auf den Verkehr hat, kann jedoch die Informationen über die Unterstützung dieses Befehls „heraus schneiden“ und die Server dazu zwingen, über das unverschlüsselte Textprotokoll zu kommunizieren (sogenannter Downgrade-Angriff). Aus diesem Grund wird bei STARTTLS in der Regel auch die Übereinstimmung des Zertifikats nicht überprüft (ein nicht vertrauenswürdiges Zertifikat kann vor passiven Angriffen schützen und ist nicht schlechter, als eine E-Mail im Klartext zu versenden). Daher schützt STARTTLS nur vor passivem Mithören.

MTA-STS reduziert teilweise das Risiko des Abfangens von E-Mails zwischen Mailservern, wenn der Angreifer die Möglichkeit hat, aktiv auf den Datenverkehr einzuwirken. Wenn die Domain des Empfängers eine MTA-STS-Richtlinie veröffentlicht und der Server des Absenders MTA-STS unterstützt, wird die E-Mail ausschließlich über eine TLS-Verbindung und nur an die Server gesendet, die in der Richtlinie definiert sind, und nur nach Überprüfung des Serverzertifikats.

Warum nur teilweise? MTA-STS funktioniert nur, wenn beide Seiten darauf geachtet haben, diesen Standard zu implementieren, und MTA-STS schützt nicht vor Szenarien, in denen der Angreifer die Möglichkeit hat, ein gültiges Domainzertifikat von einem der öffentlichen CA zu erhalten.

Wie funktioniert MTA-STS?

Empfänger

Konfiguriert die Unterstützung von STARTTLS mit einem gültigen Zertifikat auf dem Mailserver.
Veröffentlicht die MTA-STS-Richtlinie über HTTPS, wobei ein spezieller Domain mta-sts und ein spezifischer well-known Pfad verwendet wird, zum Beispiel https://mta-sts.mail.ru/.well-known/mta-sts.txt. Die Richtlinie enthält eine Liste von Mailservern (mx), die berechtigt sind, E-Mails für diese Domain zu empfangen.
Veröffentlicht einen speziellen TXT-Eintrag _mta-sts im DNS mit der Richtlinienversion. Wenn die Richtlinie geändert wird, muss dieser Eintrag aktualisiert werden (dies signalisiert dem Absender, dass die Richtlinie erneut angefordert werden muss). Zum Beispiel, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Absender

Der Absender fordert den DNS-Eintrag _mta-sts an und führt, wenn dieser vorhanden ist, eine Richtlinienanfrage über HTTPS durch (unter Überprüfung des Zertifikats). Die erhaltene Richtlinie wird im Cache gespeichert (für den Fall, dass ein Angreifer den Zugriff darauf blockiert oder den DNS-Eintrag manipuliert).

Beim Versenden von E-Mails wird überprüft, ob:

der Server, an den die E-Mail geliefert wird, in der Richtlinie enthalten ist;
der Server E-Mail unter Verwendung von TLS (STARTTLS) akzeptiert und ein gültiges Zertifikat hat.

Vorteile von MTA-STS

MTA-STS verwendet Technologien, die bereits in den meisten Organisationen implementiert sind (SMTP+STARTTLS, HTTPS, DNS). Für die Umsetzung auf der Empfängerseite ist keine spezielle Softwareunterstützung des Standards erforderlich.

Nachteile von MTA-STS

Es muss darauf geachtet werden, dass das Zertifikat des Web- und Mailservers gültig ist, die Namen übereinstimmen und rechtzeitig aktualisiert werden. Probleme mit dem Zertifikat führen dazu, dass E-Mails nicht zugestellt werden können.

Auf der Senderseite ist ein MTA erforderlich, der MTA-STS-Richtlinien unterstützt. Derzeit wird MTA-STS jedoch nicht „out of the box“ im MTA unterstützt.

MTA-STS verwendet eine Liste vertrauenswürdiger Stammzertifizierungsstellen (CAs).

MTA-STS schützt nicht vor Angriffen, bei denen der Angreifer ein gültiges Zertifikat verwendet. In vielen Fällen impliziert ein Man-in-the-Middle (MitM) Angriff in der Nähe des Servers die Möglichkeit, ein Zertifikat auszustellen. Ein solcher Angriff kann durch Certificate Transparency erkannt werden. Daher mildert MTA-STS insgesamt die Möglichkeit des Datenverkehrsabbaus, beseitigt sie jedoch nicht völlig.

Die letzten beiden Punkte machen MTA-STS weniger sicher als den konkurrierenden Standard DANE für SMTP (RFC 7672), aber technisch zuverlässiger, d. h. die Wahrscheinlichkeit, dass eine E-Mail aufgrund technischer Probleme im Zusammenhang mit der Einführung des Standards nicht zugestellt wird, ist für MTA-STS gering.

Der konkurrierende Standard ist DANE.

DANE nutzt DNSSEC zur Veröffentlichung von Zertifikatsinformationen und erfordert kein Vertrauen in externe Zertifizierungsstellen, was deutlich sicherer ist. Allerdings führt die Verwendung von DNSSEC tendenziell häufiger zu technischen Problemen, wenn man die Statistik der letzten Jahre betrachtet (obwohl die Zuverlässigkeit von DNSSEC und die technische Unterstützung insgesamt positive Fortschritte zeigen). Für die Implementierung von DANE in SMTP ist auf der Empfängerseite die Verfügbarkeit von DNSSEC für die DNS-Zone zwingend erforderlich, und für DANE ist eine korrekte Unterstützung von NSEC/NSEC3 von entscheidender Bedeutung, bei der es systemische Probleme in DNSSEC gibt.

Wenn DNSSEC fehlerhaft konfiguriert ist, kann dies zu Zustellausfällen führen, wenn die absendende Seite DANE unterstützt, selbst wenn die empfangende Seite davon nichts weiß. Daher bleibt die Verbreitung von DANE, obwohl es ein älterer und sichererer Standard ist, der bereits in einigen Server-Software auf der Absenderseite unterstützt wird, nach wie vor gering. Viele Organisationen sind nicht bereit, ihn aufgrund der Notwendigkeit der Implementierung von DNSSEC zu übernehmen, was die Einführung von DANE all die Jahre, in denen der Standard existiert, erheblich behindert hat.

DANE und MTA-STS stehen nicht im Widerspruch zueinander und können gemeinsam verwendet werden.

Wie sieht es mit der Unterstützung von MTA-STS in Mail.ru aus?

Mail.ru veröffentlicht bereits seit einiger Zeit die MTA-STS-Politik für alle wichtigen Domains. Momentan arbeiten wir an der Implementierung der Client-Seite des Standards. Zum Zeitpunkt des Verfassens dieses Artikels wird die Politik im nicht-blockierenden Modus angewendet (wenn die Zustellung durch die Politik blockiert wird, wird die Nachricht über einen „Ersatz“-Server ohne Anwendung der Richtlinien zugestellt). Danach wird der blockierende Modus schrittweise für einen kleinen Teil des ausgehenden SMTP-Traffics erzwungen, bis schließlich 100% des Traffics die Anwendung der Richtlinien unterstützt.

Wer unterstützt den Standard noch?

Derzeit veröffentlichen etwa 0,05% der aktiven Domains MTA-STS-Politiken, dennoch schützen sie bereits einen großen Teil des E-Mail-Traffics, da große Anbieter wie Google, Comcast und teilweise Verizon (AOL, Yahoo) den Standard unterstützen. Viele andere E-Mail-Dienste haben angekündigt, dass die Unterstützung des Standards in naher Zukunft realisiert wird.

Wie betrifft mich das?

Nein, wenn Ihre Domain keine MTA-STS-Policy veröffentlicht. Wenn Sie jedoch eine Policy veröffentlichen, sind die E-Mails der Benutzer Ihres Mailservers besser vor Abfangen geschützt.

Wie implementiere ich MTA-STS?

Unterstützung von MTA-STS auf der Empfängerseite

Es reicht aus, die Policy über HTTPS und DNS-Einträge zu veröffentlichen, ein gültiges Zertifikat von einer der vertrauenswürdigen CA (z. B. Let's Encrypt) für STARTTLS im MTA zu konfigurieren (STARTTLS wird von allen modernen MTAs unterstützt); spezielle Unterstützung durch den MTA ist nicht erforderlich.

Schritt für Schritt sieht das so aus:

Konfigurieren Sie STARTTLS in dem genutzten MTA (Postfix, Exim, Sendmail, Microsoft Exchange usw.).
Stellen Sie sicher, dass ein gültiges Zertifikat verwendet wird (von einer vertrauenswürdigen CA ausgestellt, nicht abgelaufen, der Subjektname des Zertifikats entspricht dem MX-Eintrag, über den die E-Mails für Ihre Domain zugestellt werden).
Konfigurieren Sie den TLS-RPT-Eintrag, über den Berichte zur Anwendung der Policies geliefert werden (durch Dienste, die das Senden von TLS-Berichten unterstützen). Beispiel für einen Eintrag (für die Domain example.com):
```
smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"
```
Dieser Eintrag weist E-Mail-Absender an, statistische Berichte über die Verwendung von TLS im SMTP an die Adresse zu senden tlsrpt@exmple.com.
Beobachten Sie die Berichte einige Tage lang, um sicherzustellen, dass keine Fehler vorliegen.
Veröffentlichen Sie die MTA-STS-Richtlinie über HTTPS. Die Richtlinie wird als Textdatei mit CRLF-Zeilenendungen am angegebenen Speicherort veröffentlicht.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Beispiel für eine Richtlinie:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Das Feld version enthält die Version der Richtlinie (derzeit ist das STSv1), mode legt den Anwendungsmodus der Richtlinie fest, testing — Testmodus (Richtlinie wird nicht angewendet), enforce — „Produktionsmodus“. Veröffentlichen Sie die Richtlinie zunächst im mode: testing. Wenn im Testmodus keine Probleme auftreten, können Sie nach einiger Zeit auf mode: enforce umschalten.
In mx wird eine Liste aller Mailserver angegeben, die E-Mails für Ihre Domain empfangen können (jeder Server muss mit einem Zertifikat konfiguriert sein, das mit dem Namen übereinstimmt, der in mx angegeben ist). Max_age legt die Cache-Dauer der Richtlinie fest (einmal gespeicherte Richtlinien werden auch dann angewendet, wenn ein Angreifer die Bereitstellung blockiert oder die DNS-Einträge während der Cachezeit beschädigt. Sie können das Bedürfnis signalisieren, die Richtlinie erneut anzufordern, indem Sie den mta-sts-DNS-Eintrag ändern).
Veröffentlichen Sie im DNS die TXT-Aufzeichnung:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Im Feld id kann eine beliebige Kennung (zum Beispiel ein Zeitstempel) verwendet werden; bei einer Änderung der Richtlinie muss sie sich ändern. Dies ermöglicht es den Absendern zu verstehen, dass die zwischengespeicherte Richtlinie erneut angefordert werden muss (wenn die Kennung von der zwischengespeicherten abweicht).

MTA-STS-Unterstützung auf der Senderseite

Aktuell ist die Situation schwierig, da der Standard neu ist.

Exim — es gibt keine eingebaute Unterstützung, aber ein externes Skript ist verfügbar. https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix — ebenfalls keine eingebaute Unterstützung, jedoch gibt es ein externes Skript, das auf Habr ausführlich beschrieben wird. https://habr.com/en/post/424961/

Als Nachwort zu „mandatory TLS“

In letzter Zeit achten die Regulierungsbehörden verstärkt auf die Sicherheit von E-Mails (was positiv ist). Zum Beispiel ist DMARC für alle staatlichen Einrichtungen in den USA verpflichtend und wird immer häufiger auch im Finanzwesen gefordert. In regulierten Bereichen liegt die Durchdringung des Standards bei 90%. Derzeit verlangen einige Regulierungsbehörden die Umsetzung von „mandatory TLS“ für bestimmte Domains, jedoch wird der Mechanismus zur Sicherstellung von „mandatory TLS“ nicht definiert, und in der Praxis wird diese Einstellung häufig auf eine Weise implementiert, die nicht einmal minimal vor realen Angriffen schützt, die bereits in Mechanismen wie DANE oder MTA-STS vorgesehen sind.

Wenn die Aufsichtsbehörde die Implementierung von 'mandatory TLS' für einzelne Domains verlangt, empfehlen wir, MTA-STS oder einen ähnlichen Mechanismus in Betracht zu ziehen, da er die Notwendigkeit eliminiert, für jede Domain separate Sicherheitskonfigurationen vorzunehmen. Sollten Sie Schwierigkeiten bei der Implementierung des Client-Teils von MTA-STS haben (da das Protokoll derzeit noch nicht weit verbreitet ist, ist das wahrscheinlich), könnte dieser Ansatz empfohlen werden:

Veröffentlichen Sie die MTA-STS-Richtlinie und/oder DANE-Einträge (DANE macht nur Sinn, wenn für Ihre Domain bereits DNSSEC aktiviert ist, wobei MTA-STS in jedem Fall erforderlich ist). Dies schützt den Datenverkehr in Ihre Richtung und entbindet Sie von der Notwendigkeit, andere E-Mail-Dienste zu bitten, mandatory TLS für Ihre Domain zu konfigurieren, sofern der E-Mail-Dienst MTA-STS und/oder DANE bereits unterstützt.
Für große E-Mail-Dienste implementieren Sie ein „Äquivalent“ zu MTA-STS über separate Transporteinstellungen für jede Domain, die den für das E-Mail-Relay verwendeten MX-Record festlegen und die obligatorische Überprüfung des TLS-Zertifikats verlangen. Wenn Domains bereits eine MTA-STS-Richtlinie veröffentlichen, sollte dies wahrscheinlich schmerzlos möglich sein. Die bloße Aktivierung von obligatorischem TLS für eine Domain ohne Festlegung des Relays und Zertifikatprüfung ist in Bezug auf Sicherheit ineffektiv und trägt nichts zu den vorhandenen STARTTLS-Mechanismen bei.

Quelle: habr.com