HTTPS通信の原理は何ですか?

HTTPS 通信原理: HTTPS は「HTTP over SSL/TLS」です。HTTP と比較して、HTTPS には「SSL/TLS」の層がもう 1 つあります。HTTPS では、データを送信する前にクライアントとサーバー間の交換が必要です。 . ハンドシェイク: ハンドシェイク プロセス中に、送信データを暗号化するために双方が使用する暗号情報が確立されます。

概要:

HTTP プロトコル (ハイパーテキスト転送プロトコル、ハイパーテキスト転送プロトコル): クライアントです。ブラウザまたは他のプログラムと Web サーバー間のアプリケーション層通信プロトコル。 HTTPS (正式名: HyperText Transfer Protocol over Secure Socket Layer) は、HTTP に SSL 層を追加した HTTP SSL/TLS と理解できます。HTTPS のセキュリティ基盤は SSL であるため、暗号化の詳細には安全性を確保するために SSL が必要ですHTTP データの送信。

HTTPS と HTTP の違い:

a. https プロトコルでは、CA から証明書を申請する必要があります。一般に、次のものがあります。無料の証明書はほとんどなく、料金を支払う必要があります。

b. http はハイパーテキスト転送プロトコルであり、情報は平文で送信されます; https は安全な SSL 暗号化送信プロトコルです。

c. http と https では接続方法がまったく異なり、使用するポートも異なります (前者は 80、後者は 443)。

d. http 接続は非常にシンプルでステートレスです。HTTPS プロトコルは、SSL HTTP プロトコルから構築されたネットワーク プロトコルで、暗号化された送信と ID 認証を実行でき、HTTPS プロトコルよりも安全です。 http プロトコル。

HTTPS の役割

その主な機能は 2 つのタイプに分類できます。1 つは、データ送信を確実にするための情報セキュリティ チャネルを確立することです。セキュリティ、もう 1 つは Web サイトの信頼性を確認することです。

a．一般的な意味では、https はサーバーが証明書を持っていることを意味します。主な目的は、サーバーが本来のサーバーであることを確認することです。これは最初の点と同じで、サーバーとクライアント間のすべての通信が暗号化されます。

b. 具体的には、クライアントは対称キーを生成し、サーバーの証明書を介してキーを交換しますが、これは一般的な意味でのハンドシェイク プロセスです。この部分については、以下で詳しく紹介します。

c. その後のすべての情報交換は暗号化されます。第三者が傍受したとしても鍵を持っていないので意味がありませんし、もちろん改ざんしても意味がありません。

d．クライアントに要件がある場合には、クライアントも証明書を持っている必要があります。

HTTPS プロトコルが必要な理由:

HTTP プロトコルは、暗号化されていないプレーン テキスト送信プロトコルです。クライアント (APP、ブラウザ) がHTTP通信 データが漏洩し、仲介者によって通信内容が乗っ取られ、通信内容が改ざんされる可能性があります。次の図に示すように、一般的な APP の HTTP 通信はオペレータによってハイジャックおよび変更され、広告が挿入されます。

#ユーザーの情報セキュリティを保護し、ビジネス上の利益を保護し、攻撃対象領域を減らすには、通信チャネルのセキュリティを確保する必要があります。開発が簡単な HTTPS を使用します。

HTTPS 通信原理

HTTPS は SSL/TLS 上の HTTP であり、HTTP はアプリケーション層プロトコル、TCP はアプリケーション層とトランスポート間のトランスポート層プロトコルです。レイヤー、セキュア ソケット レイヤー SSL/TLS を追加しました:

上の図に示すように、HTTPS には追加のレイヤーがあります。 HTTP./TLS と比較した SSL の違いにより、SSL/TLS 層は、暗号化および復号化アルゴリズムのネゴシエーション、キー交換、およびクライアントとサーバー間の通信接続の確立を担当します。

HTTPS では、データを送信する前にクライアント (ブラウザ) とサーバー (ウェブサイト) の間でハンドシェイクが必要です。ハンドシェイク プロセス中に、送信データを暗号化するための双方のパスワード情報が次のようになります。設立。 TLS/SSL プロトコルは、暗号化された送信プロトコルのセットであるだけでなく、アーティストによって慎重に設計された芸術作品でもあります。TLS/SSL では、非対称暗号化、対称暗号化、および HASH アルゴリズムが使用されます。ハンドシェイク プロセスは次のとおりです。

(1).client_hello

クライアントはリクエストを開始し、リクエスト情報をクリア テキストで送信します。バージョン情報と暗号スイート候補リスト、圧縮アルゴリズム候補リスト、乱数、拡張フィールド、その他の情報を含む関連情報は次のとおりです。

• サポートされている最も高い TSL プロトコル バージョン、低位から高位まで、SSLv2 SSLv3 TLSv1 TLSv1 .1 TLSv1.2、TLSv1 より低いバージョンは基本的に使用されなくなりました;

• クライアントによってサポートされる暗号スイートのリスト、各暗号スイート以前の TLS 原則に対応します。認証アルゴリズム Au (身元検証)、鍵交換アルゴリズム KeyExchange (鍵ネゴシエーション)、対称暗号化アルゴリズム Enc (情報暗号化)、情報ダイジェスト Mac (完全性検証) の 4 つの機能の組み合わせです。

• サポートされている圧縮方式のリスト 圧縮方式。その後の情報の圧縮と送信に使用されます。

• 乱数random_C。その後の鍵の生成に使用されます。

• 拡張フィールド拡張は、プロトコルおよびアルゴリズム関連のパラメータおよびその他の補助情報をサポートします。共通 SNI は拡張フィールドであり、このフィールドの役割については後で別途説明します。

(2).server_hello server_certificate sever_hello_done

• server_hello、サーバーは、使用するために選択されたプロトコルのバージョンを含むネゴシエーション情報の結果を返します。選択された暗号スイート、選択された圧縮アルゴリズム圧縮方法、乱数random_Sなど（乱数は後続のキーネゴシエーションに使用されます）;

•server_certificates、server-に対応します。サイド構成 認証と鍵交換に使用される証明書チェーン;

• server_hello_done、server_hello 情報の送信が完了したことをクライアントに通知します;

(3) 証明書の検証

クライアントは証明書の有効性を検証し、検証に合格した場合は以降の通信を行い、そうでない場合は、次のとおりの指示と操作を行います。合法性の検証には次のものが含まれます:

• [証明書チェーン] の信頼された証明書パス、方法は上記のとおりです;

• 証明書が失効するか失効するかに関係なく、オフライン CRL とオンライン OCSP の 2 つの方法があります。クライアントが異なれば動作も異なります。

• 有効期限、有効期限が証明書は有効な時間範囲内にあります;

#• ドメイン名ドメイン、証明書のドメイン名が現在のアクセス ドメイン名と一致するかどうかを確認し、その後の一致ルールの分析を行います;

(4 ).client_key_exchangechange_cipher_spec encrypted_handshake_message

(a) client_key_exchange、合法性検証に合格した後、クライアントは乱数を計算して生成します。証明書の公開キーで暗号化し、サーバーに送信します。

(b) この時点で、クライアントはネゴシエーション キーの計算に必要なすべての情報を取得しています。2 つの平文乱数random_C、random_Sと独自の計算で生成したPre-master、ネゴシエーションキーを計算 Key;

enc_key=Fuc(random_C, random_S, Pre-Master)

(c) change_cipher_spec、クライアントは後続の通信をサーバーに通知します。ネゴシエートされた通信キーと暗号化アルゴリズムが暗号化通信に使用されます。

(d ) encrypted_handshake_message、以前のすべての通信パラメータのハッシュ値とその他の関連情報を組み合わせて、ネゴシエートされた暗号化を使用してデータを生成します。キー セッションの秘密はアルゴリズムで暗号化され、データとハンドシェイクの検証のためにサーバーに送信されます。

(5).change_cipher_spec encrypted_handshake_message

( a) サーバーは暗号化されたプレマスターデータを秘密鍵で復号し、ネゴシエーションキーを計算します以前に交換された 2 つの平文乱数 random_C および random_S に基づきます: enc_key=Fuc(random_C, random_S, Pre-Master);

(b) 以前に受信したすべてのメッセージのハッシュ値を計算します。次に、クライアントによって送信された encrypted_handshake_message を復号し、データとキーの正確性を検証します。

(c ) change_cipher_spec、検証に合格した後、サーバーはまた、change_cipher_spec を送信して通知します。クライアントは、後続の通信で暗号化通信にネゴシエートされたキーとアルゴリズムが使用されることを通知します。

(d) encrypted_handshake_message、サーバーは現在のすべての通信パラメータ情報を組み合わせてデータを生成し、暗号化されます。ネゴシエートされたキー enc_key とアルゴリズムを使用してクライアントに送信されます;

#(6) ハンドシェイクが終了します

クライアントはハッシュ値を計算します受信したすべてのメッセージについて、ネゴシエートされたキーを使用して encrypted_handshake_message を復号化し、サーバーから送信されたデータとキーを検証します。検証に合格すると、ハンドシェイクは完了します。

( 7) . 暗号化通信

暗号化通信用にネゴシエートされたキーとアルゴリズムの使用を開始します。タイミング図は次のとおりです。

証明書の検証

(3)の証明書検証では、クライアントはサーバーから送信された証明書を検証します。完了しました

1. 発行者と有効期間を確認します

2. 信頼リストに含まれているかどうかを確認します

##2. 正当性の検証

証明書を検証するとき、クライアントは証明書内の関連する平文情報を読み取り、同じハッシュ関数を使用して、情報ダイジェストを取得し、ローカルで取得した対応する CA の公開鍵を使用して署名データを復号し、証明書の情報ダイジェストと比較し、一致していれば証明書の正当性を確認できます。 、公開鍵は正当です;

証明書の内容:

申請者の公開鍵、申請者の組織情報および個人情報、発行局 CA 情報、有効期限、証明書のシリアル番号、その他の情報を平文で同時に保存 署名が含まれます;

署名の生成: ハッシュ関数を使用して公開平文情報の情報ダイジェストを計算します次に、CA の秘密キーを使用して情報ダイジェストを暗号化し、その暗号文が署名になります。

#ヒント;

#1. クライアントはサーバーから送信された公開キーを使用してデータを暗号化し、暗号化されたデータをサーバーに送信します。サーバーは秘密キーを使用して復号化します。これが非対称暗号化です。

2. クライアントとサーバーの両方がネゴシエーション キー

enc_key を取得すると、両当事者はそのキーを使用して暗号化と復号化を行います。これは対称暗号化です。 暗号化アルゴリズムの概要

# TLS/SSL の機能実装は、主に 3 種類の基本アルゴリズム (ハッシュ関数ハッシュ、対称暗号化、非対称暗号化) に依存します。非対称暗号化は ID 認証とキー ネゴシエーションを実現します。対称暗号化アルゴリズムは、ネゴシエートされたキーを使用してデータを暗号化し、ハッシュ関数に基づいて情報の整合性を検証します。

1. 対称暗号化

# ※ストリーミングとグループ化の2種類があり、暗号化と復号化に同じ鍵を使用します。

例: DES、AES-GCM、ChaCha20-Poly1305 など。

2. 非対称暗号化

暗号化に使用される鍵と復号化に使用される鍵は異なり、それぞれ公開鍵、秘密鍵、公開鍵と呼ばれます。アルゴリズムは公開され、秘密キーは秘密に保たれます。非対称暗号アルゴリズムは、性能は低いものの安全性が高く、暗号化の特性上、暗号化できるデータ長にも制限があります。

#例: RSA、DSA、ECDSA、DH、ECDHE

3、ハッシュ アルゴリズム

##任意の長さの情報を短い固定長の値に変換します。通常、その長さは情報よりもはるかに小さく、アルゴリズムは元に戻すことができません。

例: MD5、SHA-1、SHA-2、SHA-256 など。

4、デジタル署名

署名とは、情報の後にコンテンツ (ハッシュ化後の情報の値) を追加することで、情報が変更されていないことを証明できます。通常、ハッシュ値は暗号化され (つまり、署名され)、ハッシュ値が変更されないようにメッセージと一緒に送信されます。

双方向認証:

サーバーはクライアントの検証、つまり双方向認証を要求することもできます。処理2では、client_certificate_request情報を送信し、処理4では、client_certificateとcertificate_verify_message情報を送信するが、証明書の検証方法は基本的に同じであり、certificate_verify_messageは、クライアントの秘密鍵で暗号化されたネゴシエーション通信情報に基づくデータである。サーバーは、対応する公開キーを使用して暗号化を解除し、検証できます。

以上がHTTPS通信の原理は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。