電子メールサーバー間のSTARTTLSMITM（証明書のダウングレードと偽造）を軽減する方法は？

Question

私はこのサイトのほとんどの人ほど技術的に傾いていないので、それを覚えておいてください。メールのセキュリティについてもっと知りたいと思ったので、調査を行いましたが、すべてが私の理解に基づいているので、必要に応じて修正してください。クライアントとサーバー間の接続（MSA/MTA？）は暗号化できますが、サーバー間の暗号化（MTAからMTA？）は、STARTTLSをサポートする各サーバーによって異なります。 STARTTLSは、クライアントとサーバーの間に実装することもできます。

私が遭遇したSTARTTLSの唯一の弱点は、接続が暗号化を介して、またはプレーンテキストとして受け入れられるため、暗号化をプレーンテキストにダウングレードできるMITM攻撃はおそらく些細なことです。また、証明書が偽造されているという問題があることも理解していますが、それがMITMに直接関係しているかどうかはわかりません。

これはプロトコル自体ではなく、実装の問題であると読みました。私が遭遇したいくつかの解決策は、SSL/TLSを介して接続が発生しなかったときに通知するか、接続を完全に切断するようにクライアントを構成することでした。 STARTTLSを実装してMITMが不可能になるようにする適切な方法はありますか（それが理にかなっている場合は、MITMに反応するのではなく）、それはどこで行われますか？これらの修正は、サーバー間接続を対象としていますか、それともクライアントからサーバーへの接続のみを対象としていますか？また、偽の証明書の問題、その弱点がどのように発生する可能性があるか、実装またはその他の手段によってどのように対処するかについて、もう少し知りたいと思います。

サーバーからクライアントへの問題はそれほど問題ではなく、ほとんどのESPによってすでに処理されているように思われるため、私はサーバー間のセキュリティに主に関心があります。 STARTTLSに代わるより良い方法はありますか？私が述べたように、私はこれらすべてに不慣れであり、実装/構成の方法を含む、これらのほとんどに関する包括的な指示が必要になります。ここで誰もそれを提供できない場合は、学習リソースに関する限り、正しい方向のポイントをいただければ幸いです。

オンザサイド...実際の攻撃/エクスプロイトについても知りたいのですが、上記のMITM（サーバー間）の種類が特定の接続（宛先の電子メールアドレス？）を標的にできるものかどうか疑問に思いました。または、通りすがりの人に何が起こってもそれをつかむことに似ています。

Steffen Ullrich · Answer

電子メールを安全な方法で転送することにはいくつかの問題があり、この質問はsecurity.stackexchange.comでよりよく尋ねられるかもしれません。メールはさまざまな段階で傍受される可能性があります。

明示的TLS（STARTTLS）と暗黙的TLS（SMTPS）は、エンドツーエンドではなくホップバイホップのセキュリティを提供します。つまり、その間の各メールサーバーは暗号化されていないメールにアクセスできます。
メールのネクストホップは、DNSを介してMXレコードを検索することによって決定されます。 DNSSecが使用されていない限り、これはなりすましになる可能性がありますが、ほとんどの場合はそうではありません。スプーフィングされた場合、TLSハンドシェイク内の証明書を適切にチェックしても、間違ったMTAへの接続が正しいかどうかがチェックされるため役に立ちません。
MXは、ポート25、つまり明示的なTLS（STARTTLS）でサーバーを使用するようにのみ定義されています。送信MTAが受信MTAがSTARTTLSをサポートしているかどうかを知る方法がないため、EHLOコマンドへの応答でサポートされている拡張機能のリストを変更することにより、中間者攻撃者が接続をプレーンに減らすことができます。 STARTTLSコマンドを拒否する。また、接続を直接傍受する方法がないハッカーでも、TLSハンドシェイクの開始時にTCP RSTパケットを挿入できる可能性があるため、クライアントはTLSの使用に問題があると考えてフォールバックします。 TLSハンドシェイクには実際には十分な問題があるため、クライアントは疑わしくないかもしれません。
また、TLSハンドシェイク内では、適切な検証が行われないことがよくあります。証明書がまったくチェックされない場合もあれば、チェーンのみがチェックされる場合もありますが、ホスト名が一致する場合などはチェックされません。ただし、MXがすでにスプーフィングされている場合は、とにかく間違ったサーバーに対して検証が行われる可能性があります:(

つまり、少なくともホップバイホップの暗号化を十分に安全にするには、重要な修正を複数の場所に追加する必要があり、それらのほとんどは送信MTAを制御できません。

コメントからの質問の詳細を取得するには：

1.）STARTTLSは通常、サーバー間で実装されていますか、それともクライアントサーバーから開始してホップからホップへと進みますか？

STARTTLSは、各ホップ（MTA）に実装する必要があります。これは、受信MTAがSTARTTLSをサポートし、送信MTAがサポートできる場合にのみ使用できます。これは、メールがクライアントから初期ホップ（MTA）にどのように配信されたかには依存しません。通常、SMTPを使用したTLSはホップ間の接続のみを暗号化するため、エンドツーエンドでも（PGPまたはS/MIMEを使用して）暗号化されていない場合は、各ホップでクリアに読み取ることができます。

2.）PGPまたはS/MIMEで暗号化されたメールは、MXスプーフィングによってリダイレクトされますか？

はい、それでもリダイレクトできます。ただし、メール自体は、実際の受信者、つまりターゲットキーの所有者のみが復号化できます。

3.）DNSSECは、有用であるために大規模に採用される必要がありますか、それとも個人が自分の電子メールサーバーで構成することによって利益を得ることができるものですか？

すべてのビットが役立ちますが、ほんの少しです。また、DNSSecレコードが必要なだけでなく、転送MTAは実際にDNSSecを使用する必要があることに注意してください。ほとんどのMTAはおそらくDNSのみを実行し、スプーフィングされたMXレコードを取得したかどうかを認識しません。

4。）TCP暗黙のtlsのRSTインジェクション、または単に明示的なRSTインジェクションについて心配する必要がありますか？

暗黙的なTLSは、クライアントからMTA、つまり初期ホップにのみ使用されます。これは実際にクライアントを制御し、クライアントは通常、固定TLS設定の固定SMTPサーバーを使用するため、最も安全な手順です。したがって、MXスプーフィングや接続のダウングレードに問題はありません。代わりに、利用可能な場合にのみTLSを使用するようにクライアントが構成されている場合、攻撃は暗黙のTLSに対しても機能する可能性があります。

5.）他のMTAがTLS互換でない場合、つまり、オポチュニスティックから必須に切り替える場合、またはクライアント（Thunderbirdなど）でのみ実行できることである場合、接続をドロップする（電子メールをバウンスする）ようにサーバー/ MTAを構成できませんか？クライアント/サーバー接続？

ほとんどのサーバーはこのように構成できますが、ほとんどのサーバーはさまざまなサーバーと通信する必要があり、サーバーがTLSをサポートするかどうかを事前に知りません。ただし、たとえばsendmailは、TLSのみを特定のサーバーと通信するように構成したり、TLSを特定の他のサーバーと通信しないように構成したりできます。したがって、この構成は既知の正常なサーバーに強化できますが、これは手動で行う必要があります。

6。）＃5が可能で、電子メールが返送された場合、送信者は「送信に失敗しました」という通知を受け取りますか？

はい、通常、これはすべての配信エラーと同様に当てはまります。しかし、他のほとんどの配信エラーと同様に、技術的に適切な人だけがこれらのエラーメッセージを理解する可能性があります。

7.）証明書がチェックされない限り、適切な構成/実装で修正できるものです。問題の1つは、多くの証明書が自己署名されており、ほとんどのMTAがデフォルトでそれらを受け入れるため、より多くのMTAとの互換性を維持できることであると読みました。それはあなたが言及していたことの一部ですか？

サーバーによって異なります。しばらくの間、postfixは問題ないように見えましたが、sendmailはホスト名を証明書に対して適切にチェックできませんでした。はい、自己署名は1つの問題であり、もう1つの主な問題は中間証明書が欠落していることです。しかし、メール配信はとにかく機能するため（証明書エラーは送信者によって無視されるため）、ほとんどの管理者は不適切な構成に気付かないか、気にしません。

8.）最後に、重要な修正がすべて実施され、他のMTA /クライアントが私の制御不能であることを理解していると言います。これらのMITMおよびインジェクション攻撃は、私の電子メールアドレスとの間で送受信される特定の接続を標的にすることができますか？この状況では、彼らは私のサーバーに侵入しておらず、私の連絡先についての以前の経験もありません。

繰り返しになりますが、これはホップごとの暗号化のみであり、メールは各ホップで読み取りおよび変更するために明確に利用できます。したがって、転送に関与する任意のホップ（通常は少なくとも2つ、送信者サイトと受信者サイトに1つずつ）の攻撃者は、メールを傍受して変更することができ、もちろん、選択したメールのみを処理するように制限することもできます。唯一の保護は、PGPまたはS/MIMEを使用したエンドツーエンドの暗号化です。