安全な鍵交換プロトコルに対する中間者攻撃
CISSP資料を調べていると、Diffie HellmanやRSAなどのSecure Exchange Protocolsに行き詰まりました。 DH自体がMiTMに対して脆弱であることが知られています。したがって、答えは証明書などの認証方法を使用することです。それがhttpsのベースになっているので、それは公平で正解です。しかし、SSLインスペクションのようなものがある場合、それはどのようにMiTMの証明になりますか？ SSL検査は、本来、独自の証明書を挿入し、宛先の証明書のCAのように見えることにより、暗号化されたトラフィックを傍受するように設計されたMiTM攻撃です。今日のほとんどのAVソリューションは同じことを行います。アクセスするhttps Webサイトの証明書を確認すると、AVベンダーによって署名されます。
これらは私が使用したソースです
https://www.emc.com/emc-plus/rsa-labs/standards-initiatives/what-is-diffie-hellman.htm
RSAフィンガープリントはMITM攻撃からどのように保護しますか？
RSAの記事によれば、「キャロルはアリスとボブの間でメッセージを傍受することはできますが、アリスの秘密鍵とボブの秘密鍵なしでは署名を偽造することはできません。」
私の質問は、なぜ彼女はそれをする必要があるのでしょうか？彼女が自分のデータを傍受している場合、彼女は自分が署名した証明書を使用して、どちらかの当事者になりすますことができます。彼女は自分の秘密鍵を署名と復号化に使用できます。これは、両当事者に自分の公開鍵をすでに提供しているためです。次に、宛先の公開鍵でデータを再暗号化して渡します。 SSLインターセプトの仕組みは正確ではないですか？
これを回避する唯一の方法は、偽の証明書に署名するために使用された彼女のCAが、被害者の信頼された証明書ルートストアにないことです。しかし、私がDiffie Hellmanを使用して作成したすべてのL2L VPNを思い出すと、それらのいずれも（証明書または証明書ルートストア）は使用されませんでした。
ここで何かが欠けているに違いない。
その理由は、下部で強調表示しているものです。証明書を信頼しています。 SSLインスペクションを行うときなど、企業レベルでMiTMを実行するために使用される証明書は、ドメイン内のコンピューターによって信頼されている内部CAが展開されていることに依存しています。多くの場合、信頼されたCAはドメインマシンのドメインコントローラーによってプッシュダウンされます。
L2L VPNは、鍵交換（IKE）にDHを実装するIPSecを使用します。
- フェーズI：ピアは、証明書または事前共有秘密を介して認証します。認証。
- フェーズII：Diffie-Hellman鍵が作成されます。 Diffie-Hellmanプロトコルの性質は、両側が独立して共有シークレットを作成できることを意味します。これは、ピアだけが知っているキーです。鍵交換。