SSLの中間者とその制限について
SSLの中間者（MITM）がどのように機能するかを理解しようとしています。私が理解しているように、MITMは次の2つの方法のいずれかで作業を行います。
- サーバーの秘密鍵のコピーを保持して、SSLを復号化します。厳密に言えば、「MITMデバイス」は単に盗聴しているだけなので、これはMITMではありません。 SSLセッションは変更されません
- その場で新しい証明書を生成します。ここで、MITMデバイスはクライアントのhelloを転送し、サーバー証明書を傍受し、新しい証明書を生成して署名し、クライアントに転送します。クライアントは証明書を信頼するか、証明書を信頼するよう求められます（自己署名されている場合）
ただし、制限（および緩和策）があります。
- クライアントとサーバーは、DHE_RSA（またはバリアント）を使用してキーを生成および交換することに同意する場合があります。 MITMは鍵の生成には参加しません。しかし、洗練されたMITMでもセッションキーを生成して、どちらの側でも異なるSSLセッションを作成できないのでしょうか。
- 拡張マスターシークレットも同じではないでしょうか。上記のように、MITMが実際に個別のセッションキーを計算している場合、Extended Master SecretはMITMを無効にするのに役立ちません
- サーバーはクライアント証明書を必要とする場合があります。しかし、MITMが独自のクライアント証明書と対応する秘密鍵を取得できた場合、証明書検証ハンドシェイクメッセージに正常に署名できます。
私はこれをすべて正しく理解していますか？ MITMが十分なキーマテリアルにアクセスできる場合、SSLセッションを正常に復号化できるようです。
いくつかの概念は正しいと思いますが、誤解や不正確さもあります。
- RSAキー交換が使用されている場合にのみ、サーバーの秘密キーを使用して、中間者攻撃（つまり、スニッフィングのみ）のパッシブマンでトラフィックを解読することができます。 Diffie-Hellman鍵交換では実行できません。 RSA鍵交換とは対照的に、DH鍵交換も 転送秘密 を引き起こします。これは、攻撃者が証明書の秘密鍵を取得すると、以前に盗聴された接続を復号化できないことを意味します。
- 中間者攻撃は、クライアントからMITMへ、およびMITMからサーバーへのSSLセッションで構成されます。これらは完全に独立したセッションであり、キーが異なり、異なる暗号、プロトコルバージョンなども使用できます。MITM攻撃者がサーバーの元の秘密キーを持っている場合、元の証明書を使用してサーバーを完全に偽装できます。それ以外の場合は、偽の証明書を使用する必要があります（多くの場合、動的に作成されます）。クライアントが偽の証明書を発行するCAをすでに信頼しているか、クライアントが適切な証明書の検証を行わない場合、攻撃は後者の場合にのみ成功します。
- クライアント証明書はサーバー証明書に似ています。攻撃者が元の証明書の秘密鍵を持っているため、それを使用できるか、サーバーが攻撃者を信頼する必要があり、偽の証明書はそれぞれ証明書を適切に検証できません。
MITMの最も明白な脅威は、Webサイトとブラウザの間などの対話が単純化されるところです。ほとんどの場合、ユーザーはURLを入力するだけで、接続が安全であるという通知が表示されることを期待しています。提示されたサイトが彼らの期待に一致する場合、彼らは彼らのビジネスについて行きます。
面白いことに、MITMはセキュリティゲートウェイによってホールセールで使用され、HTTPS接続でコンテンツフィルタリングを実行します。これらの場合、ゲートウェイはすべての発信トラフィックのプロキシとして機能します。 HTTPS接続は、クライアントとゲートウェイの間です。企業環境では、IT部門は通常、ゲートウェイのルートCAを社内のすべてのマシンにプッシュしました。これにより、クライアントはゲートウェイの証明書にアクセスし、接続が安全であることがわかります。次に、ゲートウェイは要求を復号化し、必要に応じてフィルタリングして、サーバーへの独自の安全な接続を確立します。これは、セキュリティで保護されたSMTP接続および強制的にプロキシされるその他のプロトコルにも適用されます。
上記のシナリオの1つの特典は、ゲートウェイで使用される証明書は通常、接続がゲートウェイプロバイダー（Sophos、Checkpoint、Fortinetなど）との接続であることを識別することです。
悪意のある俳優の場合、目的は不正な傍受です。これが成功するためには、攻撃者は一般的に信頼されているルートCAを危険にさらすことになります。その妥協を通して、アクターはサーバーに予想されるすべての詳細を含む新しい証明書を発行できます。
宿泊客（アリス）が不親切な場所に滞在していると仮定します。彼らはBob.comのサービスを利用したいと考えています。俳優マロリーはMITMを試みています。
MaloryはBob.comに接続し、Bob.comのSSL証明書のビジネスの詳細をすべてコピーします。 Maloryは以前に、Windows、macos、ios、およびAndroidに組み込まれているWeTrust Root CAを侵害しました。
マロリーはホテルのネットワークに自分自身を挿入します（物理的なタップ、スイッチでのポートの再ルーティング、または単純なDHCP攻撃のいずれかになる可能性があります）。マロリーは、Bob.comへのアクセスを探す透過的なプロキシを介してすべてのトラフィックをリダイレクトします。
AliceがBob.comにアクセスすると、Maloryのプロキシは偽造された証明書を使用してBob.comとして自分自身をAliceに提示します。一方、MaloryはBob.comに接続し、リクエスト/プル/プッシュ/プットなどを2つの間で転送します。アリスがルートCAの発行者を見て、Bob.comのSSL証明書発行者が誰であるかを知らない限り（また、Bob.comのSSL証明書発行者がMaloryによって侵害された発行者と同じでない場合）、彼女はそれを検出する方法がありません。 MITM。
MITMは、暗号化を解読するのではなく、単純なWireshark/Netflowトラフィックモニタリングを使用して、鍵交換に自分自身を挿入することを目的としています。