序文
HTTPS は、TLS/SSL プロトコルを介した HTTP の暗号化された安全な送信を実装します。TLS/SSL プロトコルは、セキュリティ機能を実現するために主に 3 つのアルゴリズムに依存しています。
非対称暗号化: ID 認証と鍵合意を実装します
対称暗号化: データを暗号化します ハッシュ
関数: 情報の完全性を検証します
対称暗号化、非対称暗号化、および署名については、このドキュメントを参照してください
HTTPS では、対称暗号化と非対称暗号化を組み合わせて使用します。具体的な方法は、
情報を送る側（クライアント）がサーバーの公開鍵を使って「対称鍵」を暗号化し、サーバーが秘密鍵を使って復号して「対称鍵」を取得します。これにより、「対称キー」の送信プロセスが安全になり、その後の暗号化されたデータ送信に「対称キー」を使用できるようになります。
電子証明書認証の具体的なプロセス
サーバーの公開鍵、組織情報、個人情報（ドメイン名）などの情報を第三者機関のCAに提出し、認証を申請します。（実際の運用では、多くの場合、秘密鍵を提供する必要があり、秘密鍵から公開鍵が自動的に抽出されます）
CA は、申請者が提供した情報の信頼性をさまざまな手段を使用して検証します。組織が存在するかどうか、企業が合法であるかどうか、ドメイン名を所有しているかどうかを確認します。情報が検討され承認されると、CA は申請者に認証文書証明書を発行します。
証明書には、申請者の公開鍵、申請者の組織情報および個人情報、発行局 CA の情報、有効期限、証明書のシリアル番号の平文などの情報が含まれており、署名も含まれています。署名生成アルゴリズム: まず、ハッシュ関数を使用して公開平文情報の情報ダイジェストを計算し、次に CA の秘密キーを使用して情報ダイジェストを暗号化し、暗号文が署名になります。
クライアントがサーバーにリクエストを送信すると、サーバーは証明書ファイルを返します。
クライアントは、証明書内の関連する平文情報を読み取り、同じハッシュ関数を使用して情報ダイジェストを計算し、次に、対応する CA の公開キーを使用して署名データを復号化し、証明書の情報ダイジェストを比較します。 、証明書が正当であることが確認できます。
クライアントは、ドメイン名情報、有効期限、および証明書に関連するその他の情報も検証します。クライアントには、信頼できる CA 証明書情報 (公開キーを含む) が組み込まれています。CA が信頼できない場合、その CA に対応する証明書は、が見つからず、証明書も違法と判断されます。
HTTPS ワークフロー
1. クライアントは HTTPS リクエストを開始します。
2. サーバーは、構成された証明書をクライアントに返します。
3. クライアントは証明書を検証します。たとえば、証明書が有効期間内であるかどうか、証明書の目的がクライアントによって要求されたサイトと一致するかどうか、CRL 失効リストに含まれているかどうか、上位レベルの証明書が有効であるかどうかなどです。 、など。 4. クライアントは
、証明書内のサーバーの公開キーによって暗号化された擬似乱数生成対称キーを使用します。この対称キーは、その後、情報の送信に使用されます。
5. サーバーは独自の秘密キーを使用してメッセージを復号化し、対称キーを取得します。この時点で、クライアントとサーバーの両方が同じ対称キーを保持します。
6. サーバーは対称キーを使用して「平文コンテンツ A」を暗号化し、クライアントに送信します。
7. クライアントは対称鍵を使用して応答の暗号文を復号し、「平文コンテンツ A」を取得します。
8. クライアントは再度 HTTPS リクエストを開始し、対称キーを使用して要求された「平文コンテンツ B」を暗号化し、サーバーは対称キーを使用して暗号文を復号し、「平文コンテンツ B」を取得します。
これにより、暗号化された通信が維持されます。
参考ドキュメント：https://github.com/ljianshu/Blog/issues/50