つまり、MTA-STSは、メールがメールサーバー間で転送されるときに、メールを傍受（つまり、MitMとしても知られる中間攻撃）からさらに保護する方法です。これは、電子メールプロトコルの継承されたアーキテクチャ上の問題を部分的に解決し、比較的最近のRFC 8461標準で説明されています。Mail.ruMailは、この標準を実装したロシアのインターネットで最初の主要な郵便サービスです。そして、より詳細には、それはすでにカットの下にあります。

MTA-STSはどのような問題を解決しますか？

これまで、電子メールプロトコル（SMTP、POP3、IMAP）は情報を平文で送信していたため、たとえば通信チャネルにアクセスするときに情報を傍受することができました。

あるユーザーから別のユーザーにレターを配信するメカニズムは次のようになります。これ

まで、MitM攻撃は、メールが送信されるすべての場所で可能でした。

RFC 8314では、ユーザーのメールプログラム（MUA）とメールサーバー間でTLSを強制的に使用する必要があります。サーバーと使用するメールアプリケーションがRFC8314に準拠している場合は、ユーザーとメールサーバー間のMan-in-the-Middle攻撃の可能性を（大幅に）排除できます。

一般的な慣行（RFC 8314で標準化）を順守することで、ユーザーに近い攻撃を排除します。

Mail.ruメールサーバーは、標準が採用される前からRFC 8314に準拠していました。実際、これはすでに受け入れられているプラクティスをキャプチャするだけであり、これ以上何も構成する必要はありませんでした。ただし、メールサーバーで安全でないプロトコルを介してユーザーを許可する場合は、必ずこの標準の推奨事項を実装してください。ほとんどの場合、サポートしている場合でも、少なくとも一部のユーザーは暗号化なしでメールを操作します。

メールクライアントは、常に同じ組織の同じメールサーバーで動作します。また、すべてのユーザーに安全な方法で接続するように強制し、安全でない接続を技術的に不可能にすることができます（これはまさにRFC 8314が要求するものです）。それは時々難しいですが、実現可能です。メールサーバー間のトラフィックはさらに複雑です。サーバーはさまざまな組織に属しており、「セットアンドフォーゲット」モードで使用されることがよくあります。これにより、接続を切断せずに一度に安全なプロトコルに切り替えることはできません。 SMTPは長い間STARTTLS拡張機能を提供してきました。これにより、暗号化をサポートするサーバーをTLSに切り替えることができます。しかし、トラフィックに影響を与える能力を持つ攻撃者このコマンドのサポートに関する情報を「カット」し、サーバーにプレーンテキストプロトコルを使用して通信させることができます（いわゆるダウングレード攻撃-プロトコルバージョンをダウングレードする攻撃）。同じ理由で、STARTTLSの場合、証明書のコンプライアンスは通常チェックされません（信頼できない証明書は受動的な攻撃から保護できます。これは、クリアテキストで電子メールを送信するよりも悪いことではありません）。したがって、STARTTLSは受動的な盗聴からのみ保護します。

MTA-STSは、攻撃者がトラフィックに積極的に影響を与えることができる場合に、メールサーバー間のメッセージを傍受する問題を部分的に排除します。受信者のドメインがMTA-STSポリシーを公開し、送信者のサーバーがMTA-STSをサポートしている場合、TLS接続を介してのみ、ポリシーで定義されたサーバーにのみ、サーバー証明書が検証された状態でのみ電子メールが送信されます。

なぜ部分的に？MTA-STSは、両方の当事者がこの標準の実装を処理した場合にのみ機能し、MTA-STSは、攻撃者がパブリックCAの1つで有効なドメイン証明書を取得する機会があるシナリオから保護しません。

MTA-STSのしくみ

受信者

メールサーバー上の有効な証明書を使用してSTARTTLSのサポートを構成します。
HTTPSを介してMTA-STSポリシーを公開しhttps://mta-sts.mail.ru/.well-known/mta-sts.txtます。たとえば、特別なmta-stsドメインと特別な既知のパスが公開に使用されます。ポリシーには、このドメインのメールを受信する権限を持つメールサーバー（mx）のリストが含まれています。
特別な_mta-stsTXTレコードをポリシーバージョンとともにDNSに公開します。ポリシーが変更された場合、このレコードを更新する必要があります（これにより、送信者にポリシーを再要求するように通知されます）。例えば、_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

送信

者送信者は、_mta-sts DNSレコードが利用可能な場合はそれを要求し、HTTPSを介してポリシー要求を行います（証明書の検証）。結果のポリシーはキャッシュされます（攻撃者がポリシーへのアクセスをブロックしたり、DNSレコードを変更した場合）。

メールを送信するとき、次のことがチェックされます。

メールの配信先のサーバーがポリシーに含まれています。
サーバーはTLS（STARTTLS）を使用してメールを受け入れ、有効な証明書を持っています。

MTA-STSの利点

MTA-STSは、ほとんどの組織ですでに実装されているテクノロジ（SMTP + STARTTLS、HTTPS、DNS）を使用します。受信者側での実装には、標準の特別なソフトウェアサポートは必要ありません。

MTA-STSのデメリット

Webおよびメールサーバー証明書の有効性、名前の対応、およびタイムリーな更新を監視する必要があります。証明書に問題があると、メールを配信できなくなります。

送信者側では、MTA-STSポリシーをサポートするMTAが必要ですが、現在、MTA-STSはMTAではサポートされていません。

MTA-STSは、信頼されたルートCAのリストを使用します。

MTA-STSは、攻撃者が有効な証明書を使用する攻撃から保護しません。ほとんどの場合、サーバーの近くのMitMは、証明書を発行する可能性を意味します。このような攻撃は、証明書の透明性を通じて検出できます。したがって、一般に、MTA-STSはトラフィックの傍受の可能性を軽減しますが、完全に排除するわけではありません。

最後の2つのポイントにより、MTA-STSは競合するSMTPのDANE標準（RFC 7672）よりも安全性が低くなりますが、技術的には安全性が高くなります。MTA-STSの場合、規格の実装に起因する技術的な問題により、レターが配信されない可能性は低いです。

競合する標準-DANE

DANEはDNSSECを使用して証明書情報を公開し、外部CAへの信頼を必要としないため、はるかに安全です。ただし、DNSSECの使用は、数年間の使用の統計に依存している場合、技術的な障害につながる可能性が大幅に高くなります（ただし、DNSSECとその技術サポートの信頼性には一般に前向きな傾向があります）。受信者側のSMTPにDANEを実装するには、DNSゾーンにDNSSECが存在することが必須であり、DANEの場合、DNSSECにシステム上の問題があるNSEC / NSEC3を正しくサポートすることが不可欠です。

DNSSECがエラーで構成されている場合、送信側がDANEをサポートしていれば、受信側がDANEについて何も知らなくても、メール配信の拒否につながる可能性があります。したがって、DANEはより古く、より安全な標準であり、送信者側の一部のサーバーソフトウェアですでにサポートされていますが、実際にはその浸透は重要ではなく、DNSSECを実装する必要があるため、多くの組織はそれを実装する準備ができていません。これにより、DANEの実装が大幅に遅くなりました。標準が存在していたすべてのそれらの年。

DANEとMTA-STSは互いに競合せず、一緒に使用できます。

Mail.ruMailのMTA-STSサポートとは

Mail.ruは、かなり前からすべての主要なドメインのMTA-STSポリシーを公開しています。現在、標準のクライアント側を実装しています。この記事の執筆時点では、ポリシーは非ブロッキングモードで適用され（配信がポリシーによってブロックされている場合、レターはポリシーを適用せずに「バックアップ」サーバーを介して配信されます）、ブロッキングモードは、発信SMTPトラフィックのごく一部に対して、徐々にトラフィックの100％に対して強制されます。ポリシーの適用がサポートされています。

他に誰が標準をサポートしていますか

これまでのところ、MTA-STSポリシーはアクティブドメインの約0.05％を公開していますが、それでも、大量のメールトラフィックをすでに保護しているためです。この規格は、Google、Comcast、および部分的にVerizon（AOL、Yahoo）などの主要なプレーヤーによってサポートされています。他の多くの郵便サービスは、標準のサポートが近い将来実装されることを発表しました。

これは私にどのように影響しますか？

ドメインがMTA-STSポリシーを公開していない場合は何もありません。ポリシーを公開すると、メールサーバーユーザーへのメッセージが傍受されないように保護されます。

MTA-STSを実装するにはどうすればよいですか？

受信者側でのMTA-STSサポート

HTTPSおよびDNSレコードを介してポリシーを公開し、MTAでSTARTTLSの信頼できるCAの1つから有効な証明書を構成（暗号化しましょう）するだけで十分です（STARTTLSはすべての最新のMTAでサポートされます）。MTAからの特別なサポートは必要ありません。 ..。

ステップバイステップで、次のようになります。

MTA（postfix、exim、sendmail、Microsoft Exchangeなど）でSTARTTLSを構成します。
, ( CA, , MX-, ).
TLS-RPT , ( TLS). ( example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:tlsrpt@example.com»
```
TLS SMTP tlsrpt@exmple.com.

, .
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).
TXTレコードをDNSに公開します。
```
_mta-sts.example.com. TXT “v=STSv1; id=someid;”
```
idフィールドでは、任意の識別子（タイムスタンプなど）を使用できます。ポリシーを変更すると、変更する必要があります。これにより、送信者は、キャッシュされたポリシーを再要求する必要があることを理解できます（識別子がキャッシュされたポリシーと異なる場合）。

送信者でのMTA-STSのサポート

悪いですが、標準は新鮮です。

Exim-組み込みのサポートはありません。サードパーティのスクリプトがありますhttps://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix-組み込みのサポートはありません。Habréhttps ： //habr.com/en/post/424961/で詳細に説明されているサードパーティのスクリプトがあります。

「必須TLS」のあとがきとして

規制当局は最近メールセキュリティに焦点を合わせています（そしてそれは良いことです）。たとえば、DMARCは米国のすべての政府機関に義務付けられており、金融セクターでますます必要とされています。規制区域では、規格の普及率は90％に達します。現在、一部の規制当局は、個別のドメインで「必須TLS」の実装を要求していますが、同時に、「必須TLS」を保証するメカニズムは定義されておらず、実際には、この設定は、次のようなメカニズムですでに提供されている実際の攻撃から最小限にさえ保護しない方法で実装されることがよくあります。 DANEまたはMTA-STS。

規制当局が個別のドメインで「必須TLS」の実装を要求する場合、MTA-STSまたはその部分的な同等物を最適なメカニズムとして検討することをお勧めします。これにより、ドメインごとに個別に安全な設定を行う必要がなくなります。MTA-STSのクライアント側の実装に問題がある場合（プロトコルが広くサポートされるまで、おそらくそうなるでしょう）、このアプローチをお勧めします。

MTA-STSポリシーやDANEレコードを公開します（ドメインでDNSSECがすでに有効になっている場合にのみDANEを追加し、いずれの場合もMTA-STSを追加するのが理にかなっています）。これにより、方向のトラフィックが保護され、他のメールサービスに必須のTLSを構成するように依頼する必要がなくなります。郵便サービスがすでにMTA-STSおよび/またはDANEをサポートしている場合は、ドメインに対して。
«» MTA-STS , MX TLS-. MTA-STS, , , . TLS STARTTLS.

Mail.ruメールは、テストモードでMTA-STSポリシーの適用を開始します