101

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

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

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

  3. 相互認証について言えば、クライアント ID に関するサーバーの信頼がすべてなのでしょうか? つまり、クライアントは適切なサーバーと通信していることをすでに確信できますが、サーバーはクライアントが誰であるかを知りたがっていますよね?

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

4

5 に答える 5

112

SSL に対する中間者攻撃は、SSL の前提条件の 1 つが破られた場合にのみ可能になります。いくつかの例を次に示します。

  • サーバー キーが盗まれました - 攻撃者がサーバーのように見える可能性があり、クライアントが知る方法がないことを意味します。

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

  • クライアントは、信頼できる CA のリストに対して証明書を正しく検証する必要はありません。誰でも CA を作成できます。検証なしでは、「Ben's Cars and Certificates」は Verisign と同じように有効であるように見えます。

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

特に＃2はかなり厄介です。信頼性の高い証明書にお金を払っても、サイトはその証明書にロックされることはありません.クライアントのブラウザですべてのCAを信頼する必要があります。あなたのサイトも同様に有効です。また、サーバーまたはクライアントへのアクセスも必要ありません。

于 2013-02-16T06:38:24.440 に答える
19

最初に、認証手順を理解しているので簡単に説明しますが、その手順を間違えている可能性があります。したがって、クライアントが接続を開始すると、サーバーは公開鍵、いくつかのメタデータ、および信頼できる機関のデジタル署名の組み合わせで応答します。

サーバーは、X.509 証明書チェーンと、独自の秘密鍵で署名されたデジタル署名で応答します。

次に、クライアントがサーバーを信頼するかどうかを決定します

正しい。

公開鍵でランダムなセッション鍵を暗号化し、送り返します。

いいえ。クライアントとサーバーは、セッション キー自体がまったく送信されない相互セッション キー生成プロセスに関与します。

このセッション キーは、サーバーに保存されている秘密キーでのみ復号化できます。

いいえ。

サーバーはこれを行います

いいえ。

その後、HTTPS セッションが開始されます。

TLS/SSLセッションが開始されますが、最初に追加の手順があります。

したがって、上記が正しければ、問題は、そのようなシナリオで中間者攻撃がどのように発生する可能性があるかということです。

サーバーになりすまし、SSL エンドポイントとして機能する。クライアントは、承認手順を省略しなければなりません。残念ながら、ほとんどの HTTPS セッションで唯一の認証手順は、ホスト名のチェックです。

つまり、誰かがサーバー (例: www.server.com) の応答を公開鍵で傍受し、何らかの手段で自分が www.server.com であると私に思わせたとしても、彼は私のセッション鍵を解読することはできません。秘密鍵なし。

上記を参照。復号化するセッション キーはありません。SSL 接続自体は安全ですが、安全ではない可能性があるのは、あなたが話している相手です。

相互認証について言えば、クライアント ID に関するサーバーの信頼がすべてなのでしょうか? つまり、クライアントは適切なサーバーと通信していることをすでに確信できますが、サーバーはクライアントが誰であるかを知りたがっていますよね?

正しい。

そして最後の質問は、相互認証の代替案についてです。上記の状況でクライアントとして動作する場合、SSL セッションが確立された後に HTTP ヘッダーでログイン/パスワードを送信するとどうなりますか? ご覧のとおり、接続は既に保護されており、サーバーはそれを使用して個人を特定できるため、この情報を傍受することはできません。私が間違っている？

いいえ。

相互認証と比較して、このようなアプローチの欠点は何ですか (実装の複雑さではなく、セキュリティの問題のみが重要です)。

ユーザー名/パスワードと同じくらい安全であり、秘密鍵よりも漏えいしやすい.

于 2013-02-17T02:47:40.960 に答える
2
  1. 正しい
  2. それほど正しくありません。この種の攻撃では、中間サーバーがリクエストを取得し、代わりに宛先に送信します。その後、結果を返信します。実際には、あなたが通信しようとしている実際のサーバーではなく、あなたと安全に接続するのは中間者サーバーです。そのため、証明書が有効で信頼できるものであることを常に確認する必要があります。
  3. 正しいかもしれません
  4. セキュリティで保護された接続が信頼されていることが確かな場合は、ユーザー名/パスワードを安全に送信できます。
于 2013-02-16T06:22:20.673 に答える
1

セッションキーに関する部分を除いて、あなたが言ったことはすべて正しいです。CA のポイントは、中間者攻撃を無効にすることです。それ以外はすべて SSL 自体によって行われます。クライアント認証は、ユーザー名とパスワードのスキームに代わるものです。

于 2013-02-16T06:19:53.440 に答える