HTTPS はどのようにして Web セキュリティを確保しますか? (コード例)

この記事の内容は、HTTPS が Web セキュリティをどのように確保するかについてです。 (コードサンプル) は、参考にしていただければ幸いです。

HTTPS (正式名: HyperText Transfer Protocol over Secure Socket Layer) は、クライアントとサーバー間のデータ転送のセキュリティを確保します。過去 2 年間で、Google、Baidu、Facebook などのインターネット大手は、国内外の多くの大手インターネット企業もフルサイト HTTPS を有効にし始めました。これは、インターネットの将来の発展傾向でもあります。フロントエンドエンジニアと同様に、HTTPSの原理を理解することも必須の科目です。
2019 年には、ネットワーク全体で HTTPS が使用される日もそう遠くありません。HTTPS の使用を促進するために、主要なインターネット企業が提示した要件をいくつか示します。
1. Google の検索エンジン アルゴリズムは、HTTPS を使用する Web サイトを許可します。上位にランク付けされる;
2. Apple は、App Store のすべてのアプリケーションで HTTPS 暗号化された接続を使用する必要があります。新世代の HTTP/2 プロトコルのサポートは HTTPS に基づく必要があります。
5. 新しいバージョンの Chrome は、HTTP プロトコル Web サイトを
unsafe
## としてマークしました。 #隠れた危険: なぜ HTTP に S を追加するのでしょうか?

HTTP プロトコルは誕生以来非常に優れていて便利ですが、HTTP にはすべてに 2 つの側面があるわけではなく、欠点も明らかです。

通信は平文で送信されるため、内容が盗聴される可能性があります

• 通信相手の身元が確認されないため、なりすましに遭遇する可能性があります

• メッセージの整合性は証明できないため、改ざんされた可能性があります。

• さらに、HTTP 自体にも多くの欠点があります。また、特定の Web サーバーや特定の Web ブラウザの実際のアプリケーションにも欠陥 (脆弱性またはセキュリティ ホールとも言えます) が存在する可能性があります。また、Java や PHP などのプログラミング言語で開発された Web アプリケーションにも問題がある可能性があります。セキュリティ上の脆弱性も考えられます。

1. 平文通信は盗聴される可能性がある

HTTP自体には暗号化機能がないため、通信全体を保護することはできません(暗号化通信を使用した通信)。 HTTP プロトコル) のリクエストとレスポンスのコンテンツ) は暗号化されます。したがって、HTTP メッセージはクリア テキストで送信されます。なぜ通信を暗号化しないとデメリットになるのかというと、TCP/IPプロトコルスイートの仕組み上、すべての通信回線で通信内容が盗み見される可能性があるからです。 いわゆるインターネットは、世界中のどこにいてもサーバーとクライアントが通信できるネットワークと、その通信回線上にあるネットワーク機器、光ケーブル、コンピュータなどで構成されています。個人の所有物であることはできないため、悪意のある覗き見がいつか発生する可能性は排除されません。

通信が暗号化されていても、通信内容が覗き見されてしまうのは、暗号化されていない通信と同じです。これは、通信が暗号化されている場合、メッセージ情報の意味を解読することは不可能かもしれないが、暗号化されたメッセージ自体は表示されることを意味します。

同じセグメント上の通信を盗聴することは難しくありません。インターネット上を流れるデータパケットを収集するだけです。収集されたデータ パケットの分析は、パケット キャプチャ ツールまたはスニッフィング ツールに任せることができます。


2. 通信相手の身元が確認できない場合、HTTP プロトコルのリクエストやレスポンスでは通信相手が確認されない可能性があります。 。つまり、「サーバーが実際にリクエスト内のURIで指定されたホストなのか、返されるレスポンスは本当にリクエストを行ったクライアントに返されるのか」といった同様の問題が存在します。

HTTPプロトコルの通信では、通信相手を確認する処理がないため、サーバーがリクエストを受信する限り、IPアドレスとポート番号さえわかれば誰でもリクエストを送信できます。送信側はWebサーバーの制限を受けず、相手が誰であっても応答が返ってくるため、様々な危険が潜んでいます。ターゲットにリクエストを送信した Web サーバーが、真の意図に従って応答を返すサーバーであるかどうかを判断します。偽装された Web サーバーである可能性があります。

レスポンスによって返されたクライアントが、真の意図に従ってレスポンスを受け取ったクライアントであるかどうかを判断することはできません。偽装されたクライアントである可能性があります。

通信相手にアクセス権があるかどうかを判断できません。一部の Web サーバーには、特定のユーザーに送信される通信の許可を示す重要な情報が保存されているためです。
リクエストがどこから来たのか、誰が行ったのかを特定することは不可能です。

• #たとえ無意味な要求であっても、全面的に受け入れます。大量のリクエストによる DoS 攻撃 (Denial of Service、サービス拒否攻撃) を防ぐことができません。
3. メッセージの整合性は証明できず、改ざんされている可能性があります。

いわゆる完全性とは、情報の正確さを指します。完全性を証明できないということは、通常、情報が正確であるかどうかを判断できないことを意味します。
したがって、リクエストまたはレスポンスを送信してから相手がそれを受信するまでの間は、リクエストまたはそれに対応するコンテンツが改ざんされたかどうかを知る方法はありません。
言い換えれば、送信されたリクエストとレスポンスが受信したリクエストとレスポンスと同じであることを確認する方法はありません。送信中にファイルの内容が別の内容に変更されている可能性があり、この場合、送信中にリクエストやレスポンスが攻撃者に傍受され、内容が改ざんされる攻撃を中間者攻撃（MITM）といいます。 ）。

解決策: HTTP 暗号化認証整合性保護 = HTTPS

上記の HTTP の欠点は数多くあるため、当然、HTTPS でそれらを解決する必要があります。その方法を見てみましょう。 HTTPS はデータ送信のセキュリティを保証します。

1. HTTPS は、実際には SSL シェルでラップされた HTTP です。

HTTPS は、アプリケーション層の新しいプロトコルではありません。 HTTP 通信インターフェイス部分は、SSL (Secure Socket Layer) および TLS (Transport Layer Security) プロトコルに置き換えられます。
通常、HTTP は TCP と直接通信します。 SSLを使用する場合、最初にSSLで通信し、次にSSLでTCPで通信することになります。簡単に言えば、SSL と組み合わせて使用​​される HTTP は、HTTPS (HTTP Secure、Hypertext Transfer Security Protocol) または HTTP over SSL と呼ばれます。
SSL の採用により、HTTP には HTTPS の暗号化、証明書、完全性保護機能が追加されました。 SSL は HTTP から独立したプロトコルであるため、HTTP プロトコルだけでなく、アプリケーション層で動作する SMTP や Telnet などの他のプロトコルも SSL プロトコルで使用できます。 SSL は、現在世界で最も広く使用されているネットワーク セキュリティ技術であると言えます。



#HTTPS の暗号化原理

最新の暗号化アルゴリズムでは、暗号化アルゴリズムは公開されており、暗号化アルゴリズムは公開されます。キーは秘密に保たれます。このようにして、暗号化方式のセキュリティが維持されます。
暗号化と復号化にはキーが必要です。キーがない場合、パスワードを復号化することはできません。言い換えれば、鍵を持っている人は誰でも暗号文を復号化できます。
HTTPS は、暗号化プロセスで非対称暗号化テクノロジと対称暗号化テクノロジを使用します。
対称暗号化アルゴリズム
同じキーで情報の暗号化と復号化を同時に実行できる暗号化方式を使用し、対称暗号化とも呼ばれます。単一キー暗号化。
対称暗号化アルゴリズムを、以下では共有鍵暗号化アルゴリズムと呼びます。
ここで、SSL が通信プロセス中に対称暗号化アルゴリズムを使用するとします。これは、クライアントとサーバーが同時にキーを共有することを意味します。
つまり、共有鍵を使用して暗号化するには、その鍵を相手に送信する必要があります。このとき、通信プロセスが監視され、攻撃者に鍵が入手されてしまうと、その時点で暗号化の意味が失われてしまいます。



それでは、この問題を解決する方法はあるのでしょうか?答えは「はい」です。つまり、2 つのキーを使用します。
まず、2 つの鍵を使用する非対称暗号化アルゴリズムを見てみましょう。
非対称暗号化アルゴリズム
対称暗号化アルゴリズムとは対照的に、非対称暗号化アルゴリズムでは、暗号化と復号化に 2 つの鍵 (公開鍵と公開鍵) が必要です。 (公開鍵) と秘密鍵 (秘密鍵) です。
一般に、公開キーは公開することができ、主にプレーン テキストの暗号化に使用されます。同様に、秘密キーは公開できず、公開キーで暗号化された暗号文を復号するために使用されます。
公開キーで暗号化された暗号文は対応する秘密キーでのみ復号化できますが、秘密キーで暗号化された暗号文は対応する公開キーで復号化できることに注意してください。
上記では、暗号化には公開鍵暗号化と秘密鍵復号が使用され、署名には秘密鍵暗号化と公開鍵復号が使用されます。関連する使用法については後で説明します。
非対称暗号化アルゴリズムを、以下では公開鍵暗号化アルゴリズムと呼びます。
それでは、サーバーが公開鍵と秘密鍵のペアを生成すると仮定します。
クライアントが初めてサーバーとネゴシエートするリクエストを送信すると、サーバーは公開キーと秘密キーのペアを生成します。
次に、サーバーは公開キーをクライアントに送信します (平文、暗号化は必要ありません)。受信後、クライアントはランダムにキーを生成し、サーバーから送信された公開キーを暗号化に使用します。
次に、クライアントは公開鍵で暗号化された鍵をサーバーに送信し、サーバーがそれを受信すると、ペアになった秘密鍵を使用して復号し、クライアントによってランダムに生成された鍵を取得します。
現時点では、クライアントとサーバーが保持するキーは同じです。この時点で、鍵交換プロセスは完了します。
したがって、通信が開始されるときは、上記の共有キー暗号化方式を使用して暗号化することができます。
同時に使用する
友人の中には、なぜわざわざ非対称暗号を使用し、共有鍵暗号化通信のために同じ鍵を取得する必要があるのか​​と疑問に思う人もいるかもしれません。

公開キー暗号化は共有キー暗号化よりも処理が複雑であるため、通信中に公開キー暗号化を使用する効率は非常に低くなります。

したがって、鍵共有プロセス中に鍵のセキュリティを確保するために非対称暗号化を使用し、通信プロセス中に対称暗号化アルゴリズムを使用する必要があります。これは安全性を確保する最も合理的な設計方法です。パフォーマンスを確保しながら。

したがって、HTTPS では、共有キー暗号化と公開キー暗号化の両方を使用するハイブリッド暗号化メカニズムが採用されています。鍵交換フェーズでは公開鍵暗号が使用され、その後の通信メッセージ交換フェーズでは共有鍵暗号が使用されます。

上記はおそらく対称暗号化と非対称暗号化を使用するプロセスです。このプロセスは完璧であるように見えますが、サーバーから渡された公開キーの正確性をどのように確認するかという問題がまだ残っています。つまり、傍受や改ざんができないようにするためです。

証明書を使用して公開キーの正確性を確認する

公開キー暗号化を使用してサーバーとの通信を確立する準備をしている場合、クライアントがその正当性を証明する方法が受信しました 公開鍵は、当初想定されていたようにサーバーによって発行された公開鍵ですか?おそらく、公開鍵の送信中に、攻撃者によって実際の公開鍵が置き換えられた可能性があります。

この問題を解決するには、デジタル認証局とその関連機関によって発行された公開キー証明書を使用できます。

次に、デジタル認証局 (CA) のビジネス プロセスについて説明します。

まず、サーバー オペレーターは、デジタル認証局に公開キーを申請します。デジタル証明書認証局は、申請者の身元を確認した後、適用された公開鍵にデジタル署名し、署名された公開鍵を配布し、公開鍵を公開鍵証明書に入れて Together にバインドします。

上記の段落を現地語に翻訳してみましょう:
まず、CA は申請者に証明書を発行します。この証明書の内容には、発行者、証明書の目的、および証明書に含まれる内容が含まれます。サーバー アプリケーションの公開キー、サーバー暗号化アルゴリズム、使用される HASH アルゴリズム、証明書の有効期限など。
次に、上記のコンテンツに対して HASH 評価を実行し、HASH 値を取得します。

次に、CA の秘密キーを使用して暗号化し、デジタル署名を完成させます。 CA の秘密キーで暗号化した後、人間の指紋に似た署名が生成され、証明書を改ざんしようとする試みはデジタル署名によって発見されます。
最後に、デジタル証明書の末尾にデジタル署名を添付してサーバーに送り返します。
次に、サーバーはデジタル証明書認証局が発行した公開鍵証明書をクライアントに送信します。このとき、クライアントはデジタル認証局の公開鍵を使用して検証できます。検証が成功すると、クライアントは公開キーが信頼できることを確認できます。

これを現地語に翻訳しましょう:
クライアントはこのデジタル証明書を取得した後、CA 秘密鍵に対応する公開鍵を使用してデジタル証明書の末尾にあるデジタル署名を復号化し、元のハッシュ値。
次に、クライアントは、証明書内の HASH アルゴリズムに従って、証明書のコンテンツの HASH 値を計算します。 CA公開鍵で復号したHASH値が計算で得たHASH値と同じであれば認証は成功し、それ以外の場合は認証失敗となります。
認証に合格すると、サーバーの公開キーを取得できます。

クライアント上の CA 公開キーはどこから来たのでしょうか?
ほとんどのブラウザ開発者はバージョンをリリースするときに、一般的に使用される認証局の公開キーを事前に内部に埋め込みます。このようにして、クライアントがデジタル証明書の信頼性を検証するのに便利です。

具体的なプロセスは次のとおりです (写真ではデジタル署名のプロセスを簡略化しています):



実際に使用されますここでは非対称暗号化アルゴリズムですが、現在この暗号化アルゴリズムは暗号化ではなく署名に使用されています。

秘密鍵暗号化と公開鍵復号化は、公開鍵の所有者が秘密鍵で暗号化されたコンテンツが改ざんされていないかどうかを確認するために使用されますが、コンテンツが改ざんされているかどうかを確認するためには使用されません。他人が入手したものです。

公開キー暗号化と秘密キー復号化の使用はその逆であり、情報が他者によって傍受され改ざんされることは保証されませんが、情報が仲介者によって取得されることは保証されません。

クライアント証明書

HTTPSではサーバー証明書だけでなくクライアント証明書も使用できます。クライアント認証には、サーバー証明書と同じ機能を持つクライアント証明書を使用します。

クライアントは証明書を取得するためにクライアント証明書をインストールする必要があるため、コストの問題もあります。

したがって、非常にセキュリティの高い認証局がクライアント証明書を取得できるのは、特殊な目的のサービスに限られているのが現状です。たとえば、クライアント証明書のコストをサポートできる企業などです。

たとえば、銀行のオンライン バンキングではクライアント証明書が使用されます。ネットバンキングにログインする際には、IDとパスワードの入力確認が求められるだけでなく、特定の端末からネットバンキングにアクセスしているかどうかを確認するために、利用者のクライアント証明書も必要となります。

HTTPS の安全な通信メカニズム

HTTPS をよりよく理解するために、Xiaosi は、HTTPS の通信手順を誰もが観察できるように次の図を描きました。



ステップ 1 :クライアントは、Client Hello メッセージを送信して SSL 通信を開始します。メッセージには、クライアントがサポートする SSL の指定されたバージョンと、暗号化コンポーネントのリスト (使用される暗号化アルゴリズム、キーの長さなど) が含まれます。

ステップ 2: サーバーが SSL 通信を実行できる場合、サーバーは Server Hello メッセージで応答します。クライアントと同様に、SSL バージョンと暗号化コンポーネントがメッセージに含まれます。サーバーの暗号化コンポーネントの内容は、受信したクライアントの暗号化コンポーネントからフィルターで除外されます。

ステップ 3: 次に、サーバーは証明書メッセージを送信します。メッセージには公開鍵証明書が含まれています。

ステップ 4: 最後に、サーバーは Server Hello Done メッセージを送信して、SSL ハンドシェイク ネゴシエーションの最初のフェーズが終了したことをクライアントに通知します。

ステップ 5: 最初の SSL ハンドシェイクが完了すると、クライアントはクライアント キー交換メッセージで応答します。メッセージには、通信の暗号化に使用されるプレマスター シークレットと呼ばれるランダムなパスワード文字列が含まれています。メッセージは手順 3 の公開キーを使用して暗号化されています。

ステップ 6: その後、クライアントは暗号仕様変更メッセージの送信を続けます。このメッセージは、このメッセージ以降の通信がプレマスター秘密鍵を使用して暗号化されることをサーバーに要求します。

ステップ 7: クライアントは Finished メッセージを送信します。このメッセージには、これまでに接続されたすべてのメッセージの全体的な検証値が含まれています。このハンドシェイク ネゴシエーションが成功するかどうかは、サーバーがメッセージを正しく復号化できるかどうかによって決まります。

ステップ 8: サーバーは、Change Cipher Spec メッセージも送信します。

ステップ 9: サーバーは、Finished メッセージも送信します。

ステップ 10: サーバーとクライアントの間で Finished メッセージが交換された後、SSL 接続が確立されます。もちろん、通信は SSL によって保護されます。ここから、アプリケーション層プロトコルとの通信、つまり HTTP リクエストの送信が始まります。

ステップ 11: アプリケーション層プロトコル通信、つまり HTTP 応答の送信。

ステップ 12: 最後に、クライアントが切断されます。切断時には、close_notify メッセージが送信されます。上の図では一部省略されていますが、このステップの後、TCP FIN メッセージが送信されて TCP との通信が終了します。

上記のプロセスでは、アプリケーション層がデータを送信するときに、MAC (メッセージ認証コード) と呼ばれるメッセージ ダイジェストを追加します。 MAC はメッセージが改ざんされていないかどうかをチェックできるため、メッセージの完全性が保護されます。

ここで質問があります。プロセス全体で生成された 3 つの乱数は何に使われるのでしょうか?また、後からHTTP通信を行う際に、どの鍵を使って暗号化するのか、メッセージの整合性をどのように確保するのか。

下の写真を見てください。



クライアントの場合:

プレマスター シークレットを生成した後、元の A と B の乱数を組み合わせます。 DH アルゴリズムを使用してマスター シークレットを計算し、このマスター シークレットに基づいてハッシュ シークレットとセッション シークレットを導出します。

サーバーの場合:

プレマスター シークレットを復号して取得した後、元の A と B の乱数を組み合わせ、DH アルゴリズムを使用してマスター シークレットを計算し、このマスター シークレットからハッシュ シークレットとセッション シークレットが派生します。

クライアントとサーバーのマスター シークレットは、3 つの乱数に基づいて導出されます。これは、両者だけが知り、第三者には知られません。同時に、クライアントによって導出されるセッション シークレットとハッシュ シークレットは、サーバーのものとまったく同じです。

それでは、双方が対称アルゴリズム暗号化を使用して通信を開始した場合、どちらが共有キーとして使用されるのでしょうか?プロセスは次のようなものです。

双方が対称暗号化アルゴリズムを使用して暗号化し、ハッシュ シークレットを使用して HTTP メッセージに対して操作を実行して MAC を生成し、それを HTTP メッセージの末尾に添付します。 session-secret を使用してすべてのデータ (HTTP MAC) を暗号化して送信します。

受信者は、まずセッション シークレットを使用してデータを復号化し、次に HTTP MAC を取得し、次に同じアルゴリズムを使用して自身の MAC を計算します。2 つの MAC が等しい場合、データが暗号化されていることを証明します。改ざんされていない。

この時点で、プロセス全体が紹介されます。

以上がHTTPS はどのようにして Web セキュリティを確保しますか? (コード例)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。