[解決済み] SSLとMan-in-the-Middleの誤解

質問

この問題に関連するドキュメントを大量に読みましたが、まだすべてのピースをまとめることができないので、いくつか質問させてください。

1. まず最初に、私が理解しているように、認証手順を簡単に説明します。クライアントは接続を開始し、サーバーは公開鍵、いくつかのメタデータ、および信頼できる機関のデジタル署名の組み合わせでそれに応答します。そして、クライアントはサーバを信頼するかどうかを判断し、ランダムなセッションキーを公開キーで暗号化して送り返します。このセッションキーは、サーバに保存されている秘密鍵によってのみ復号化することができます。サーバーがこれを実行すると、HTTPSセッションが開始されます。

2. というわけで、もし私が上記の通りなら、問題はこのようなシナリオでどのように中間者攻撃が起こりうるか、ということです。つまり、誰かが公開鍵によるサーバー (例: www.server.com) の応答を傍受し、私に彼が www.server.com であると思わせる手段を持っていたとしても、彼は秘密鍵なしで私のセッション鍵を復号化することはできないでしょう。

3. 相互認証について言えば、それはすべてクライアントの身元についてサーバーが信頼できるかどうかということでしょうか。つまり、クライアントは自分が正しいサーバと通信していることをすでに確信していますが、今度はサーバがクライアントが誰であるかを知りたがっているのですよね？

4. そして最後の質問は、相互認証の代替案についてです。もし私が前述の状況でクライアントとして行動する場合、SSLセッションが確立された後、HTTPヘッダーにログイン/パスワードを送信したらどうなるでしょうか？私が思うに、接続はすでに保護されており、サーバは私の識別のためにそれを信頼することができるので、この情報は傍受されることはないでしょう。私は間違っているのでしょうか？相互認証と比較して、このようなアプローチの欠点は何ですか（セキュリティの問題のみが重要であり、実装の複雑さは重要ではありません）？

どのように解決するのですか？

SSLに対する中間者攻撃は、実際にはSSLの前提条件の1つが破られた場合にのみ可能であり、ここにいくつかの例があります。

• サーバーの鍵が盗まれた - 攻撃者がサーバーであるかのように見せかけることができることを意味します。 まさか を知る術はありません。

• クライアントは信頼できない CA (またはルートキーを盗まれた CA) を信頼します。信頼できる CA キーを保持する人は誰でも、サーバーのふりをした証明書を生成でき、クライアントはそれを信頼します。今日、ブラウザにあらかじめ存在するCAの数からして、これは現実的な問題かもしれません。これは、サーバー証明書が別の有効なものに変更されたように見えることを意味し、ほとんどのクライアントがそれを隠してしまうことになります。

• クライアントは、信頼できる CA のリストに対して証明書を正しく検証することを面倒くさがりません - CA は誰でも作成できます。検証を行わない場合、quot;Ben's Cars and Certificates" はベリサインと同じように有効であるように見えます。

• クライアントは攻撃され、偽の CA が信頼されたルート認証局に注入されました。これにより、攻撃者は好きな証明書を生成でき、クライアントはそれを信頼することになります。マルウェアは、たとえば、偽のバンキング サイトにリダイレクトするためにこれを行う傾向があります。

特に2は厄介で、たとえお金を払って信頼性の高い証明書を購入したとしても、あなたのサイトはその証明書に一切ロックされることはありません。 すべて CA のいずれかが、あなたのサイト用に有効な偽の証明書を生成することができるからです。また、サーバーまたはクライアントのいずれにもアクセスする必要はありません。