Kurz gesagt, MTA-STS ist eine Möglichkeit, E-Mails während der Übertragung zwischen Mailservern zusätzlich vor Abfangen (d. h. sogenannten Man-in-the-Middle-Angriffen) zu schützen. Es löst teilweise die architektonischen Probleme, die in den E-Mail-Protokollen verankert sind, und wird im relativ neuen Standard RFC 8461 beschrieben. Mail.ru ist der erste große E-Mail-Dienst im Runet, der diesen Standard implementiert hat. Mehr dazu erfahren Sie im Folgenden.

Welches Problem löst MTA-STS?

Historisch gesehen übertrugen die E-Mail-Protokolle (SMTP, POP3, IMAP) Informationen im offenen Format, was das Abfangen erleichtert, zum Beispiel beim Zugriff auf die Kommunikationsleitung.

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

Historisch gesehen war ein Man-in-the-Middle-Angriff an allen Stellen möglich, an denen E-Mails übermittelt werden.

Der Standard RFC 8314 verlangt die zwingende Verwendung von TLS zwischen dem E-Mail-Client (MUA) und dem Mailserver. Wenn Ihr Server und die verwendeten E-Mail-Anwendungen dem RFC 8314 entsprechen, haben Sie (in hohem Maße) die Möglichkeit von Man-in-the-Middle-Angriffen zwischen Benutzern und Mailservern beseitigt.

Die Einhaltung bewährter Praktiken (standardisierte RFC 8314) beseitigt Angriffe in der Nähe des Benutzers:

Die Mailserver von Mail.ru entsprachen dem RFC 8314 bereits vor der Annahme des Standards; tatsächlich dokumentiert dieser nur bereits etablierte Praktiken, und wir mussten nichts weiter konfigurieren. Wenn Ihr Mailserver jedoch weiterhin Benutzer über unsichere Protokolle zulässt, sollten Sie die Empfehlungen dieses Standards unbedingt umsetzen, da vermutlich zumindest ein Teil Ihrer Benutzer E-Mails ohne Verschlüsselung verwendet, selbst wenn Sie diese unterstützen.

Ein E-Mail-Client arbeitet immer mit demselben E-Mail-Server derselben Organisation. Man kann alle Benutzer zwingend dazu bringen, sich auf sichere Weise zu verbinden, und es dann technisch unmöglich machen, sich unsicher zu verbinden (das verlangt genau RFC 8314). Das ist manchmal schwierig, aber umsetzbar. Bei dem Datenverkehr zwischen E-Mail-Servern ist es noch komplizierter. Die Server gehören verschiedenen Organisationen und werden oft im „Plug-and-Forget“-Modus betrieben, was ein sofortiges Umschalten auf ein sicheres Protokoll ohne Unterbrechung der Verbindung unmöglich macht. Im SMTP-Protokoll gibt es seit geraumer Zeit die Erweiterung STARTTLS, die es Servern, die Verschlüsselung unterstützen, ermöglicht, auf TLS umzuschalten. Ein Angreifer, der Einfluss auf den Datenverkehr hat, kann jedoch Informationen über die Unterstützung dieses Befehls „heraus schneiden“ und die Server dazu zwingen, über ein normales Textprotokoll zu kommunizieren (sogenannter Downgrade-Angriff). Aus demselben Grund wird bei STARTTLS in der Regel die Übereinstimmung des Zertifikats nicht überprüft (ein nicht vertrauenswürdiges Zertifikat kann vor passiven Angriffen schützen, und das ist nicht schlechter, als eine Nachricht im Klartext zu senden). Daher schützt STARTTLS nur vor passivem Mithören.

MTA-STS behebt teilweise das Problem des Abfangens von E-Mails zwischen E-Mail-Servern, wenn ein Angreifer aktiv Einfluss auf den Datenverkehr nehmen kann. Wenn die Domain des Empfängers eine MTA-STS-Richtlinie veröffentlicht und der Absender-Server MTA-STS unterstützt, wird die E-Mail nur über eine TLS-Verbindung und nur an die Server gesendet, die in der Richtlinie festgelegt sind, und es erfolgt eine Überprüfung des Serverzertifikats.

Warum teilweise? MTA-STS funktioniert nur, wenn beide Seiten sich um die Implementierung dieses Standards gekümmert haben, und MTA-STS schützt nicht vor Szenarien, in denen ein Angreifer die Möglichkeit hat, ein gültiges Zertifikat für die Domain von einer der öffentlichen CA zu erhalten.

Wie funktioniert MTA-STS

Empfänger

Konfiguriert die Unterstützung von STARTTLS mit einem gültigen Zertifikat auf dem E-Mail-Server.
Veröffentlicht über HTTPS eine MTA-STS-Richtlinie; für die Veröffentlichung wird eine spezielle Domain mta-sts und ein spezieller well-known-Pfad, z. B. https://mta-sts.mail.ru/.well-known/mta-sts.txt. Die Richtlinie enthält eine Liste von E-Mail-Servern (mx), die berechtigt sind, E-Mails für diese Domain zu empfangen.
Veröffentlicht einen speziellen TXT-Datensatz _mta-sts im DNS mit der Richtlinienversion. Bei Änderung der Richtlinie muss dieser Datensatz aktualisiert werden (dies signalisiert dem Absender die Notwendigkeit, die Richtlinie erneut anzufordern). Zum Beispiel, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Absender

Der Absender fordert den DNS-Datensatz _mta-sts an. Bei Vorhandensein wird die Richtlinie über HTTPS abgerufen (unter Überprüfung des Zertifikats). Die erhaltene Richtlinie wird zwischengespeichert (für den Fall, dass ein Angreifer den Zugriff darauf blockiert oder den DNS-Datensatz manipuliert).

Beim Versand von E-Mails wird überprüft, dass:

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

Vorteile von MTA-STS

MTA-STS nutzt Technologien, die bereits in den meisten Organisationen implementiert sind (SMTP+STARTTLS, HTTPS, DNS). Für die Implementierung auf der Seite des Empfängers sind keine speziellen Softwareunterstützungen des Standards erforderlich.

Nachteile von MTA-STS

Es ist notwendig, die Gültigkeit des Zertifikats des Web- und Mailservers, die Übereinstimmung der Namen und die rechtzeitige Aktualisierung zu überwachen. Probleme mit dem Zertifikat führen dazu, dass die Zustellung von E-Mails unmöglich wird.

Auf der Seite des Absenders wird ein MTA mit Unterstützung für MTA-STS-Richtlinien benötigt. Derzeit wird MTA-STS in MTAs nicht "out of the box" unterstützt.

MTA-STS verwendet eine Liste vertrauenswürdiger Root-CA.

MTA-STS schützt nicht vor Angriffen, bei denen ein Angreifer ein gültiges Zertifikat verwendet. In den meisten Fällen impliziert ein MitM 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, beseitigt aber nicht vollständig die Möglichkeit des Datenverkehrs-Abfangs.

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. bei MTA-STS ist die Wahrscheinlichkeit, dass eine E-Mail aufgrund technischer Probleme, die durch die Implementierung des Standards verursacht werden, nicht zugestellt wird, gering.

Der konkurrierende Standard ist DANE

DANE verwendet DNSSEC, um Informationen über Zertifikate zu veröffentlichen, und erfordert kein Vertrauen in externe Zertifizierungsstellen, was viel sicherer ist. Die Verwendung von DNSSEC führt jedoch laut jahrelanger Statistik deutlich häufiger zu technischen Störungen (obwohl die Zuverlässigkeit von DNSSEC und die allgemeine technische Unterstützung positiv zu beobachten sind). Für die Implementierung von DANE im SMTP auf der Empfängerseite ist DNSSEC für die DNS-Zone zwingend erforderlich. Zudem ist eine korrekte Unterstützung von NSEC/NSEC3 für DANE entscheidend, bei der es in DNSSEC systematische Probleme gibt.

Wenn DNSSEC fehlerhaft konfiguriert ist, kann das zu Zustellverweigerungen führen, wenn die sendende Seite DANE unterstützt, selbst wenn die empfangende Seite nichts darüber weiß. Daher bleibt, obwohl DANE ein älterer und sicherer Standard ist und bereits in einigen Serveranwendungen auf der Senderseite unterstützt wird, seine tatsächliche Durchdringung gering; viele Organisationen sind aufgrund der Notwendigkeit der Implementierung von DNSSEC nicht bereit, DANE einzuführen. Dies hat die Einführung von DANE über all die Jahre, in denen der Standard existiert, erheblich verzögert.

DANE und MTA-STS stehen sich nicht im Weg und können gemeinsam verwendet werden.

Wie steht es um die Unterstützung von MTA-STS bei Mail.ru?

Mail.ru veröffentlicht seit geraumer Zeit eine MTA-STS-Politik für alle Hauptdomains. Derzeit arbeiten wir an der Implementierung des Clientteils des Standards. Zum Zeitpunkt der Erstellung dieses Artikels werden die Richtlinien im nicht blockierenden Modus angewendet (wenn die Zustellung durch die Politik blockiert wird, wird die E-Mail über einen "Backup"-Server ohne Anwendung der Politiken zugestellt). Später wird ein blockierender Modus für einen kleinen Teil des ausgehenden SMTP-Verkehrs erzwungen, wobei allmählich für 100 % des Verkehrs die Anwendung der Politiken unterstützt wird.

Wer unterstützt den Standard noch?

Bislang veröffentlichen etwa 0,05 % der aktiven Domains Politiken für MTA-STS, dennoch schützen sie bereits ein beträchtliches Volumen an E-Mail-Verkehr, da große Akteure wie Google, Comcast und teilweise Verizon (AOL, Yahoo) den Standard unterstützen. Viele andere E-Mail-Dienste haben erklärt, dass die Unterstützung des Standards in naher Zukunft realisiert wird.

Wie wird mich das betreffen?

Nein, wenn Ihre Domain keine MTA-STS-Richtlinie veröffentlicht. Wenn Sie eine Richtlinie veröffentlichen, werden E-Mails für die Benutzer Ihres Mailservers besser vor Abfangungen geschützt.

Wie implementiere ich MTA-STS?

Unterstützung für MTA-STS auf der Empfängerseite

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

Schritt für Schritt sieht das so aus:

Konfigurieren Sie STARTTLS in dem verwendeten MTA (Postfix, Exim, Sendmail, Microsoft Exchange usw.).
Stellen Sie sicher, dass ein gültiges Zertifikat verwendet wird (ausgestellt von einem vertrauenswürdigen CA, nicht abgelaufen, das Zertifikatssubjekt entspricht dem MX-Eintrag, über den E-Mails für Ihre Domain zugestellt werden).
Konfigurieren Sie einen TLS-RPT-Eintrag, über den Berichte zur Anwendung von Richtlinien zugestellt werden (von Diensten, die das Senden von TLS-Berichten unterstützen). Beispiel eines Eintrags (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 in SMTP an die Adresse zu senden tlsrpt@exmple.com.
Überwachen Sie die Berichte einige Tage und stellen Sie sicher, dass es keine Fehler gibt.
Veröffentlichen Sie die MTA-STS-Richtlinie über HTTPS. Die Richtlinie wird als Textdatei mit CRLF-Zeilenenden an folgender Stelle veröffentlicht.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Beispiel einer 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 Versionsnummer der Richtlinie (aktuell ist das STSv1), während der Modus den Anwendungsmodus der Richtlinie festlegt: testing — Testmodus (Richtlinie wird nicht angewendet), enforce — Produktionsmodus. Veröffentlichen Sie zunächst die Richtlinie mit mode: testing; wenn es im Testmodus keine Probleme mit der Richtlinie gibt, können Sie nach einiger Zeit auf mode: enforce umschalten.
In mx wird eine Liste aller Mailserver festgelegt, die E-Mails für Ihre Domain empfangen können (jeder Server muss ein Zertifikat haben, das mit dem in mx angegebenen Namen übereinstimmt). Max_age gibt die Cache-Dauer der Richtlinie an (eine einmal gespeicherte Richtlinie wird weiterhin angewendet, selbst wenn ein Angreifer ihre Bereitstellung blockiert oder die DNS-Einträge während der Cache-Zeit beschädigt. Es kann ein Zeichen gegeben werden, dass die Richtlinie erneut angefordert werden muss, indem der mta-sts DNS-Eintrag geändert wird).
Veröffentlichen Sie im DNS einen TXT-Eintrag:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Im Feld id kann eine beliebige Identifier (zum Beispiel ein Zeitstempel) verwendet werden. Bei einer Änderung der Richtlinie sollte er sich ändern, das ermöglicht es den Absendern zu verstehen, dass sie die zwischengespeicherte Richtlinie erneut anfordern müssen (wenn sich der Identifier von dem zwischengespeicherten unterscheidet).

Unterstützung von MTA-STS auf der Absenderseite

Derzeit ist die Unterstützung schlecht, da der Standard neu ist.

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

Als Nachsatz zu „mandatory TLS“

In letzter Zeit richten Regulierungsbehörden die Aufmerksamkeit auf die Sicherheit von E-Mails (und das ist gut). Zum Beispiel ist DMARC für alle staatlichen Einrichtungen in den USA verpflichtend und wird immer häufiger im Finanzsektor gefordert; in regulierten Bereichen erreicht die Durchdringung des Standards 90 %. Derzeit verlangen einige Regulierungsbehörden die Implementierung von „mandatory TLS“ mit separaten Domains, aber der Mechanismus zur Gewährleistung von „mandatory TLS“ wird nicht definiert, und in der Praxis wird diese Einstellung häufig auf eine Weise implementiert, die nicht einmal minimal gegen reale Angriffe schützt, die bereits in Mechanismen wie DANE oder MTA-STS vorgesehen sind.

Wenn die Regulierungsbehörde die Umsetzung von „mandatory TLS“ mit separaten Domains verlangt, empfehlen wir, MTA-STS oder eine Teilanaloge als den am besten geeigneten Mechanismus zu betrachten, da dies die Notwendigkeit eliminiert, sichere Einstellungen für jede Domain einzeln vorzunehmen. Wenn Sie Schwierigkeiten bei der Implementierung des Clientteils von MTA-STS haben (da das Protokoll derzeit noch nicht weitreichend unterstützt wird, werden sie höchstwahrscheinlich auftreten), kann 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, MTA-STS sollte in jedem Fall aktiviert sein), dies schützt den Verkehr zu Ihnen hin und erspart Ihnen die Notwendigkeit, andere E-Mail-Dienste zu bitten, „mandatory TLS“ für Ihre Domain zu konfigurieren, wenn der E-Mail-Dienst bereits MTA-STS und/oder DANE unterstützt.
Für große E-Mail-Dienste implementieren Sie ein "Analogon" von MTA-STS über separate Transporteinstellungen für jede Domain, die den für das Mail-Relaying verwendeten MX festlegen und eine obligatorische Überprüfung des TLS-Zertifikats erfordern. Wenn die Domains bereits eine MTA-STS-Richtlinie veröffentlichen, ist dies wahrscheinlich problemlos möglich. Die bloße Aktivierung von obligatorischem TLS für eine Domain ohne Festlegung des Relays und Überprüfung des Zertifikats ist aus Sicherheitsgründen ineffektiv und trägt nichts zu den vorhandenen STARTTLS-Mechanismen bei.

Quelle: habr.com