目次
2.2. シナリオ 2 - 一方の当事者のみが非対称暗号化を使用する
2.7. スキーム 5 - 非対称暗号化 + 対称暗号化 + 証明書認証
1.HTTPSプロトコル
1.1. HTTPS の概要
HTTPS はアプリケーション層プロトコルでもあり、HTTP プロトコルに基づいた暗号化層が導入されています。HTTP プロトコルの内容はテキスト形式の平文で送信されますが、平文送信は安全ではないため、現在の主流の解決策は、http が配置されているアプリケーション層とトランスポート層の間に SSL/TLS ソフトウェアの層を追加することです。 tcp が配置されている層 (SSL/TLS ソフトウェア層はアプリケーション層に属します)。SSL/TLS ソフトウェア層は、アプリケーション層からトランスポート層に送信されるデータの暗号化機能を実行し、データの復号化機能を実行します。トランスポート層からアプリケーション層に受信されます。http プロトコルとSSL/TLS ソフトウェア層全体を https プロトコルに 組み込みます 。ノート：1. http プロトコル自体については、平文情報を送信し、平文情報を受信しますが、これはいかなる影響も受けません。2. http プロトコルのデフォルトのバインディング ポートはポート 80、https プロトコルのデフォルトのバインディング ポートはポート 443 です。
1.2.補足知識
1.2.1. 「暗号化」とは
• 暗号化とは、平文（送信する情報）に一連の変換を実行して暗号文を生成することです。• 復号化とは、暗号文に対して一連の変換を実行し、平文に復元することです。• 暗号化と復号化のプロセスでは、多くの場合、このプロセスを支援するために 1 つ以上の中間データが必要になります (このようなデータはキーと呼ばれます)。注: すべての暗号化は、中間者による盗用や改ざんを防ぐために行われます。
1.2.2.暗号化を行う理由
例えば：Tiantiandongting ソフトウェアをダウンロードします。ハイジャックされていない場合は、ダウンロード ボタンをクリックすると、下の図 1 に示すように、Tiantiandongting のダウンロード リンクがポップアップ表示されます。ハイジャックされている場合は、ダウンロード ボタンをクリックすると、QQ ブラウザがダウンロードされます下の図 2 に示すように、リンクがポップアップします。
以下の図に示すように、ネットワークを通じて送信されるデータ パケットはすべて事業者のネットワーク機器 (ルーター、スイッチなど) を通過するため、事業者のネットワーク機器は送信したデータの内容を解析して改ざんする可能性があります。それ。「ダウンロードボタン」をクリックすると、実際にサーバーにHTTPリクエストが送信され、取得したHTTPレスポンスには実際にAPPのダウンロードリンクが含まれています。オペレーターによる乗っ取り後、要求が天天東亭のダウンロードであることが判明したため、ユーザーへの応答を「QQ Browser」のダウンロードアドレスに自動的に変更した。
したがって、httpの内容は平文で送信されるため、平文データはルーター、Wi-Fiホットスポット、通信事業者、プロキシサーバーなどの複数の物理ノードを経由することになります。送信中に情報が乗っ取られると、送信された内容が失われてしまいます。完全に暴露されてしまいます。ハイジャッカーは、双方に気付かれずに送信された情報を改ざんすることもでき、これは中間者攻撃であるため、情報を暗号化する必要があります。オペレーターだけがハイジャックできるだけでなく、他のハッカーも同様の手段を使用してハイジャックし、ユーザーのプライバシー情報を盗んだり、コンテンツを改ざんしたりする可能性があります。 想像してみてください。ユーザーが Alipay にログインしたときにハッカーがユーザーのアカウントの残高を取得し、さらにユーザーの支払いパスワードも取得した場合...インターネットでは、平文で送信することの方が危険です。HTTPS は HTTP に基づいて暗号化され、ユーザー情報のセキュリティをさらに確保します。
1.2.3.一般的な暗号化方式
対称暗号化:• 単一鍵暗号方式の暗号化方式を使用すると、情報の暗号化と復号化に同じ鍵を使用できます。この暗号化方式は対称暗号化と呼ばれ、単一鍵暗号化とも呼ばれます。同じだ。• 一般的な対称暗号化アルゴリズム (理解): DES、3DES、AES、TDEA、Blowfish、RC2 など。• 特徴: オープンなアルゴリズム、少ない計算量、速い暗号化速度、高い暗号化効率。対称暗号化とは、実際には、同じ「鍵」を使用して平文を暗号文に暗号化し、暗号文を平文に復号することです。例: (単純な対称暗号化、ビットごとの XOR)平文 a=1234、鍵 key=8888 とすると、a^key を暗号化して得られる暗号文 b は 9834 となります。次に、暗号文 9834 に対して b^key を再度計算すると、元の平文 1234 が得られます。(文字列の対称暗号化にも同じことが当てはまり、各文字は数値として表すことができます)もちろん、ビットごとの XOR は対称暗号化の最も単純な形式にすぎません。ビットごとの XOR は HTTPS では使用されません。
非対称暗号化:• 暗号化と復号化には 2 つの鍵が必要です。2 つの鍵は、公開鍵 (公開鍵、公開鍵と呼ばれます) と秘密鍵 (秘密鍵、秘密鍵と呼ばれます) です。• 一般的な非対称暗号化アルゴリズム: RSA、DSA、ECDSA• 特徴：アルゴリズムの強度が複雑で、安全性はアルゴリズムと鍵に依存しますが、アルゴリズムが複雑であるため、暗号化および復号の速度は対称暗号および復号ほど速くありません。非対称暗号化では、「公開鍵」と「秘密鍵」というペアになった2つの鍵を使用します。最大の欠点は、動作速度が非常に遅いことであり、対称暗号化よりもはるかに遅いです。• 平文を公開鍵で暗号化し、暗号文に変換する• 秘密鍵を使用して暗号文を復号し、平文に変換します。逆に使用することもできます• 平文を秘密鍵で暗号化し、暗号文に変換します。• 公開鍵を使用して暗号文を復号し、平文に変換します。例: 非対称暗号化の数学的原理は比較的複雑で、数論に関連する知識が必要になります。ここでは日常生活からの簡単な例を示します。A は B にいくつかの重要な書類を渡したいと考えていますが、B がその場にいない可能性があるため、A と B は事前に次のような合意を交わします。B は言いました。「私の机の上に箱があります。それで鍵をあげます。あなたはその箱にファイルを入れて鍵をかけ、私は振り返って鍵を取り、ロックを解除してファイルを取り出します。」このシナリオでは、ロックは公開キーに相当し、キーは秘密キーです。公開鍵は誰にでも与えることができますが (漏洩の心配はありません)、秘密鍵は B 自身だけが保持します。秘密鍵を持っている人だけが復号化できます。
1.2.4. データの概要とデータのフィンガープリント
• デジタル フィンガープリント (データ サマリー)、基本原理は、一方向ハッシュ関数 (ハッシュ関数) を使用して情報を操作し、一連の固定長のデジタル サマリーを生成することです。デジタル フィンガープリントは暗号化メカニズムではありませんが、データが改ざんされているかどうかを判断するために使用できます。• ダイジェストの一般的なアルゴリズム: MD5、SHA1、SHA256、SHA512 など。このアルゴリズムは無限を有限にマッピングするため、衝突が発生する可能性があります (2 つの異なる情報、計算されたダイジェストは同じですが、確率は非常に低いです)。• ダイジェスト機能: 暗号化アルゴリズムとの違いは、ダイジェストは復号化がないため厳密には暗号化されていませんが、通常データ比較に使用されるダイジェストから元の情報を推定することが困難であることです。データサマリー/データフィンガープリンティングの適用例 1:Baidu Netdisk に動画をアップロードする場合、数秒でアップロードできる場合もありますが、この素晴らしい転送機能はどのように実現されているのでしょうか。ユーザーがムービーをアップロードすると、Baidu サーバーはアップロードされたムービーを検索して、以前に同じムービーをアップロードしたユーザーがいるかどうかを確認します。以前にサーバーに同じムービーをアップロードしたユーザーがいる場合、このアップロードは終了します。 、ユーザー ディレクトリの下にアップロードされます。前のユーザーがアップロードした同じムービーを指すソフト リンクを作成します。Baidu サーバーは、アップロードされた映画がサーバー上の映画と同じかどうかを迅速に比較および確認するにはどうすればよいですか? 答えは、一方向ハッシュ関数を使用して、アップロードされた映画のデータ概要を作成し、それをサーバー内のすべての映画のデータ概要と比較することです。同じデータ概要がある場合、その映画には、サーバー内の同じリソース。データサマリー/データフィンガープリントの適用例2:ユーザーのパスワードをサーバー内部に平文で保存すると漏洩の危険性が高くなるため、ユーザーのパスワードは暗号化してサーバーに保存するのが一般的であり、一度暗号化したユーザーのパスワードは復号しないことが望ましいです。ハッシュ関数は、パスワードを「暗号化」して保存するのに特に適しています。ユーザーが登録時にアカウントのパスワードを入力すると、サーバーは一方向ハッシュ関数を使用してパスワードを処理し、登録されたパスワードのデータ概要を取得します。ハッシュ関数は、ログインパスワードのデータダイジェストを処理し、データダイジェストを比較します。ログインパスワードと登録パスワードのデータダイジェストを一致させ、両方のデータダイジェストが同じであれば、パスワードが正しいことを意味します。
1.2.5.デジタル署名
• データサマリは平文でネットワーク上に送信しないほうがよく、サマリを暗号化した上でデジタル署名を取得します（詳細はデジタル署名で後述します）。
2. HTTPS の動作プロセスを調べる
データの安全性を確保するため、「暗号化」が必要となります。
ネットワーク伝送においては、平文が直接伝送されるのではなく、暗号化された「暗号文」が伝送されるようになりました。暗号化には多くの方式がありますが、全体として対称暗号化と非対称暗号化の 2 つのカテゴリに分類できます。
2.1.オプション 1 - 対称暗号化のみを使用する
両方の通信当事者が同じ鍵X を保持し、他の誰も知らない場合、当然のことながら、2 つの当事者の通信のセキュリティは(鍵が解読されない限り) 保証されます。
下図に示すように、対称暗号化の導入後は、たとえデータが傍受されても、ハッカーは鍵がわからないため復号できず、リクエストの本当の内容もわかりません。 。
しかし、物事はそれほど単純ではなく、下図に示すように、実際にはサーバーは多くのクライアントに同時にサービスを提供します。クライアントが非常に多い場合、全員が使用する秘密鍵は異なっていなければなりません (鍵が同じだと、鍵が簡単に拡散してしまい、ハッカーが入手してしまう可能性があります)。そのため、サーバーは各クライアントとそれぞれの秘密鍵を管理する必要があります。キーの関係も非常に厄介なものです。
理想的な方法は、クライアントとサーバーが接続を確立するときに、ネゴシエートしてキーが何であるかを決定できることです。ただし、キーが平文で直接送信された場合、次の図に示すように、ハッカーはキーを取得でき、この時点ではその後の暗号化操作は役に立ちません。したがって、キーの送信も暗号化する必要があります。
ただし、キーを対称的に暗号化したい場合は、「キー キー」を決定するためにネゴシエートする必要があり、これは「鶏が先か卵が先か」の問題になります。現時点では、キーの送信と対称暗号化の使用は機能しません。
2.2.シナリオ 2 - 一方の当事者のみが非対称暗号化を使用する
非対称暗号化のメカニズムを考慮すると、サーバーが最初に公開キーを平文でブラウザに送信し、次にブラウザがこの公開キーを使用してデータを暗号化してからサーバーに送信すると、クライアントからサーバーへのチャネルは公開鍵で暗号化されたデータを復号化するための対応する秘密鍵を持っているのはサーバーだけであるため、安全であるように見えます (セキュリティ上の問題があります)。しかし、サーバーからブラウザまでのパスのセキュリティを確保するにはどうすればよいでしょうか?サーバーが秘密キーを使用してデータを暗号化してブラウザに送信すると、ブラウザは公開キーを使用してデータを復号化できます。公開キーは元々ブラウザに平文で送信され、その公開キーを使用してサーバーから送信された情報を復号化できます。 。
2.3. シナリオ 3 - 両側で非対称暗号化を使用する
プラン：
(1) サーバーは公開鍵 S とそれに対応する秘密鍵 S' を持ち、クライアントは公開鍵 C とそれに対応する秘密鍵 C' を持ちます。(2) クライアントとサーバーは公開鍵を交換します。(3) クライアントはサーバーにメッセージを送信します。最初にデータを S で暗号化してから送信します。サーバーだけが秘密鍵 S' を持っているため、このメッセージを復号できるのはサーバーだけです。(4) サーバーはクライアントにメッセージを送信します。まずデータを C で暗号化してから送信します。クライアントだけが秘密鍵 C' を持っているため、このメッセージを復号化できるのはクライアントだけです。双方が非対称暗号化を使用する上記の スキームは安全で実現可能であるように見えますが、実際には次の 2 つの理由により実現不可能です。• 非効率すぎます。双方とも非対称暗号化を使用しますが、これは非常に非効率的です。• セキュリティ上の問題がまだあり、中間者攻撃に抵抗できません (これについては後で詳しく説明します)。
2.4. スキーム 4 - 非対称暗号化 + 対称暗号化
プラン：
(1) サーバーは非対称公開鍵 S と秘密鍵 S' を持っています。(2) クライアントは、https リクエストを開始してサーバーの公開鍵 S を取得します。(3) クライアントは対称鍵 C をローカルで生成し、公開鍵 S で暗号化してサーバーに送信します。(4) 中間ネットワーク装置は秘密鍵を持たないため、データを傍受されても内部の原文を復元することはできず、対称鍵を取得することもできない。(5) サーバーは秘密鍵 S' で復号し、クライアントから送信された対称鍵 C を復元します。そして、この対称キーを使用して、クライアントに返される応答データを暗号化します。(6) クライアントとサーバー間のその後の通信では、対称暗号化のみが使用されます。キーはクライアントとサーバーの 2 つのホストのみが知っているため、他のホスト/デバイスがキーを知らなくてもデータを傍受しても意味がありません。対称暗号化の効率は非対称暗号化の効率よりもはるかに高いため、非対称暗号化は初期段階でキーがネゴシエートされる場合にのみ使用され、その後の送信には対称暗号化が引き続き使用されるため、効率が低いという問題は解決されます 。ただし、上記の 非対称 暗号化 + 対称暗号化方式には 依然として セキュリティ上の問題があり、中間者攻撃に耐えることができません (これについては後で詳しく説明します) 。
2.5.中間者攻撃
中間者攻撃: Man-in-the-Middle Attack、「MITM 攻撃」と呼ばれます。確かに、上記の方式 3 と 4 では、クライアントが公開鍵 S を取得した後、クライアントが作成した対称鍵 X がサーバーからクライアントに与えられた公開鍵 S で暗号化され、たとえ仲介者がデータを盗んだとしても、実際、現時点では、サーバーだけが秘密鍵 S' を持っているため、中間者はクライアントによって形成された鍵 X を解読できません。しかし、中間者攻撃が握手交渉の開始時に実行されるかどうかは、必ずしもそうではありません。中間者攻撃:（１）サーバは、非対称暗号アルゴリズムの公開鍵Ｓと秘密鍵Ｓ'を有する。（２）仲介者は、非対称暗号アルゴリズムの公開鍵Ｍと秘密鍵Ｍ'を保有している。(3) クライアントはサーバーへのリクエストを開始し、サーバーは公開鍵 S を平文でクライアントに送信します。(4) 仲介者はデータメッセージをハイジャックし、公開鍵 S を抽出して保存し、ハイジャックされたメッセージ内の公開鍵 S を自分の公開鍵 M に置き換えて、偽造したメッセージをクライアントに送信します。(5) クライアントはメッセージを受信し、公開鍵 M を抽出し (公開鍵が変更されたことはもちろん知りません)、対称鍵 X を自ら生成し、公開鍵 M で X を暗号化し、メッセージを送信します。サーバーに。(6) 仲介者に乗っ取られた後、自分の秘密鍵 M' で直接復号して通信鍵 X を取得し、保存しておいたサーバ公開鍵 S で暗号化してサーバにメッセージをプッシュします。(7) サーバーはメッセージを取得し、独自の秘密鍵 S' で復号し、通信鍵 X を取得します。(8) 両者は、対称暗号化に X を使用して通信を開始します。しかし、すべては仲介者の手に渡っており、データの乗っ取り、盗聴、さらには改ざんさえも可能です。ここでの中間者攻撃スキームはスキーム 3 にも当てはまります。問題の本質はどこにあるのでしょうか？クライアントは、受信した公開キーを含むデータ メッセージがターゲット サーバーから送信されたものであるかどうかを確認できません。
2.6.証明書のインポート
2.6.1. CA認証
HTTPSを利用する前に、サーバーはCA機関に証明書申請者の情報や公開鍵情報などが含まれるデジタル証明書を申請する必要があります。サーバーは証明書をブラウザに送信し、ブラウザは証明書から公開鍵を取得するだけでよく、証明書はサーバーの公開鍵の権限を証明するIDカードのようなものです。
この証明書は、証明書発行局、証明書の有効期間、公開キー、証明書の所有者、署名などの情報を含む構造化された文字列として理解できます。注意しなければならないことは次のとおりです。• 証明書を申請する場合、特定のプラットフォームでチェックを生成する必要があります。• サーバーは、一対のキーペア、つまり公開キーと秘密キーを同時に生成します。この鍵ペアは、ネットワーク通信における平文の暗号化とデジタル署名に使用されます (後述)。このうち公開鍵は、権威認証のために CSR ファイルとともに CA に送信され、秘密鍵サーバーはその後の通信のために保管します (実際には、主に対称鍵の交換に使用されます)。• CSR と秘密キーはオンラインで生成可能: CSR オンライン生成ツール (myssl.com)
• CSR が形成された後、次は CA に認証を申請します。ただし、一般的な認証プロセスは非常に煩雑です。証明書アプリケーションを提供するインターネット上のさまざまなサービス プロバイダーは、通常、プラットフォームに直接アクセスして問題を解決する必要があります。問題。
2.6.2.データ署名について
• 証明書は結局のところ文字列、つまりデータですが、証明書の正当性をどうやって保証するのでしょうか？証明書と証明書内の公開キーが改ざんされていないことを確認するにはどうすればよいですか? 答えは、証明書を発行するときに証明書のデータ署名を保持することです。これについては、以下で詳しく説明します。• 署名の形成は、非対称暗号化アルゴリズムに基づいています。
署名と検証のプロセス:
• 署名プロセス: まず、元のデータをハッシュして固定長のハッシュ値 (データ サマリー/データ フィンガープリント) を取得します。次に、署名者がそのハッシュ値を自分の秘密鍵で暗号化して署名を取得し、元のデータと取得された署名を結合して、署名を含むデータを取得します。
• 検証プロセス: 検証者は署名付きデータを取得し、まずデータと署名を分離し、次にデータに対してハッシュ処理を実行してハッシュ値 1 を取得し、署名者の公開鍵で署名を復号してハッシュ値 2 を取得します。ハッシュ値 1 とハッシュ値 2 を比較します。2 つのハッシュ値が等しい場合、データと署名が仲介者によって改ざんされていないことを意味します。2 つのハッシュ値が等しくない場合は、等しい場合、データが改ざんされているか、署名が改ざんされているかのいずれかが改ざんされている、またはデータと署名の両方が改ざんされていることを意味します。
• 仲介者が署名を含むデータのデータ部分を改ざんした場合、仲介者は署名者の秘密鍵を持っていないため、署名部分を変更することはできません。つまり、仲介者はデータと署名を改ざんすることはできません。同時に。
• したがって、データにデータ署名を付ける意義は、内容の改ざんを防ぐことにあります。
注: 現時点では https とは関係がないため、https の公開キーと秘密キーと混同しないでください。
サーバーが CA 証明書を申請すると、CA 組織はサーバーを確認し、Web サイトのデジタル署名を作成します。プロセスは次のとおりです。(1) CA 組織は、非対称に暗号化された秘密鍵 A と公開鍵 A' を持っています。(2) CA 機関は、サーバーから適用された証明書データに対してハッシュ処理を実行し、データの要約を作成します。(3) 次に、データ要約を CA 秘密鍵 A' で暗号化し、デジタル署名 S を取得します。サーバーによって適用された証明書の平文とデジタル署名 S が一緒になってデジタル証明書を形成し、デジタル証明書をサーバーに発行できます。注: CA 組織の秘密鍵は自分だけが所有しており、他の人は CA 組織の秘密鍵を持っていないため、CA 組織を真似て証明書を発行することはできません。専ら、それによって発行された証明書が権威を持ちます。
2.7.スキーム 5 - 非対称暗号化 + 対称暗号化 + 証明書認証
クライアントとサーバーが接続を確立するとき、クライアントはサーバーに接続リクエストを送信し、サーバーはサーバーの公開キーと Web サイトの ID 情報を含む証明書をクライアントに返します。クライアントは以下を認証します:クライアントは証明書を取得した後、(証明書の偽造を防ぐために) 証明書を検証します。• 証明書の有効期限が切れているかどうかを確認します (証明書の有効期限が切れている場合、ブラウザは Web サイトの対応する証明書の有効期限が切れていることを通知し、アクセスを続けるかどうかを確認するプロンプトを表示します)。• 証明書発行機関が信頼できるかどうかを確認します (オペレーティング システムに組み込まれている信頼できる証明書発行機関) (証明書発行機関が信頼できない場合、ブラウザは、Web サイトの証明書発行者が信頼できないことを示すプロンプトを表示し、書体にアクセスし続けるかどうかを確認します)。 ）。• 証明書が改ざんされているかどうかを確認します。証明書発行組織の公開鍵をシステムから取得し (証明書を発行する各 CA の公開鍵はシステムに組み込まれています)、署名を復号し、ハッシュ値 (と呼ばれます) を取得します。データダイジェスト）を取得し、それを hash1 に設定し、証明書全体のハッシュ値を計算し、hash2 に設定し、hash1 と hash2 が等しいかどうかを比較し、等しい場合、証明書は改ざんされていないことを意味します。クライアントは証明書からサーバーの公開キーを取得した後、解決策 4 の通信ロジックを実行できます。
ブラウザの信頼できる認証局を確認してください。エッジ ブラウザを例に挙げますが、他のブラウザも同様です。以下の図 1 に示すように、右上隅にある 3 つの点ボタンをクリックし、[設定] を選択します。以下の図 2 に示すように、[プライバシー検索とサービス] -> [セキュリティ] で [証明書管理] をクリックします。信頼できるルート証明機関を選択すると、下の図 3 に示すように、現在のブラウザの 信頼できる。以下の図 4 に示すように、信頼できる証明書発行機関をクリックし、[表示] をクリックして、[詳細] を選択すると、対応する信頼できる証明書発行機関の公開キーが表示されます。
質問 1: 仲介者が証明書を改ざんする可能性はありますか?回答: 仲介者は証明書の平文を改ざんしました。彼は CA 組織の秘密鍵を持っていないため、秘密鍵で暗号化してハッシュ化した後に署名を形成することができません。したがって、一致する署名を形成する方法はありません。改ざんされた証明書について。強制的に改ざんされた場合、クライアントは証明書を受け取った後に、署名の平文と復号化された値が矛盾していることに気づき、証明書が改ざんされており、証明書が信頼できないことを示すため、クライアントへの情報の送信は行われません。情報が仲介者に漏洩しないようにサーバーを停止します。質問 2: 仲介者が証明書全体を削除した場合はどうなりますか?回答: 仲介者は CA 秘密キーを持っていないため、偽の証明書を作成することはできません。そのため、仲介者は CA から本物の証明書を申請し、申請した証明書を使用してパッケージを交換することしかできません。この方法では確かにパッケージ全体の証明書の損失を実現できますが、証明書の平文にはドメイン名などのサーバー認証情報が含まれていることを忘れないでください。パッケージが全体としてパッケージ化されている場合でも、クライアントはそれを認識できます。中間者は CA 秘密キーを持っていないため、自分の証明書も含め、いかなる証明書も合法的に変更できないことに常に注意してください。質問 3: ダイジェスト コンテンツをネットワーク経由で送信するときに、署名を形成するためにダイジェスト コンテンツを暗号化する必要があるのはなぜですか?補足: 一般的なダイジェスト アルゴリズムは次のとおりです: MD5 および SHA シリーズ MD5 を例にとると、署名を計算する具体的なプロセスを学ぶ必要はなく、MD5 の特性を理解するだけで済みます。• 固定長: 文字列の長さに関係なく、計算される MD5 値は固定長です (16 バイト バージョンまたは 32 バイト バージョン)。• 分散: ソース文字列が少し変更される限り、最終的な MD5 値は大きく異なります。• 不可逆性: ソース文字列から MD5 を生成するのは簡単ですが、MD5 を通じて元の文字列を復元することは理論的に不可能です。MD5 がこのような特性を持っているというだけで、2 つの文字列の MD5 値が同じであれば、その 2 つの文字列は同じであると考えることができます。回答: 証明書の改ざんを判断するプロセスを理解します: (このプロセスは、この ID カードが偽の ID カードであるかどうかを判断するようなものです)、証明書が単なる文字列 hello であると仮定し、この文字列のハッシュ値 (md5 など) を計算します。 、結果は BC4B2A76B9719D91 ですが、hello の文字が改ざんされると、たとえば hella になると、計算される md5 値が大きく変化します。次に、文字列 hello とハッシュ値 BC4B2A76B9719D91 をサーバーからクライアントに返すことができますが、このときクライアントは hello が改ざんされているかどうかをどのように確認するのでしょうか? 次に、hello のハッシュ値を計算して、それが BC4B2A76B9719D91 であるかどうかを確認します。しかし、まだ問題があり、ハッカーが hello を改ざんし、同時にハッシュ値を再計算すると、クライアントは違いを見分けることができなくなります。したがって、送信されるハッシュ値は平文では送信できず、証明書の平文 (ここでは「hello」) ハッシュのハッシュ要約を形成するために暗号文で送信する必要があり、CA は独自の秘密キーを使用して暗号化して形成します。 CA 証明書を作成し、サーバーに発行します。クライアントが要求すると、それがクライアントに送信されます。仲介者がそれを傍受します。CA 秘密キーがないため、証明書を取得することはできません。変更されるかパッケージ全体が削除されると、証明書の合法性を安全に証明できます。最後に、クライアントはOSにあらかじめ格納されている証明書発行局の公開鍵で復号し、元のハッシュ値を復元して検証を行います。質問:署名が直接暗号化されず、最初にハッシュされてダイジェストが形成されるのはなぜですか?回答: 署名暗号文の長さを短縮し、デジタル署名と検証署名の計算速度を高速化します。
2.8. 完了プロセス
左側はクライアントの動作、右側はサーバーの動作です。クライアントが特定の Web サイトをリクエストすると、対応するサーバーはクライアントのリクエストの暗号化とハッシュ アルゴリズムを確認し、デジタル証明書をサーバーに返し、サーバーのデジタル証明書を受け取ったクライアントは、デジタル証明書の有効性を検証します。証明書が合法である場合、対称鍵 R を生成し、証明書内の公開鍵を使用して対称鍵 R を暗号化し、それをサーバーに送信します。サーバーは受信した情報を秘密鍵で復号化し、対称鍵 R、これまでのところクライアント サーバーとサーバーは暗号化通信に対称鍵 R を使用できます。
要約:HTTPS の動作プロセスには、次の 3 つのキー グループが含まれます。• 最初のグループ (非対称暗号化) (CA の公開キーと秘密キー): 証明書が改ざんされているかどうかを確認するために使用されます。CA 機関が秘密鍵を保持し、クライアントが公開鍵を保持します (オペレーティング システムには、信頼できる CA 認証機関が含まれており、対応する公開鍵が保持されます)。サーバーはクライアントの要求に応答して署名付き証明書を返し、クライアントは対応する CA 機関の公開キーを使用して証明書を検証し、証明書の有効性を確認し、証明書に含まれるサーバーの公開キーの権限をさらに保証します。• 2 番目のグループ (非対称暗号化) (サーバーの公開キーと秘密キー): 対称暗号化キーのネゴシエーションと生成に使用されます。サーバーは公開キーと秘密キーを同時に保持し、クライアントはサーバー証明書を受信した後にサーバーの公開キーを保持します。クライアントはランダムに生成した対称暗号鍵をサーバー証明書内の公開鍵（信頼できるもの）で暗号化してサーバーに送信し、サーバーは秘密鍵を復号して対称暗号鍵を取得します。• 3 番目のグループ (対称暗号化): クライアントとサーバーによって送信される後続のデータは、この対称キーによって暗号化および復号化されます。実際、すべての鍵はこの対称暗号化キーにあり、他のメカニズムはこのキーの機能を支援します。• 非対称暗号化キーの最初のセットは、クライアントが非対称暗号化公開キーの 2 番目のセットを取得するためのものです。• 非対称暗号化キーの 2 番目のセットは、クライアントがこの対称キーをサーバーに渡すためのものです。
2.9.仲介者になる方法
• ARP スプーフィング: LAN では、ハッカーは ARP 要求ブロードキャスト パケットを受信した後、他のノードの (IP、MAC) アドレスを盗聴できます。たとえば、ハッカーは 2 つのホスト A と B のアドレスを受け取り、B (被害者) に自分が A であることを伝えるため、B から A に送信されたすべてのデータ パケットがハッカーによって傍受されます。• ICMP 攻撃: ICMP プロトコルにはリダイレクション パケット タイプがあるため、ICMP メッセージを偽造し、より適切なルーティング パスであるかのように装って LAN 内のクライアントに送信できます。その結果、ターゲットのすべてのインターネット トラフィックが指定したインターフェイスに送信され、ARP スプーフィングと同じ効果が得られます。• 偽の Wi-Fi や偽の Web サイトなど。