HTTP リクエストの構築方法と HTTPS の動作プロセス

1. HTTP リクエストの作成方法:

HTML/JS ベース(クライアントは HTTP リクエストを構築します。最も一般的な HTTP クライアントはブラウザです)
- formフォームベース
- に基づくajax
Java ベース(このソリューションは完全に実現可能ですが、実際の開発では上記の方法ほど使用されません)
- に基づくsocket

1. フォームに基づいて HTTP リクエストを構築します

1.1、フォーム

form は HTML の一般的なタグであり、サーバーに GET または POST リクエストを送信するために使用できます。

フォームの重要なパラメータ:

action: 構築されたHTTPリクエストがどのサーバーに送信されるか、URLです
method: 構築された HTTP リクエストメソッドが GET か POST か (フォームは GET と POST のみをサポートし、大文字と小文字は区別されません)

この form タグだけでは送信できず、送信するものが何もないため、
input などのフォーム内の他のタグとも一致させる必要があります。

入力の重要なパラメータ:

type: 入力ボックスのタイプを示し、「text 表示文本， password 表示密码，submit」は送信ボタンを示します。
value: input タグの値。submit タイプの場合、値はボタンに表示されるテキストに対応します。
name: ID やクラスではなく、name 属性はスタイルとは関係ありません。from フォームによってサーバーに送信されるデータは、基本的にキーと値のペアです。ここでの名前は、構築された HTTP リクエストのクエリ文字列のキーを表し、クエリ文字列の値は、ユーザーが入力ボックスに入力した内容です。

<input type="text" name="username"> <!-- key 就是 username，value 就是用户在输入框输入的内容 -->
<input type="password" name="password"> <!-- key 就是 password，value 就是用户在输入框输入的内容 -->

ここでユーザーが入力したユーザー名が zhangsan で、パスワードが 123 であると
します。このとき、フォームフォームによって生成される送信データは、username=zhangsan&password=123 という形式になります。

入力ボックスが 2 つあるだけでは十分ではなく、ここで HTTP リクエストをトリガーするための「送信ボタン」も必要です。

1.2. リクエストの取得

<form action="http://www.sogou.com/index.html" method="get">
    <input type="text" name="username">
    <input type="password" name="password">
    <input type="submit" value="提交">
</form>

ここでのクエリ文字列は、ページによってサーバーに送信されるデータそのものです。

1.3. リクエストの投稿

<form action="http://www.sogou.com/index.html" method="post">
    <input type="text" name="username">
    <input type="password" name="password">
    <input type="submit" value="提交">
</form>

現時点では、URL に名前はありません。

ここに画像の説明を挿入します

リクエストの表示:

ここに画像の説明を挿入します

注: lisi 123 に変更しても、送信は Sogou のホームページのままです。現在、そのようなリクエストは Sogou のホームページに直接送信されますが、Sogou はそのようなパラメーターを処理しません。独自のサーバーを作成する場合、独自のサーバーはそれを次のサーバーに送信できます。フロントエンド
パラメータを処理することで、いくつかの異なる機能を実現できます。

2. Ajax が HTTP リクエストを構築します

2.1、アヤックス

フォームフォームはより原始的な構築方法であり、フォームを使用すると必ずページジャンプが発生し、
ブラウザは新しいページを読み込む必要があります。

この問題は、特にページが非常に複雑な場合には非常に非科学的です。
フロントエンドページがますます複雑になるにつれて、ページがページ全体をロードするのではなく、変更が必要なページのごく一部だけをロードすることを望みます。。

この場合、ajax を使用できます。JavaScript
では、ajax を通じて HTTP リクエストを構築し、js コードを使用してレスポンスを処理し、取得したデータの一部をページに更新できます。

ajax の正式名称は、Asynchronous Javascript And XMLJavaScript がサーバーに HTTP リクエストを送信するために 2005 年に提案されたメソッドです。

ページ更新・ページジャンプをせずにデータを転送できるのが特徴です。

2.2. 非同期

非同期の概念は、コンピューターでは非常に一般的な概念です。ここで説明する同期とロックのセクションで説明する同期は同期ではなく、コンテキストによって異なる意味を持つコンピューター用語です。

たとえば、彼女と出かける約束をするとき、私が先に到着し、彼女を先に待ちます。ここでの待機は同期待機です。私が発信者で、私のガールフレンドが受信者です。発信者は常にそこにいます。ここで待って、呼び出し先の結果を取得するために率先してください

非同期で待っているとき、私は彼女に、「しばらく携帯電話で遊べる涼しい場所を見つけます。降りたら電話してください。発信者が通話要求を開始した後、発信者は通話要求を開始するまでそれを無視します」と伝えました。呼び出し先の結果が出ると、呼び出し元に積極的に通知します

同期待機中:

ブロックされた状態で待っています (会えるか会わないか)

ノンブロッキングで待機します (結果を時々クエリします)

もう一つの例は、食事に行って店に来たときです。「上司、卵入りチャーハンを食べてください。」

同期ブロッキング待機:
私はここのフロントデスクにしゃがみ込み、キッチンを見ながら料理をします。食事の準備ができるまで、自分で取り除きます。
同期ノンブロッキング待機：
フロントを見たら食事の準備ができていなかったので散歩に出かけ、しばらくしてフロントに戻って確認したら食事が
まだだった準備ができていない携帯電話をいじりに行った...数回後、食事の準備ができていることに気づき、自分で持ち帰りました。
非同期待機:
何も気にせず、左下の隅を見つけたり、携帯電話をいじったり、やるべきことは何でもやるだけで、食事の準備ができたら、人々が直接私にそれを提供します
。

方法 2 と方法 3 の両方を使用すると、待機中に他のことを行うことができます。
違いは、2 番目の方法は呼び出し側(結果を繰り返しクエリする) にとってコストがかかるのに対し、3 番目の方法の方が優れている場合が多いことです。

IO シナリオでは、多くの場合
、コンソールを介した入出力、ファイルを介した入出力、ネットワークを介した入出力の 3 つの状況が関係します。

スキャナ、入力ストリームオブジェクト、および出力ストリームオブジェクト、デフォルトでは同期ブロックおよび待機

Ajax は非同期待機を使用します

同期と非同期: 主な違いは、呼び出し元が結果に積極的に注意を払うか、呼び出し先が呼び出し元に通知するかどうかにあります。

ブロッキングとノンブロッキング: 違いは、待機中に他のことができるかどうかです。

2.3. Ajaxリクエスト

Ajax は非同期待機に基づいています。

まず HTTP リクエストを作成し、サーバーに送信します。
しかし、ブラウザはサーバーがいつ応答するかわからないため、現時点ではサーバーを無視し、ブラウザ内で他のコードを実行し続けます（必要なことは何でも）
サーバーの応答が返されると、ブラウザは対応する JS コードを通知し、コールバック関数の形式で応答を処理します。

これは、ネイティブ JS の ajax を介してリクエストを構築し、レスポンスを処理するものです。ネイティブの記述方法は非常に面倒で抽象的で理解しにくいです。よりシンプルで理解しやすい方法を使用して、jQuery の ajax に基づいた関連コード
を示します。
Shao は、JS の世界で最もよく知られたライブラリ (誰も) です。js における jQuery の地位は、Java における Spring の地位と同等です。近年、jQuery の脚光は、いくつかの新しい JS フレームワークに奪われています。Shao の 3 つの主要なフレーム
ワーク、Vue、React、Angela

ここに画像の説明を挿入します

jQueryを導入します。

まず、検索エンジンで jquery cdn クエリ用語を検索します。
結果から、適切な CDN URL を見つけます。
対応する URL を開いて jquery オントロジーをロードします
投稿したコンテンツをローカルファイルにコピーする

http://libs.baidu.com/jquery/2.0.0/jquery.min.js

ここに画像の説明を挿入します

jQueryを使用したAjax:$

変数名。js が許可します。$変数名の一部として、これは$jquery のコアオブジェクトです。jquery のさまざまな API が$トリガーされます。

$.ajax ({
    
    
	
});

ajax 関数は $ オブジェクトを通じて呼び出されます。パラメータは 1 つだけですが、それは「オブジェクト」です

オブジェクト内の値:

type: HTTP リクエストのメソッドを示します。GET と POST だけでなく、PUT や DELETE などの他のメソッドもサポートします。
url: HTTPリクエストのURL
success：コールバック関数に相当このコールバック関数はHTTPレスポンスを正しく取得した後に呼び出される非同期処理です。

ここで、ajax パラメータには他の値も指定できます: jQuery ajax - ajax() メソッド

<script src="jquert.js"></script>
<script>
    $.ajax ({
    
    
        type: 'get',
        url: 'http;//www.sogou.com/index.html',
        success: function(body) {
    
    
            // 回调函数的参数就是 HTTP 响应的 body 部分
            console.log("获取到响应数据！" + body);
        },
        error: function() {
    
    
            // error 也对应一个回调函数 会在请求失败后触发 也是异步
            console.log("获取响应失败！");
        }
    });
</script>

先ほどの ajax リクエストでは、パケットキャプチャからレスポンスが200 OKで、ボディも html データであることがわかります。

しかし、ブラウザはこれが「エラー」リクエストであるとまだ考えています。

ここに画像の説明を挿入します

このエラーの理由は、ブラウザーがajax が複数のドメイン名/複数のサーバー間でクロスドメインアクセスを実行することを禁止しているためです。

現在のページが配置されているサーバーはローカルファイルであり、ページ内で ajax によってリクエストされた URL、ドメイン名は www.sogou.com です。

現在のページが配置されているサーバーは www.sogou.com にあります。次に、ページは ajax を通じて URL を要求します。ドメイン名は www.sogou.com です。これはクロスドメインとみなされません。

上記の動作はブラウザによる制限です。もちろん、この制限を回避する方法もあります。
他のサーバーから返された応答に関連する応答ヘッダーが含まれており、クロスドメイン操作が許可されている場合は、ブラウザで正常に表示できます。。

そのため、今作成している ajax リクエストは正しく処理できません。いつになったら正しく処理できるようになるでしょうか? 必要なのは独自のサーバーを用意し、ページと ajax のアドレスが両方ともこのサーバーになるようにするだけです。

3. Java ソケットを介して HTTP リクエストを構築する

Java は、主に TCP ソケットに基づいて HTTP リクエストを構築し、HTTP リクエストのメッセージ形式に従って、一致する文字列を構築してソケットに書き込みます。

実際の開発では、http リクエストが Java に基づいて構築される状況が実際にいくつかありますが、これはサードパーティのライブラリに基づいて直接実装でき、必ずしもソケットを直接使用する必要はありません。

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.Socket;

public class HttpClient {
    
    
    private Socket socket;
    private String ip;
    private int port;

    public HttpClient(String ip, int port) throws IOException {
    
    
        this.ip = ip;
        this.port = port;
        socket = new Socket(ip, port);
    }

    public String get(String url) throws IOException {
    
    
        StringBuilder request = new StringBuilder();
        // 构造首行
        request.append("GET " + url + " HTTP/1.1\n");
        // 构造 header
        request.append("Host: " + ip + ":" + port + "\n");
        // 构造 空行
        request.append("\n");
        // 发送数据
        OutputStream outputStream = socket.getOutputStream();
        outputStream.write(request.toString().getBytes());
        // 读取响应数据
        InputStream inputStream = socket.getInputStream();
        byte[] buffer = new byte[1024 * 1024];
        int n = inputStream.read(buffer);
        return new String(buffer, 0, n, "utf-8");
    }

    public String post(String url, String body) throws IOException {
    
    
        StringBuilder request = new StringBuilder();
        // 构造首行
        request.append("POST " + url + " HTTP/1.1\n");
        // 构造 header
        request.append("Host: " + ip + ":" + port + "\n");
        request.append("Content-Length: " + body.getBytes().length + "\n");
        request.append("Content-Type: text/plain\n");
        // 构造 空行
        request.append("\n");
        // 构造 body
        request.append(body);
        // 发送数据
        OutputStream outputStream = socket.getOutputStream();
        outputStream.write(request.toString().getBytes());
        // 读取响应数据
        InputStream inputStream = socket.getInputStream();
        byte[] buffer = new byte[1024 * 1024];
        int n = inputStream.read(buffer);
        return new String(buffer, 0, n, "utf-8");
    }

    public static void main(String[] args) throws IOException {
    
    
        HttpClient httpClient = new HttpClient("42.192.83.143", 8080);
        String getResp = httpClient.get("/AjaxMockServer/info");
        System.out.println(getResp);
        String postResp = httpClient.post("/AjaxMockServer/info", "this is body");
                System.out.println(postResp);
    }
}

Javaを使用して構築されたHTTPクライアントに「クロスドメイン」の制限がなくなりました。この時点で、他のサーバーからデータを取得するためにも使用できます。クロスドメインは単なるブラウザの動作です。ajaxでは有効です。その他の言語の
場合、一般的にはクロスドメインと同じです。

HttpClient httpClient = new HttpClient("www.sogou.com", 80);
String resp = httpClient.get("/index.html");
System.out.println(resp);

// 此时可以获取到 搜狗主页 的 html

標準の http リクエストヘッダーで、正しいステートメントは次のうちどれですか (ABCD)

A.User-Agent: ユーザーのオペレーティングシステムとブラウザのバージョン情報を宣言します。

B.Content-Type: データ型

C.ホスト: クライアントはサーバーに、要求されたリソースがどのホストとどのポート上にあるかを伝えます。

D.location: クライアントに次に訪問する場所を伝えるために 3xx ステータスコードとともに使用されます。

2.HTTPS

1. オペレーターのハイジャック

HTTPS もアプリケーション層プロトコルです。HTTPS は HTTP の双子の兄弟に相当し、 HTTP プロトコルに基づいた暗号化層を導入しています。

HTTP プロトコルのコンテンツはクリアテキストで送信されるため、送信プロセス中に改ざんが発生する可能性があります。

悪名高い「キャリアハイジャック」:

毎日曲をダウンロード

エフェクトはハイジャックされません。ダウンロードボタンをクリックすると、Tiantiandongting のダウンロードリンクがポップアップ表示されます。

エフェクトがハイジャックされているので、ダウンロードボタンをクリックすると、QQ ブラウザのダウンロードリンクがポップアップします。

ここに画像の説明を挿入します

オペレーターだけでなく、他のハッカーも同様の手段を使ってユーザーの個人情報を乗っ取ったり、コンテンツを改ざんしたりする可能性があり、ハッカーがユーザーが
Alipay にログインするときにユーザーのアカウント残高を取得したり、ユーザーの支払いのパスワードを取得したりする場合を想像してみてください。 …

インターネットでは、平文での送信は比較的危険です。

HTTPS は HTTP に基づいて暗号化され、ユーザー情報のセキュリティをさらに確保します。

2. 暗号化

暗号化は、平文(送信する情報) に一連の変換を実行して **暗号文**を生成することです。
復号化は、暗号文に一連の変換を実行して平文に復元することです。

この暗号化と復号化のプロセスでは、多くの場合、このプロセスを支援するために 1 つまたは複数の中間データが必要になります。このようなデータはキーと呼ばれます(正しくは 4 声で「ユエ」と発音されますが、通常、誰もが 4 声で「ヤオ」、または「シ」と発音します) )

暗号化と復号化は現在、独立した分野として発展しています:暗号学.
暗号学の創始者は、コンピューターサイエンスの創始者の 1 人でもあるアランマセソンチューリングです。

ここに画像の説明を挿入します

私たちのもう一人の祖先であるフォン・ノイマンと比較してください。

ここに画像の説明を挿入します

チューリングは、コンピューター、人工知能、暗号学の基礎を築いただけでなく、第二次世界大戦でドイツのエニグマ機械を破壊し、連合軍に情報上の優位性を与え、敗北を勝利に変えた若く有望な男でした。英国王室から批判、迫害され41歳で死去、チューリングの物語を描いた映画「イミテーション・ゲーム」、
コンピューティング分野における最高の栄誉は彼の名を冠した「チューリング賞」である。

第83回の《頤和園炎上》では、何者かが西太后を謀殺しようとしており、西洋化運動の代表の一人である恭儀信公が西太后に冊子を手渡した。ほんの少しの家庭用品だけで、穴の開いたものが巻かれていました。本当の意味は紙で見ることができます

平文: 送信する元のメッセージ「崇順、端化、戴恒に気をつけろ」 (崇順、端化、戴恒は生前に老皇帝によって任命された補佐官であり、後に西渓に引き継がれた) ）

暗号文：追悼文全文他人が入手しても暗号文は何も見ることができません。

キー: キーを使用して平文を暗号文に変換したり、暗号文を平文に復元したりできます。これは穴の開いた紙です。

3. HTTPSの動作プロセス

暗号化と復号自体は数学と密接に関係する問題であるため、
ここでは「プロセス」について簡単に説明するだけで、暗号化と復号の「実装の詳細」については説明できません。

暗号化後は、絶対に安全というわけではありません。それは、解読するには非常に計算量が多く、コストがかかるということだけです
。一部のデータが暗号化された後は、現時点で最も強力なコンピューターを使用したとしても、解読するには数十年、数百年かかります。クラッキングにかかるコストがデータ自体の価値よりも高い限り
、安全であると考えられています（偽紙幣を作るギャングがいますが、彼らは紙幣探知機がまったく区別できないほど、偽紙幣を作るのが上手です。） ..ただし、偽の 100 元紙幣を作ります。実際のコストは 110 元です...)

HTTPSで導入された暗号化層はSSL（旧名）/ TLS（新名）と呼ばれます。

SSL では、実際には主に次の 2 つの方法で暗号化操作が行われます。

対称暗号化: 暗号化と復号化の両方に同じキーを使用します。
非対称暗号化

3.1. 対称暗号化

対称暗号化では、実際には同じ「鍵」を使用して平文を暗号文に暗号化し、暗号文を平文に復号することもできます。

シンプルな対称暗号化、ビットごとの XOR

平文 a = 1234、キー key = 8888 と仮定します。

この場合、^ キーを暗号化して得られる暗号文 b は 9834 になります。

次に、暗号文 9834 に対して操作 b ^ key を再度実行すると、結果が元の平文 1234 になります。

(文字列の対称暗号化にも同じことが当てはまり、各文字は数値として表すことができます)

もちろん、ビットごとの XOR は最も単純な対称暗号化にすぎず、HTTPS ではビットごとの XOR は使用されません。

ここに画像の説明を挿入します

クライアントとサーバーは同じキーを保持します

クライアントによって送信されるデータ (HTTP リクエストのヘッダーと本文) は、このキーを使用して対称的に暗号化され、ネットワーク上で実際に送信されるのは暗号文です。

サーバーは暗号文を受信すると、先ほどのキーに基づいて暗号文を復号し、平文を取得できます。

上記のプロセスは非常に優れているように見えますが、致命的な欠陥があります。
クライアントとサーバーが同じキーを保持していることを確認するにはどうすればよいでしょうか?特に 1 つのサーバーが多数のクライアントに対応する場合はどうすればよいでしょうか。

ここに画像の説明を挿入します

明らかに、異なるクライアントは異なるキーを使用する必要があります。
各クライアントが同じキーを持っている場合、ハッカーにとってこのキーは非常に簡単に入手できます (ハッカーはクライアントを起動するだけで済みます...)

異なるキーが必要となるため、サーバーは異なるクライアントのキーが何であるかを記録できる必要があり
、そのキーはクライアントとサーバーの間で受け渡される必要があります。

異なるクライアントは異なるキーを必要とするため、クライアントがアクティブにキーを生成してサーバーに通知するか、サーバーがキーを生成してこのキーをネットワーク経由で送信する必要があることをクライアントに通知します。

ここに画像の説明を挿入します

この図では、クライアントがキーを生成し、クライアントがネットワークを通じてサーバーにキーを伝える必要があると想定しています。

クライアントはキー 888888 を生成し、クライアントはサーバーにキーが 888888 であることを伝える必要があります。

デバイスはずっと前にハッキングされている可能性があるため、
キーは何ですか? クリアテキストで送信される場合、ハッカーは簡単に入手できます。ハッカーがキーを知っている場合、その後の暗号化は無駄になります。

3.2. 非対称暗号化

上記の説明を踏まえると、対称暗号化を使用する場合の最大の問題は、キーを渡せる必要があることです。平文で渡された場合は機能せず、キーを再度暗号化する必要があります。

この問題を解決する鍵となるのが、非対称暗号化の導入です。

非対称暗号化には、公開キーと秘密キーと呼ばれる 2 つのキーがあります。

公開キーは誰もがそれを入手できることを意味します
秘密鍵はあなただけが知っています

公開キーを使用して暗号化し、秘密キーを使用して復号化すること
も、秘密キーを使用して暗号化し、公開キーを使用して復号化することもできます。

公開キーと秘密キーを直観的に理解します。

多くのコミュニティでは、ユニットのドアに「郵便ポスト」があります。

あなたは鍵とたくさんの錠前を持っているので、これらの錠前をメッセンジャーボーイに渡します。

すべての手紙配達員はこの鍵を使って郵便受けに手紙を閉じ込めることができ、鍵を持っているあなただけが箱を開けて手紙を取り出すことができます。

ここでの錠前が公開鍵に相当し、手に持っている鍵が秘密鍵に相当します。

非対称暗号化に基づいて、サーバーは公開鍵と秘密鍵のペアを独自に生成でき、公開鍵は送信され (誰もが取得できます)、秘密鍵は独自に保管されます。

クライアントは対称キーを生成し、サーバーの公開キーを使用して対称キーを暗号化し、データをサーバーに送信し、サーバーは秘密キーを使用してデータを復号します。

ここに画像の説明を挿入します

サーバーは秘密キーを保持し、クライアントは公開キーを保持します。ハッカーは公開キーを取得できますが、秘密キーは取得できません。

クライアントは対称キーを生成した後、公開キーに基づいて対称キーを暗号化できます。

ハッカーが暗号文を取得した場合、秘密鍵を持たず、対称鍵が何であるかわからないため、暗号文を復号化できません。

非対称暗号化は非常に簡単に使用できるのに、なぜ対称暗号化が必要なのでしょうか? 非対称暗号化を直接使用するだけでよいのでしょうか?

実際の実装では、対称暗号化の計算オーバーヘッド << 非対称暗号化

行き来の頻度が少ない場合は、この非対称暗号化を使用するとコストも悪くありません

しかし、すべてのデータが非対称的に暗号化されると、コストが高くなりすぎます。

3.3. 中間者攻撃

上記のプロセスは完璧に見えるかもしれませんが、そうではありません。ここにはまだ大きな穴があります！

サーバーはその公開キーをクライアントに返す必要がありますが、この操作では非常に古典的な「中間者攻撃」が関与する可能性があります。

通常の状況:

ここに画像の説明を挿入します

中間者攻撃:

ここに画像の説明を挿入します

中間者攻撃の鍵は、ハッカー自身が公開鍵と秘密鍵のペアを生成することです。

サーバーからクライアントに返された公開キーをインターセプトし、自分で生成した公開キーに置き換えます。

ハッカーが対称キーの暗号文を傍受した後、暗号文は公開鍵 2 を使用して暗号化されているため、ハッカーは秘密鍵 2 を使用して復号化できます!!! ハッカーは対称鍵 888888 を取得します。

その直後、ハッカーは身を隠すため、事前にサーバーから取得した公開鍵を使用して888888を暗号化し、別の暗号文を取得してサーバーに返しました。

3.4. 証明書の導入

中間者攻撃があるため、この問題をどのように解決すればよいでしょうか?
重要な点は、現在の公開キーがサーバーからのものであり、ハッカーによって偽造されたものではないことをクライアントが確認できるようにすることです。

考えてみてください、人生における他のシナリオはどのように検証されるのでしょうか?
たとえば、インターネットカフェに行ったり、小さなホテルに滞在したりする場合、身元を登録する必要があります。

本人確認方法は? ID カードをお持ちです

ネットワーク管理者があなたの ID カードを受け取り、それをスワイプすることで、実際に公安局の関連サーバーにアクセスし、あなたの身元情報を確認します。

したがって、公開鍵が正規の公開鍵であることを証明するには、第三者の公的信頼機関を導入する必要があります。

私たちはこの公的信頼機関を信頼しており (jc を信頼しているのと同じように)、公的信頼機関が公開鍵は問題ないと言っているため、公開鍵は信頼できると考えることができます。

ここに画像の説明を挿入します

サーバーが初めてオンラインになったら、CA 組織に行って証明書を申請する必要があります!
その後、サーバー自体によって生成された公開キーがこの証明書に配置されます (データの一部です)。

クライアントとサーバーが最初に接続を確立すると、サーバーは先ほどの公開鍵と Web サイトの ID 情報を含む証明書をクライアントに返します。

この証明書は、次の情報を含む構造化された文字列として理解できます。

証明書発行局

証明書の有効期間

公開鍵

証明書の所有者

サイン

…

ハッカーがクライアント側で証明書を偽造する可能性もあります。

クライアントはこの証明書を取得すると、(証明書の偽造を防ぐために) 証明書を検証します。

クライアントはこの証明書が妥当かどうかをどのように確認しますか?

証明書自体にはいくつかの検証メカニズムがあります
公的信託機関に検証を求める

ハッカーが証明書を偽造すると、その時点で秘密が暴露され、ブラウザに警告がポップアップ表示されます。

証明書の有効期限が切れているかどうかを確認する

証明書の発行局が信頼できるかどうかを確認します (オペレーティングシステムに組み込まれている信頼できる証明書発行局)。

証明書が改ざんされているかどうかを確認する: システムから証明書発行局の公開キーを取得し、署名を復号し、ハッシュ値 (データダイジェストと呼ばれる) を取得し、 hash1 として設定し、証明書全体のハッシュ値を計算します。 , hash2 に設定します。hash1 と hash2 を比較して、それらが等しいかどうかを確認します。
等しい場合は、証明書が改ざんされていないことを意味します。

検証のために毎回この公的信頼組織を訪問するのは面倒ではないでしょうか?
実際、クライアント自体には、サーバーネットワーク経由で要求しなくても、クライアント自体に公的信頼組織の情報 (オペレーティングシステムに組み込まれています) が含まれています。現地で行うこと（ここは非常に優れたインターネットカフェのようなもので、公安局が直接JCを派遣してここに長期駐在させます）

上記に挙げたものはすべて SSL に含まれており、SSL は HTTPS に適用されるだけでなく、他の多くの場所でも使用されます。

この暗号化プロセス全体により、データの傍受を防ぐことが期待されますが、さらに重要なのは、データの改ざんを防ぐことです。

HTTP データは暗号化されているのに、なぜ Fiddler は HTTPS のデータグラムをキャプチャして解析できるのでしょうか?

fiddler がパケットをキャプチャできる理由は、fiddler をインストールした後、初めて HTTPS 機能を有効にしたときに表示されるダイアログボックスと密接に関係しています。

重要なのは操作であり、実際にはオペレーティングシステムが fiddler によって提供された証明書を信頼できるようにすることです。

これはユーザーが Fiddler を承認するのと同等であり、Fiddler が「中間者攻撃」を実行できるようになります。

ブラウザの信頼できる証明書発行機関を確認します。Chrome
ブラウザの右上隅にある [設定] をクリックし、[証明書管理] を検索すると、次のインターフェイスが表示されます。

ここに画像の説明を挿入します

データのダイジェスト/署名を理解する:

今後、私たちがこの業務に参加する際、「払い戻し」のシナリオに関わることが多くなります。請求書を受け取り、払い戻しをしたい場合は、リーダーの承認が必要です。ただし、リーダーは財務部門に一緒に行くことはできません
。。私たちは何をすべきか？

それは非常に簡単です。リーダーに署名を依頼するだけです。財務担当者がリーダーの署名を見たとき、彼は「その人を見るのと同じように言葉を見ます」。人が異なれば、「署名」も大きく異なります。署名を使用すると、次のことが可能になり
ます。特定の人をある程度区別する、特定の人。

同様に、データの一部 (文字列など) に対して、特定のアルゴリズムを使用して、
この文字列の「署名」を生成することもできます。そして、生成された「署名」がデータごとに大きく異なることを確認します。次のように使用します。署名は、異なるデータをある程度まで区別できます。

署名を生成するための一般的なアルゴリズムには、MD5 および SHA シリーズが含まれます。MD5 を
例にとると、署名を計算する具体的なプロセスを検討する必要はありません。MD5 の特性を理解するだけで済みます。

固定長: 文字列の長さに関係なく、計算される MD5 値は固定長です (16 バイトバージョンまたは 32 バイトバージョン)。

分散: ソース文字列が少し変更される限り、最終的な MD5 値は大きく異なります。

不可逆: ソース文字列から MD5 を生成するのは簡単ですが、MD5 を通じて元の文字列を復元することは理論的に不可能です。

MD5 にはこのような特性があるため、 2 つの文字列の MD5 値が同じであれば、その 2 つの文字列は同じであると考えることができます。

証明書が改ざんされているかどうかを判断するプロセスを理解します: (このプロセスは、ID カードが偽の ID カードであるかどうかを判断するようなものです)

証明書が単純な文字列 hello であると仮定します。この文字列のハッシュ値 (md5 など) を計算すると、結果は
BC4B2A76B9719D91になります。

hella など、hello の文字が改ざんされると、計算された md5 値が大きく変化します
。

次に、文字列 hello とハッシュ値 BC4B2A76B9719D91 をサーバーからクライアントに返すことができますが、このとき
クライアントは hello が改ざんされているかどうかをどのように確認するのでしょうか?

次に、hello のハッシュ値を計算して、それが BC4B2A76B9719D91 であるかどうかを確認します。

しかし、別の問題があり、ハッカーが hello を改ざんしてハッシュ値を再計算した場合、クライアントは違いを見分けることができなくなります。

したがって、送信されるハッシュ値は平文を送信することはできず、暗号文を送信する必要があります。

このハッシュ値は、別の秘密キーを使用してサーバー側で暗号化されます (この秘密キーは、クライアントとサーバーの間で対称キーを送信するために使用される秘密キーではなく、証明書を申請するときに証明書発行局によってサーバーに与えられます)。

次にクライアントは、オペレーティングシステムに既に保存されている証明書発行局の公開キーを使用してそれを復号し、元のハッシュ値を復元して
検証します。