1

デジタル証明書は、特定の公開鍵が特定のユーザーによって所有されていることを証明するデジタル文書です。したがって、証明書に署名した CA を信頼する場合C、特定の公開鍵と秘密鍵のペアが証明書の所有者によって所有されていることを信頼できますC

a) クライアントがURL www.some_domain.com にあるAサーバーとの接続を確立したいとします。Bとの接続を確立するときB、は、証明書の所有者に属するAX.509 証明書と公開鍵を相手側から受け取ることができます。CC

しかし、クライアントは、 の所有者Cが実際にはサーバーBであり、接続を乗っ取って (それが正しい用語である場合) 独自の証明書と公開鍵を送信した他のエンティティではないことをどのように知ることができますAか?

の所有者がC実際BC's Subject組織 www.some_domain.com 所属)?!

ありがとうございました

4

4 に答える 4

2

証明書ができることは、A と C の間の通信が暗号化され、C (または証明書がインストールされているもの) だけが復号化できるようにすることだけです。

C が誰によって所有されているかについては、まったく表明しません。一部の認証局は、証明書を発行する前に、特定のエンティティが本人であることを証明しようとします。しかし、率直に言って、それらはすべてだまされる可能性があり、ほとんどのサイトはとにかくそのレベルの調査 (Extended Validation と呼ばれる) にお金を払っていません。

ここで、攻撃者がサーバー C から証明書を盗み、(同じ完全修飾ドメイン名を使用して) 独自のサーバーをセットアップした場合、なりすましを行うことができます。ただし、これには、DNS 解決をポイズニングする追加の手順が必要になり、www.some_domain.com への要求が元のサーバーではなくハッカーのサーバーに送信されるようになります。通常、元のサーバーをクラックして独自のデータ キャプチャ ソフトウェアをインストールする方がはるかに簡単です。

補足として、DNS 解決には大きな セキュリティ上 の問題があります。

別の注記として、最近、stuxnetワームは、盗まれたコード署名証明書を使用して、Windows インストール保護の一部をすり抜けました。

于 2010-11-23T19:52:32.990 に答える
1

「C」は、システムにすでに存在する CA 認証局によって署名されているためです。そのため、CA を管理する政府によってスキームが破られる可能性があります。

ブラウザで証明書を見ると、誰が署名したかがわかります。たとえば、gmail は Verisign によって署名された Thawte によって署名されています。CNフィールドはマークされているため、そのwww.google.comドメインでのみ有効です。

たぶん、あなたは中間者について話している: http://en.wikipedia.org/wiki/Man-in-the-middle_attack

中間者攻撃は、攻撃者が相互認証に対する攻撃であり、攻撃者が各エンドポイントを偽装して他のエンドポイントを満足させることができる場合にのみ成功します。ほとんどの暗号化プロトコルには、MITM 攻撃を防止するための何らかの形式のエンドポイント認証が含まれています。たとえば、SSL は、相互に信頼された証明機関を使用してサーバーを認証します。

したがって、あなたのシナリオでは、だまされるのは片側だけです。以下のステップ 2 を確認してください。

https://ssl.trustwave.com/support/support-how-ssl-works.php

  • ステップ 1: 顧客が SSL ポート (通常は 443) で xyz.com に接続します。この接続は、http ではなく https で示されます。
  • ステップ 2: xyz.com は公開鍵を顧客に送り返します。顧客がそれを受け取ると、ブラウザは続行してもよいかどうかを判断します。

    • xyz.com 公開鍵の有効期限が切れていてはなりません
    • xyz.com 公開鍵は、xyz.com 専用でなければなりません
    • クライアントは、Trustwave の公開鍵をブラウザの証明書ストアにインストールする必要があります。最新のブラウザー (1998 年以降) の 99.9% には、Trustwave ルート証明書が含まれています。顧客が Trustwave の信頼できる公開鍵を持っている場合、XYZ, Inc. と実際に通信していると信頼できます。
  • ステップ 3: 顧客が証明書を信頼することを決定した場合、顧客は xyz.com に自分の公開鍵が送信されます。-ステップ 4: 次に、xyz.com は一意のハッシュを作成し、顧客の公開鍵と xyz.com の秘密鍵の両方を使用して暗号化し、これをクライアントに送り返します。

  • ステップ 5: お客様のブラウザがハッシュを復号化します。このプロセスは、xyz.com がハッシュを送信し、顧客だけがそれを読み取ることができることを示しています。
  • ステップ 6: 顧客と Web サイトが安全に情報を交換できるようになりました。
于 2010-11-23T19:51:41.180 に答える
1

A は通常、C の公開鍵を信頼できるエンティティ (この場合は B) にマップする一連の信頼できる CA で構成されています。

于 2010-11-23T19:52:12.207 に答える
0

したがって、クライアント A は、証明書 C が本物かどうかを知る必要があります。これを検証するのは誰の仕事ですか?回答: A のブラウザです。どのように検証しますか?回答: ブラウザは、誰が証明書に署名したかをチェックします。誰が証明書に署名しましたか? 回答: AweCerts.Inc という名前の CA (認証局) ブラウザはこの CA を認識していますか。また、ブラウザは CA を信頼していますか? 回答:はい。ブラウザが信頼しない場合、A は先に進むことができません。そして、ブロワーは AweCerts を信頼するだけでなく、彼女/彼の友人 (チェーン全体) も信頼します。ブラウザーは、この証明書が AweCerts.Inc によって署名されたことをどのように認識しますか? 回答: ブラウザは AweCerts と契約していました。Microsoft はIE の場合にこれを行います。
ブラウザが AweCerts 公開鍵を使用してメッセージ (外側のカバー) のロックを解除できる場合、メッセージは「AweCerts 秘密鍵で暗号化」されているか、Awecerts によって署名されていることが確実です。

通常、公開鍵で暗号化し、秘密鍵で復号化します。しかし、その逆も可能であり、それが実際にデジタル署名と呼ばれるものです。また、証明書とメッセージングに関する興味深い情報については、私のブログを参照してください。

ここに興味深いブログがありますhttp://the-blueclouds.blogspot.nl/2011/11/public-key-private-key-hashing-blah.html

于 2014-05-23T13:28:23.970 に答える