6

HTTPS 経由で安全な通信を行うために継承したクライアント コードを調べていますが、サーバー証明書の共通名をチェックしていないようです (例: 'CN = "example.com"' を実際の URL に対してクライアント アプリはさまざまな環境と通信する必要があるため、これはおそらく意図的なものであり、最初のポータル (例: example.com/main) に接続し、ユーザーが環境を選択した後、アプリは特定の IP にリダイレクトされます。したがって、今後のすべてのリクエストは「 http://127.0.0.1/page 」のようになります。

ただし、SSL の初心者であるため、このチェックを無効にすることの意味がわかりません。私の最初の反応は、他の誰かが私たちの証明書をコピーして、私たちのサーバーの 1 つになりすますことができるため、ある種の中間者攻撃を実行する方が簡単だということです。しかし、共通名のチェックを行っている場合は、カスタム DNS 設定を使用して同じことを行うことができるため、実際には何も得られないようです. これにより、他の方法では無防備になる他の攻撃はありますか?

ありがとう

4

6 に答える 6

10

他の誰かがあなたの秘密鍵を持っていないため、証明書をコピーして使用することはできません。

証明書の CN がドメイン名と一致しないことを確認しない場合、彼らは単に独自の証明書を作成し (信頼できる CA によって署名されているため、有効に見えるように)、それをあなたの代わりに使用して、中間者攻撃。

また、証明書が信頼できる CA からのものであることを確認する必要があります。実際にそのドメインを制御している場合にのみ、CN= を使用して証明書を取得できるようにするのは、CA の仕事です。

これらのチェックのいずれかをスキップすると、MITM 攻撃の危険にさらされます。

クライアントを十分に制御できる場合に機能する別のアプローチについては、この回答も参照してください。

于 2008-09-26T11:09:09.180 に答える
5

クライアント コードを制御する場合は、信頼できる CA を自分のものだけに制限できます。その場合、ドメイン チェックはそれほど重要ではありません。どのサーバーも別のサーバーになりすますことができます。

クライアント コードを管理していない場合は、信頼できる CA によって署名された証明書を代わりに使用できます。

于 2008-09-26T11:28:35.280 に答える
4

$ 0.02：ホスト名にCNを使用することは非推奨です。代わりに、X.509サブジェクト代替名を使用する必要があります。

于 2008-09-28T10:37:30.353 に答える
2
  • 証明書自体を検証し、既に信頼している CA 証明書にチェーンできることを確認することで、証明書が本物で有効であることを確認できます。
  • 証明書のホスト名を確認すると、証明書が実際に有効であることが確認されていれば、通信しようとしていたサーバーと通信していることを確認できます。
  • (リモート パーティが実際にその証明書の秘密キーを保持していることを確認することは、SSL/TLS ハンドシェイク内で行われます。)

人のパスポート/ID チェックとの類似性が必要な場合:

  • 証明書の検証は、パスポートや身分証明書が本物であることを検証するようなものです。個人から受け入れる ID の形式 (パスポート、運転免許証、スタッフ カードなど) と、その信頼性を検証できると信頼できる発行国を決定できます。
  • 相手が秘密鍵を持っているかどうかを確認することは、パスポートや身分証明書の写真と目の前にいる人の顔が一致しているかどうかを確認することに似ています。
  • ホスト名を確認することは、探している名前の人のパスポートを確認するようなものです。

ホスト名を確認しないと、有効なパスポートを持っている本物と思われる人があなたのところに来て、あなたが探しているのは自分だと主張する可能性があります (名前で)。

非常に限られた一連の状況では、特定の CA または自己署名証明書のみを信頼し、潜在的な証明書が信頼する証明書のセット全体で他の証明書になりすますことを許可する場合、この検証を無視しても問題ありませんが、これは非常にまれであり、良い習慣ではありません。

パスポートの名前が探している人の名前と一致することを確認することは、常識と見なされます。証明書にもそれを行います。そうしないと、本物として信頼できる証明書を持っている人が、信頼できる他の証明書になりすますことができ、MITM 攻撃を実行する可能性があります。

HTTPS ホスト名検証ルールは、RFC 2818 セクション 3.1で定義されています(最近では、「ベスト プラクティス」仕様のRFC 6125にも定義されていますが、まだあまり実装されていません)。

つまり、ホスト名は Subject Alternative Name DNS エントリにある必要があります (ただし、証明書に SAN がないサブジェクト DN の CN にフォールバックできます)。IP アドレスを使用している場合、その IP アドレスは SAN IP アドレス エントリに含まれている必要があります (ただし、一部のブラウザでは、サブジェクト DN の CN にある IP アドレスを使用できます)。

于 2012-10-23T18:25:24.693 に答える
0

ホスト名の検証（CN部分の検証）は、接続のもう一方の端（サーバー）で、アドレスバーに入力したドメイン名でSSL証明書の問題が発生していることを保証します。通常、攻撃者はそのような証明書を取得できません。

ホスト名の部分を確認しないと、誰か（誰かがルーターのいずれかに座っているか、リクエストが通過するプロキシ）が中間者攻撃を行う可能性があります。または、誰かがDNS攻撃を悪用する可能性があります。

于 2008-09-28T10:32:52.097 に答える
0

「カスタム DNS 設定」で同じことを行うには、証明書を単にコピーするのではなく、DNS サーバー (あなたまたはクライアントの) を悪用して、攻撃者が制御する IP を example.com にポイントする必要があります。可能であれば、すべての特定のアプリを example.com のサブドメインとして作成し、ワイルドカード証明書 (*.example.com) を使用して CN を検証できるようにします。

于 2008-09-26T10:58:07.693 に答える