証明書はどのようにしてこの中間者攻撃を阻止しますか？
アリスとボブは安全な会話をセットアップしようとしていますが、真ん中では彼らの間で送信されたすべてのパケットを傍受して変更できるイブが知られていません。
通信は次のようになります。
アリスはハローをボブに送信し、いくつかのパラメーター（たとえば、一時的なDiffie-Hellman公開鍵）を含めます。A。イブはメッセージを傍受し、AをEに置き換えます。
ボブはパラメータBで応答し、公開鍵とドメインを含む証明書も送信します。イブはこれを傍受します。この時点で、EveとBobはE、B、およびそれらに関連するプライベートデータ（たとえば、関連する一時的なDHプライベートキー）から共有秘密EBを取得しますが、アリスはこれを知りません。
Eveはメッセージを（2）からAliceに転送し、証明書は同じままにします（CAではないため、自分で作成することはできません）が、BをEに変更します。この時点で、AliceとEveはEから共有秘密EAを導出します。 A、およびボブが知らない関連するプライベートデータ。
アリスは証明書を検証します。改ざんされていないため、フラグは立てられません。
アリスは、ボブの公開鍵（証明書から）を使用してメッセージを暗号化し、ボブに送信します。共有シークレットEAが含まれています。
Eveはこのメッセージ（確かに彼女は解読できない）を傍受し、破棄します。彼女は代わりに、共有秘密EBを含む、彼の公開鍵で暗号化された新しいものをボブに送信します。ボブはこれを見て、それが彼が期待していた共有された秘密と一致するので、ハンドシェイクは成功したと見なします。
これからは、ボブとイブが共有秘密EBを使用して会話し、イブとアリスが共有秘密EAを使用して会話します。ボブもアリスも、イブが盗聴していることに気づいていません。
おそらく、これは証明書によって防止されることを意図していますが、私は方法がわかりません。
まさにこの理由から、実際のセキュリティシステムは、あなたが説明したようには機能しません。証明書は、共有シークレットを暗号化して同じシークレットを持っていることを確認するためには使用されません。それは無意味です（一方の側でシークレットを生成し、もう一方の側の公開鍵で暗号化して送信することもできます）。共有秘密が証明書にないデータを使用して生成される場合、証明書の役割はsignそのデータです。経験則として、自分からではなく、信頼された公開鍵で署名されていない鍵生成プロセスへの入力は絶対に受け入れないようにします（TLSでは、CA鍵はブラウザーにプリロードされているため、信頼済み;次に、CA署名付き証明書がボブの公開鍵への信頼を確立します。
この場合、通信が実際に機能する方法は次のとおりです。
- アリスはボブAを送ります。イブはそれを傍受し、Eに置き換えます。
- Bobは証明書Bと、証明書で検証できるBのsignatureを送り返します。証明書は、暗号化キーではなく署名キー用です（RSAでは、キーを指定したのは違いだけですが、暗号化専用または署名専用のアルゴリズムがあります）。
- イブはそれを傍受し、BをEに置き換えます。ただし、Eはボブの秘密鍵で署名できないため、証明書を変更してEに新しい署名を付けるか、証明書をそのまま残します（ただし、証明書を作成しません）彼女ができないので、それで新しい署名。
- アリスは、証明書がCAによって署名されていないか、署名の検証が失敗したことを確認します（署名はEの有効な署名ではありません）。
- アリスは、改ざんされていることを知っているため、通信を終了します。
アリスはコードAを含むボブにHelloを送信します。イブはメッセージを傍受し、代わりにコードEを配置します。
上記は起こりません。アリスが何かを送信する前に、アリスはCAの公開鍵（自分の証明書ストアに存在）を使用して verify bob.com（Eve）に送信します。検証は失敗するため、アリスはボブの証明書が無効。
アリスがイブの証明書をアリスの信頼できる証明書ストアに追加した場合、アリスは大きな問題を抱えています。それは、アリスがbob.comをCAの公開鍵に対して検証しないためです。