0

この質問が本当に素朴な場合は申し訳ありませんが、関連する回答を見つけることができずにできる限り検索しました。

この 3 日間、https の仕組みを理解しようとしました。最近まで私が知っていたのは、対称暗号と非対称暗号がどのように機能するかということだけでした。これら 2 つが ssl-https にどのように適用され、いわゆるデータ暗号化とサーバー ID 検証を実現するかを理解するときが来ました。

データの暗号化と中間者攻撃の防止に関して、すべてが明確です

サーバーの身元確認がどのように機能するかを完全には理解していないようですので、ご協力いただければ幸いです。

これまでの私の理解は次のとおりです。

クライアントが https 経由でサーバーに接続すると、サーバーは CA によって署名された証明書を送信します。このサーバー証明書は、サーバーに関する情報 (名前、所有者の電子メール、公開鍵など) とデジタル署名を含むテキスト ファイルです。

この署名は、サーバー情報のコンテンツのハッシュであり、CA 秘密鍵によって暗号化されています。

クライアントは、サーバー情報のハッシュを独自に生成し、CA の公開鍵を使用して署名を復号化することにより、署名の有効性を確認します。復号化された署名値が生成されたハッシュと同じである場合、署名と証明書はその後有効になります。

ここで、官民暗号化方式には二重の性質があることに注意してください。メッセージは公開鍵で暗号化し、秘密鍵で復号化できます。同じメッセージを秘密鍵で暗号化し、公開鍵で復号化することもできます。

ここで覚えておく必要があるのは、証明書が静的で変更不可能なファイルであることです。ファイルを変更すると、署名の不一致が発生します。

ここで、https をだます方法について説明します。

URL = https://wwww.TheBank.com/ebanking (public IP = 195.134.0.1)の ebanking サイトがあるとします。この URL に接続すると、ブラウザがサーバー証明書を取得します。(theBank.cer)

同時に私はインターネットカフェのオーナーです。私のインターネット カフェには、独自のルーター、DNS、および DCHP サーバーがあり、それらを制御する知識があります。WEBサーバーもあります。

銀行と同じように、IP 195.134.0.1 を所有するように Web サーバーを構成します 195.134.0.1 の接続要求を Web サーバーに送信するルーターへのルートを作成します 上記の銀行の URL を 195.134.0.1(私の Web サーバー) 私は自分の Web サーバーに詐欺的な銀行サイトを配置しています。このサイトへの接続では、以前にダウンロードした証明書をクライアントに送信するように Web サーバーに指示します ( theBank.cer)。

ユーザーが私のカフェに来て、私のネットワークに接続し、この銀行に接続しようとします。私のサーバーは彼に銀行の証明書を送信します。彼のブラウザは証明書の有効性を確認します。これは実際に有効なものであり、URL、IP、およびホスト名が本物と同じであるため、私の偽の Web サイトへの接続を許可します。

これで私の詐欺は成功です。

もちろん、このセキュリティ ホールはあまりにも明白すぎて真実ではありません。つまり、このサーバー ID 検証手順で何か理解できませんでした。誰かが私にここで何が欠けているのか説明してもらえますか?

4

3 に答える 3

3

ユーザーが私のカフェに来て、私のネットワークに接続し、この銀行に接続しようとします。私のサーバーは彼に銀行の証明書を送ります。彼のブラウザは、証明書が実際に有効であるため、証明書の有効性を確認し、URL、IP、およびホスト名が実際のものと同じであるため、私の偽のWebサイトへの接続を許可します。

彼のブラウザが有効性を確認すると、証明書に含まれているため、銀行の実際の公開鍵がわかります。サーバーはその公開鍵に対応する秘密鍵で何にも署名できず、その公開鍵で暗号化されたものを復号化できないため、銀行になりすますことはできません。あなたができることは、あなたが偽装することができない銀行の本当のアイデンティティをユーザーに納得させることです。

あなたが見逃している重要なことは、証明書の主な目的は、信頼できる機関が実世界のIDを公開鍵にバインドすることであり、その実世界のIDの所有者だけが対応する秘密鍵を知っているということだと思います。

于 2012-11-21T13:54:50.780 に答える
0

この署名は、サーバー情報のコンテンツのハッシュであり、CA 秘密鍵によって暗号化されています。

クライアントは、サーバー情報のハッシュを独自に生成し、CA の公開鍵を使用して署名を復号化することにより、署名の有効性を確認します。復号化された署名値が生成されたハッシュと同じである場合、署名と証明書はその後有効になります。

これは多かれ少なかれ RSA で発生することですが、署名のみ (暗号化なし) である DSA では発生しません。

一般に、秘密鍵による「暗号化」について話すべきではありません。誰でも公開鍵で復号化できるため(公開されているため)、意味がありません。暗号化とは、情報を隠すことです。

秘密鍵でできることは、署名と復号化/解読です。公開鍵でできることは、署名の暗号化と検証です。

暗号化が必要な場合と署名が必要な場合を混同すると (アルゴリズムが RSA と非常に似ているにもかかわらず)、セキュリティを提供しないシステムを設計することになります。

より一般的には、公開鍵証明書 (X.509 証明書、または PGP 証明書) の目的は、ID (サーバーのホスト名など) を公開鍵にバインドすることです。( Security.SE に関するこの質問を参照してください。)

私のウェブサーバーが受け取るデータは、銀行の公開鍵によって暗号化されます

SSL/TLS トラフィックは、証明書の秘密鍵を使用して暗号化されるのではなく、SSL/TLS ハンドシェイク中にネゴシエートされた共有鍵を使用して暗号化されることに注意してください。

SSL/TLS ハンドシェイク中、その公開鍵は、プリマスター シークレットを暗号化するか、他のパラメーターに署名するために使用され (暗号スイートに応じて)、最終的に、クライアントが秘密鍵を持つサーバーと通信していることをクライアントに証明します。この公開鍵の鍵。

証明書はサーバー名も公開鍵にバインドするため、クライアントは正しいサーバーと通信していることを認識します。

このため、(a) 証明書が信頼されていること、および (b) クライアントが接続したいサーバー名に対して証明書が発行されていることを確認することが重要です。

于 2012-11-21T14:30:36.447 に答える
0

theBank.cer公開鍵です。
それを使用して何かを復号化または署名することはできません。

于 2012-11-21T13:52:37.150 に答える