Kurz gesagt, MTA-STS ist eine Möglichkeit, E-Mails zusätzlich vor dem Abfangen (d. H. Angreifern in der Mitte, auch bekannt als MitM) zu schützen, wenn sie zwischen Mailservern übertragen werden. Es löst teilweise die ererbten Architekturprobleme von E-Mail-Protokollen und ist im relativ neuen RFC 8461-Standard beschrieben. Mail.ru Mail ist der erste große Postdienst im russischen Internet, der diesen Standard implementiert. Und im Detail ist es bereits unter dem Schnitt.

Welches Problem löst MTA-STS?

In der Vergangenheit haben E-Mail-Protokolle (SMTP, POP3, IMAP) Informationen im Klartext übertragen, sodass sie beispielsweise beim Zugriff auf einen Kommunikationskanal abgefangen werden können.



Wie der Mechanismus für die Zustellung eines Briefes von einem Benutzer an einen anderen aussieht: In







der Vergangenheit war der MitM-Angriff an allen Orten möglich, an denen E-Mails verschickt werden.



RFC 8314 erfordert die obligatorische Verwendung von TLS zwischen dem Mail-Programm (MUA) des Benutzers und dem Mail-Server. Wenn Ihr Server und die von Ihnen verwendeten Mail-Anwendungen RFC 8314-kompatibel sind, haben Sie die Möglichkeit von Man-in-the-Middle-Angriffen zwischen dem Benutzer und den Mail-Servern (weitgehend) ausgeschlossen.



Die Einhaltung gängiger Praktiken (standardisiert durch RFC 8314) eliminiert benutzernahe Angriffe:







Mail.ru-Mailserver entsprachen RFC 8314, noch bevor der Standard übernommen wurde. Tatsächlich werden lediglich die bereits akzeptierten Praktiken erfasst, und wir mussten nichts weiter konfigurieren. Wenn Ihr Mailserver jedoch weiterhin Benutzer über unsichere Protokolle zulässt, müssen Sie die Empfehlungen dieses Standards implementieren, da Höchstwahrscheinlich arbeiten zumindest einige Ihrer Benutzer mit E-Mails ohne Verschlüsselung, auch wenn Sie dies unterstützen.



Der Mail-Client arbeitet immer mit demselben Mail-Server derselben Organisation. Sie können alle Benutzer dazu zwingen, eine sichere Verbindung herzustellen, und es dann technisch unmöglich machen, eine unsichere Verbindung herzustellen (genau dies erfordert RFC 8314). Es ist manchmal schwierig, aber realisierbar. Der Verkehr zwischen Mailservern ist noch komplizierter. Die Server gehören verschiedenen Organisationen an und werden häufig in einem "Set and Forget" -Modus verwendet, der es unmöglich macht, sofort zu einem sicheren Protokoll zu wechseln, ohne die Konnektivität zu unterbrechen. SMTP bietet seit langem die STARTTLS-Erweiterung an, mit der Server, die die Verschlüsselung unterstützen, zu TLS wechseln können. Aber ein Angreifer, der die Fähigkeit hat, den Verkehr zu beeinflussenkann Informationen über die Unterstützung dieses Befehls "abschneiden" und die Server zur Kommunikation mit einem Nur-Text-Protokoll zwingen (dem sogenannten Downgrade-Angriff - einem Angriff zum Downgrade der Protokollversion). Aus dem gleichen Grund wird bei STARTTLS die Zertifikatskonformität normalerweise nicht überprüft (ein nicht vertrauenswürdiges Zertifikat kann vor passiven Angriffen schützen, und dies ist nicht schlimmer als das Senden einer E-Mail im Klartext). Daher schützt STARTTLS nur vor passivem Abhören.



MTA-STS beseitigt teilweise das Problem des Abfangens von Nachrichten zwischen Mailservern, wenn ein Angreifer den Datenverkehr aktiv beeinflussen kann. Wenn die Domäne des Empfängers die MTA-STS-Richtlinie veröffentlicht und der Server des Absenders das MTA-STS unterstützt, wird die E-Mail nur über eine TLS-Verbindung gesendet, nur an die in der Richtlinie definierten Server und nur mit überprüftem Serverzertifikat.



Warum teilweise? MTA-STS funktioniert nur, wenn beide Parteien 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 Domänenzertifikat in einer der öffentlichen Zertifizierungsstellen zu erhalten.

Wie MTA-STS funktioniert

Empfänger

1. Konfiguriert die Unterstützung für STARTTLS mit einem gültigen Zertifikat auf dem Mailserver. 
2. Veröffentlicht die MTA-STS-Richtlinie über HTTPS, eine spezielle mta-sts-Domäne und ein spezieller bekannter Pfad werden beispielsweise zum Veröffentlichen verwendet https://mta-sts.mail.ru/.well-known/mta-sts.txt. Die Richtlinie enthält eine Liste von Mailservern (mx), die das Recht haben, E-Mails für diese Domain zu empfangen.
3. Veröffentlicht einen speziellen _mta-sts TXT-Eintrag in DNS mit der Richtlinienversion. Wenn sich die Richtlinie ändert, muss dieser Datensatz aktualisiert werden (dies signalisiert dem Absender, die Richtlinie erneut anzufordern). Zum Beispiel,_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Absender Der



Absender fordert den DNS-Eintrag _mta-sts an, sofern verfügbar, und sendet eine Richtlinienanforderung über HTTPS (Überprüfung des Zertifikats). Die resultierende Richtlinie wird zwischengespeichert (falls ein Angreifer den Zugriff darauf blockiert oder den DNS-Eintrag ändert).



Beim Senden von E-Mails wird Folgendes überprüft:

• Der Server, an den die E-Mail gesendet wird, befindet sich in der Richtlinie.
• Der Server akzeptiert E-Mails mit TLS (STARTTLS) und verfügt über ein gültiges Zertifikat.

Vorteile von MTA-STS

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

Nachteile von MTA-STS

Es ist erforderlich, die Gültigkeit des Web- und Mailserver-Zertifikats, die Übereinstimmung der Namen und die rechtzeitige Erneuerung zu überwachen. Probleme mit dem Zertifikat machen die Zustellung von E-Mails unmöglich.



Auf der Absenderseite ist ein MTA mit Unterstützung für MTA-STS-Richtlinien erforderlich. Derzeit wird MTA-STS im MTA nicht unterstützt.



MTA-STS verwendet eine Liste vertrauenswürdiger Stammzertifizierungsstellen.



MTA-STS schützt nicht vor Angriffen, bei denen der Angreifer ein gültiges Zertifikat verwendet. In den meisten Fällen impliziert MitM in der Nähe des Servers die Möglichkeit, ein Zertifikat auszustellen. Ein solcher Angriff kann durch Zertifikatstransparenz erkannt werden. Daher verringert MTA-STS im Allgemeinen die Möglichkeit des Abfangens von Verkehr, schließt ihn jedoch nicht vollständig aus.



Die letzten beiden Punkte machen den MTA-STS weniger sicher als den konkurrierenden DANE-Standard für SMTP (RFC 7672), aber technisch sicherer, d. H. Für MTA-STS besteht eine geringe Wahrscheinlichkeit, dass der Brief aufgrund technischer Probleme, die durch die Implementierung des Standards verursacht werden, nicht zugestellt wird.

Konkurrierender Standard - DANE

DANE verwendet DNSSEC zum Veröffentlichen von Zertifikatinformationen und erfordert kein Vertrauen in externe Zertifizierungsstellen, was viel sicherer ist. Die Verwendung von DNSSEC führt jedoch mit deutlich höherer Wahrscheinlichkeit zu technischen Fehlern, wenn wir uns auf Statistiken für mehrere Jahre der Nutzung stützen (obwohl sich die Zuverlässigkeit von DNSSEC und dessen technischem Support im Allgemeinen positiv entwickelt). Um DANE in SMTP auf der Empfängerseite zu implementieren, ist das Vorhandensein von DNSSEC für die DNS-Zone obligatorisch. Für DANE ist die korrekte Unterstützung von NSEC / NSEC3 unerlässlich, bei der DNSSEC systemische Probleme hat.



Wenn DNSSEC mit Fehlern konfiguriert ist, kann dies zu einer Verweigerung der E-Mail-Zustellung führen, wenn die sendende Seite DANE unterstützt, auch wenn die empfangende Seite nichts darüber weiß. Trotz der Tatsache, dass DANE ein älterer und sicherer Standard ist und bereits in einigen Serversoftware auf der Seite des Absenders unterstützt wird, bleibt seine Durchdringung unbedeutend. Viele Organisationen sind aufgrund der Notwendigkeit, DNSSEC zu implementieren, nicht bereit, dies zu implementieren. Dies hat die Implementierung von DANE erheblich verlangsamt all die Jahre, in denen der Standard existiert hat.



DANE und MTA-STS stehen nicht in Konflikt miteinander und können zusammen verwendet werden.

Was ist mit MTA-STS-Unterstützung in Mail.ru Mail

Mail.ru veröffentlicht seit einiger Zeit die MTA-STS-Richtlinie für alle wichtigen Domänen. Wir implementieren derzeit die Client-Seite des Standards. Zum Zeitpunkt dieses Schreibens werden die Richtlinien in einem nicht blockierenden Modus angewendet (wenn die Zustellung durch eine Richtlinie blockiert wird, wird der Brief über einen "Sicherungs" -Server zugestellt, ohne dass Richtlinien angewendet werden), und der Blockierungsmodus wird für einen kleinen Teil des ausgehenden SMTP-Verkehrs schrittweise für 100% des Datenverkehrs erzwungen Die Durchsetzung von Richtlinien wird unterstützt.

Wer unterstützt den Standard noch?

Bisher veröffentlichen die MTA-STS-Richtlinien etwa 0,05% der aktiven Domänen, schützen jedoch bereits ein großes Volumen des E-Mail-Verkehrs, weil Der Standard wird von Hauptakteuren unterstützt - Google, Comcast und teilweise Verizon (AOL, Yahoo). Viele andere Postdienste haben angekündigt, dass die Unterstützung für den Standard in naher Zukunft implementiert wird.

Wie wird sich das auf mich auswirken?

Nichts, wenn Ihre Domain die MTA-STS-Richtlinie nicht veröffentlicht. Wenn Sie die Richtlinie veröffentlichen, sind Nachrichten an Ihre Mailserverbenutzer besser vor dem Abfangen geschützt.

Wie implementiere ich MTA-STS?

MTA-STS-Unterstützung auf Empfängerseite



Es reicht aus, die Richtlinie über HTTPS und Einträge in DNS zu veröffentlichen und ein gültiges Zertifikat von einer der vertrauenswürdigen Zertifizierungsstellen (Verschlüsseln) für STARTTLS in MTA zu konfigurieren (STARTTLS wird in allen modernen MTAs unterstützt). Eine spezielle Unterstützung durch den MTA ist nicht erforderlich ...



Schritt für Schritt sieht es so aus:

1. Konfigurieren Sie STARTTLS in dem von Ihnen verwendeten MTA (Postfix, Exim, Sendmail, Microsoft Exchange usw.).
2. , ( CA, , MX-, ).
3. TLS-RPT , ( TLS). ( example.com):
   
   
   
   

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:tlsrpt@example.com»

   
   
   TLS SMTP tlsrpt@exmple.com.
   
   
   
   , .
4. MTA-STS HTTPS. CRLF .
   
   
   
   

   https://mta-sts.example.com/.well-known/mta-sts.txt
   

   
   
   :
   
   
   
   

   version: STSv1
   mode: enforce
   mx: mxs.mail.ru
   mx: emx.mail.ru
   mx: mx2.corp.mail.ru
   max_age: 86400
   

   
   
   version ( STSv1), Mode , testing — ( ), enforce — «» . mode: testing, , mode: enforce.
   
   
   
   mx , ( , mx). Max_age ( DNS- , mta-sts DNS).
5. Veröffentlichen Sie den TXT-Eintrag in DNS: 
   
   
   
   

   _mta-sts.example.com. TXT “v=STSv1; id=someid;”
   

   
   
   Im ID-Feld können Sie einen beliebigen Bezeichner (z. B. einen Zeitstempel) verwenden. Wenn Sie die Richtlinie ändern, sollte sich dieser ändern. Dadurch können Absender verstehen, dass sie die zwischengespeicherte Richtlinie erneut anfordern müssen (wenn sich der Bezeichner von dem zwischengespeicherten unterscheidet).

Unterstützung für MTA-STS beim Absender



Während es schlecht ist, weil Der Standard ist frisch.

• Exim - keine integrierte Unterstützung, es gibt ein Skript eines Drittanbieters https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix - Es gibt keine integrierte Unterstützung. Es gibt ein Skript eines Drittanbieters, das unter Habré https://habr.com/en/post/424961/ ausführlich beschrieben wird.

Als Nachwort zu "obligatorischem TLS"

Die Aufsichtsbehörden haben sich in letzter Zeit auf die E-Mail-Sicherheit konzentriert (und das ist gut so). Beispielsweise ist DMARC für alle Regierungsbehörden in den USA obligatorisch und wird im Finanzsektor zunehmend benötigt. In regulierten Bereichen erreicht die Durchdringung des Standards 90%. Jetzt verlangen einige Regulierungsbehörden die Implementierung von "obligatorischem TLS" mit separaten Domänen, aber der Mechanismus zur Gewährleistung von "obligatorischem TLS" ist nicht definiert, und in der Praxis wird diese Einstellung häufig so implementiert, dass sie nicht einmal minimal vor echten Angriffen schützt, die bereits in Mechanismen wie vorgesehen sind DANE oder MTA-STS.



Wenn die Regulierungsbehörde die Implementierung von "obligatorischem TLS" mit separaten Domänen erfordert, empfehlen wir, MTA-STS oder dessen Teiläquivalent als den am besten geeigneten Mechanismus zu betrachten, sodass keine sicheren Einstellungen für jede Domäne separat vorgenommen werden müssen. Wenn Sie Probleme mit der Implementierung der Client-Seite von MTA-STS haben (bis das Protokoll breite Unterstützung erhalten hat, wird dies höchstwahrscheinlich der Fall sein), können Sie diesen Ansatz empfehlen:

1. Veröffentlichen Sie die MTA-STS-Richtlinie und / oder DANE-Einträge (es ist sinnvoll, DANE nur hinzuzufügen, wenn DNSSEC bereits für Ihre Domain und in jedem Fall für MTA-STS aktiviert ist). Dadurch wird der Datenverkehr in Ihre Richtung geschützt und es ist nicht mehr erforderlich, andere Mail-Dienste zur Konfiguration des obligatorischen TLS aufzufordern für Ihre Domain, wenn der Postdienst bereits MTA-STS und / oder DANE unterstützt.
2. «» MTA-STS , MX TLS-. MTA-STS, , , . TLS STARTTLS.