つまり、MTA-STS は、メール サーバー間で送信される電子メールを傍受 (つまり、中間者攻撃、別名 MitM) からさらに保護する方法です。 これは、電子メール プロトコルの従来のアーキテクチャ上の問題を部分的に解決し、比較的最近の標準 RFC 8461 で説明されています。Mail.ru は、この標準を実装した RuNet 上の最初の主要なメール サービスです。 そしてそれはカットの下でより詳細に説明されています。

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

歴史的に、電子メール プロトコル (SMTP、POP3、IMAP) は情報をクリア テキストで送信するため、通信チャネルにアクセスする場合などに情報を傍受することが可能でした。

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

歴史的に、MitM 攻撃はメールが流通するあらゆる場所で可能でした。

RFC 8314 では、メール ユーザー アプリケーション (MUA) とメール サーバーの間で TLS を使用することが要求されています。 使用するサーバーとメール アプリケーションが RFC 8314 に準拠していれば、ユーザーとメール サーバー間の中間者攻撃の可能性が (ほぼ) 排除されます。

一般に受け入れられている慣行 (RFC 8314 で標準化) に従うと、ユーザーの近くでの攻撃が排除されます。

Mail.ru メール サーバーは、標準が採用される前から RFC 8314 に準拠していました。実際、RFC XNUMX は既に受け入れられている慣行を単に取り込んでいるだけであり、追加の設定は何も必要ありませんでした。 ただし、メール サーバーが依然として安全でないプロトコルの使用をユーザーに許可している場合は、必ずこの標準の推奨事項を実装してください。 おそらく、たとえ暗号化をサポートしていても、少なくとも一部のユーザーは暗号化なしでメールを扱っているでしょう。

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

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

なぜ部分的に？ MTA-STS は、双方がこの標準の実装に注意を払った場合にのみ機能します。MTA-STS は、攻撃者がパブリック CA の XNUMX つから有効なドメイン証明書を取得できるシナリオに対しては保護しません。

MTA-STS の仕組み

Получатель

1. メール サーバー上の有効な証明書を使用して STARTTLS サポートを構成します。 
2. HTTPS 経由で MTA-STS ポリシーを公開します。公開には、特別な mta-sts ドメインと特別な既知のパスが使用されます。たとえば、 https://mta-sts.mail.ru/.well-known/mta-sts.txt。 ポリシーには、このドメインのメールを受信する権利を持つメール サーバー (mx) のリストが含まれています。
3. 特別な TXT レコード _mta-sts をポリシー バージョンとともに 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 はトラフィック傍受の可能性を軽減しますが、完全に排除するわけではありません。

最後の 7672 つの点により、MTA-STS は競合する SMTP の DANE 標準 (RFC XNUMX) よりも安全性が低くなりますが、技術的には信頼性が高くなります。 MTA-STS の場合、標準の実装によって引き起こされる技術的な問題によりレターが配信されない可能性は低いです。

競合規格 - DANE

DANE は DNSSEC を使用して証明書情報を公開し、外部の認証局を信頼する必要がないため、より安全です。 しかし、数年間の使用に関する統計に基づくと、DNSSEC の使用は技術的な障害につながることが非常に多くなっています (ただし、DNSSEC とその技術サポートの信頼性には一般的に良い傾向があります)。 受信側の SMTP に DANE を実装するには、DNSSEC の存在が必須であり、DNSSEC にはシステム上の問題がある DANE には NSEC/NSEC3 の適切なサポートが不可欠です。

DNSSEC が正しく構成されていない場合、送信側が DANE をサポートしていれば、受信側が DANE について何も知らなくても、メール配信が失敗する可能性があります。 したがって、DANE はより古く、より安全な標準であり、送信側の一部のサーバー ソフトウェアですでにサポートされているにもかかわらず、実際にはその普及率はまだわずかであり、DNSSEC を実装する必要があるため、多くの組織が DANE を実装する準備ができていません。このため、DANE 規格が存在してから何年もの間、DANE の実装が大幅に遅れてきました。

DANE と MTA-STS は相互に競合しないため、併用できます。

Mail.ru Mail の 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 の XNUMX つから有効な証明書を構成するだけで十分です (暗号化しましょう) (STARTTLS は最新のすべての MTA でサポートされています)。 MTAは必須です。

段階的に、次のようになります。

1. 使用している MTA (postfix、exim、sendmail、Microsoft Exchange など) で STARTTLS を構成します。
2. 有効な証明書 (信頼できる CA によって発行され、有効期限が切れていないこと、証明書の件名がドメインにメールを配信する MX レコードと一致すること) を使用していることを確認してください。
3. (TLS レポートの送信をサポートするサービスによって) ポリシー アプリケーション レポートが配信される TLS-RPT レコードを構成します。 エントリの例 (example.com ドメインの場合):

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»

   このエントリは、SMTP での TLS 使用状況に関する統計レポートをメール送信者に送信するように指示します。 [email protected].

   レポートを数日間監視して、エラーがないことを確認します。

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
   

   バージョン フィールドには、ポリシーのバージョンが含まれます (現在、 STSv1)、モードはポリシー適用モード、テスト - テスト モード (ポリシーは適用されません)、強制 - 「戦闘」モードを設定します。 最初にモード: testing でポリシーを公開します。テスト モードでポリシーに問題がない場合は、しばらくしてからモード: enforce に切り替えることができます。

   mx では、ドメインのメールを受け入れることができるすべてのメール サーバーのリストが指定されます (各サーバーには、mx で指定された名前と一致する証明書が構成されている必要があります)。 Max_age は、ポリシーのキャッシュ時間を指定します (キャッシュ時間中に攻撃者がその配信をブロックしたり、DNS レコードを破損したりしても、記憶されたポリシーが適用されるようになります)。mta-sts DNS を変更することで、ポリシーを再度要求する必要があることを通知できます。記録）。

5. TXT レコードを DNS に公開します。 

   _mta-sts.example.com. TXT “v=STS1; 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 のクライアント部分の実装が難しい場合 (プロトコルが広くサポートされるまでは、おそらくそうなるでしょう)、次のアプローチをお勧めします。

1. MTA-STS ポリシーや DANE レコードを公開します (DANE は DNSSEC がドメインですでに有効になっている場合にのみ意味があり、どのような場合でも MTA-STS が有効です)。これにより、自分の方向のトラフィックが保護され、他のメール サービスに問い合わせる必要がなくなります。メール サービスがすでに MTA-STS や DANE をサポートしている場合、ドメインに必須の TLS を構成します。
2. 大規模な電子メール サービスの場合は、ドメインごとに個別のトランスポート設定を通じて MTA-STS の「類似物」を実装します。これにより、メール中継に使用される MX が修正され、その TLS 証明書の検証が必須になります。 ドメインがすでに MTA-STS ポリシーを公開している場合、これはおそらく問題なく実行できます。 リレーを修正して証明書を検証せずにドメインの必須 TLS を有効にするだけでは、セキュリティの観点からは効果がなく、既存の STARTTLS メカニズムには何も追加されません。

出所： habr.com