この記事では、主にHTTPSプロトコルの動作プロセスと、公開鍵交換プロセス中に置き換えられる問題を解決する方法について説明します
HTTPSプロトコル対話プロセス
1.クライアントがSSL通信を開始し、メッセージにクライアントでサポートされているSSLバージョン、暗号化コンポーネントなど
が含まれている。2.サーバーがSSL通信をサポートしている場合、メッセージにSSLバージョンと暗号化コンポーネントが含まれており、クライアントが指定したリストから選択される
3.サーバーは公開鍵を送信し
ます4、5、6。公開鍵が正当であることをクライアントが確認した後、クライアントはランダムに鍵を生成し、後続の通信の暗号化鍵として使用され、サーバーの公開鍵を使用してサーバーに送信します。（ランダムにキーを生成する理由は、メッセージを公開キーで暗号化してリソースを消費しすぎるのは複雑すぎるためです）
ステップ3：公開鍵が転送されないようにする方法
デジタル証明書
サーバーがクライアントに公開鍵を送信し、仲介者に置き換えられた場合はどうなりますか？これはより
理解しやすい写真です
公開鍵が調整されている問題は、クライアントが、返された公開鍵がサーバーであるか仲介者であるかを判別できないためです。問題の難しさは、公開鍵をクライアントに直接渡すことを選択した場合、仲介者によって転送される公開鍵の問題を常に解決できるとは限らないことです。
したがって、サーバーの公開鍵をクライアントに直接渡すことはできませんが、サードパーティの組織はその秘密鍵を使用して公開鍵を暗号化してからクライアントに渡します。次に、クライアントはサードパーティ組織の公開鍵を使用して復号化します。これはデータ証明書です。
クライアントは、サーバーから返された証明書を取得した後、サードパーティ組織の公開鍵を使用して、証明書が合法であるかどうかを復号化して判断できます。
デジタル署名
ただし、このサードパーティ組織は多くの人に証明書を発行できるため、この証明書が中間者に置き換えられていないことを確認するにはどうすればよいですか？同じサードパーティ組織である限り、組織の公開鍵は組織が発行したすべてのデジタル証明書を復号化できます。
同じ組織によって発行された異なる証明書
の改ざんの問題を解決するためのデジタル署名。この問題を解決するには、まず問題について考え、同じ組織の下の異なる証明書の責任を特定する必要があります。どこに配置すればよいですか？
クライアントにのみ配置できます。クライアントは証明書を取得した後、証明書が改ざんされていないかどうかを確認できます。どうすればこの能力を持つことができますか？
私たちは実際にインスピレーションを見つけます。たとえば、あなたがHRの場合、候補者の学歴証明書、証明書の所有者、発行機関、発行時刻などを取得します。同時に、証明書には最も重要な証明書番号も含まれます。この証明書の信頼性をどのようにして識別しますか？関係機関にこの証明書番号を携帯して確認する限り、証明書保有者が実際の候補者と一致しており、証明書番号も一致している場合は、証明書が真であることを意味します。
しかし、この「サードパーティ組織」はどこにあるのでしょうか。リモートサービスですか？不可能？それがリモートサービスである場合、対話全体が遅くなります。したがって、このサードパーティ組織の検証機能は、クライアントのローカルにのみ配置できます。
クライアントはどのようにローカルで証明書を検証しますか？答えは、証明書自体がすでに証明書の信頼性を確認する方法をクライアントに伝えているということです。
つまり、証明書の内容に応じて証明書番号を生成する方法が証明書に記載されている。証明書を取得すると、クライアントは証明書の方法に従って自身で証明書番号を生成し、生成された証明書番号が証明書の証明書番号と同じ場合は、証明書が本物であることを意味します。同時に、証明書番号自体が転送されないようにするため、暗号化には第三者の秘密鍵が使用されます。
