HTTPS が HTTP よりも安全なのはなぜですか?

まえがき

近年、インターネット、特に私たちが使用する HTTP プロトコルは、地球を揺るがす変化を経験しました。使い慣れた HTTPS プロトコルは徐々に HTTPS プロトコルに置き換えられています。ブラウザ、検索エンジン、CA 機関、大手インターネット企業の共同推進により、インターネットは「HTTPS 暗号化時代」を迎えました。HTTPS は HTTP を完全に置き換えます。今後数年間の輸送が合意の主流となる。

この記事を読むと、次のことが理解できると思います。

HTTP 通信の問題は何ですか?

HTTPS がどのように改善されるか 問題は何ですか? with HTTP

HTTPS

##の動作原理は何ですか?1. HTTPS#とは何ですか?HTTPS は HTTP の上に SSL 暗号化層を確立し、暗号化します。送信データ。HTTP プロトコルの一部です。安全なバージョンです。現在、トランザクションの支払いなど、World Wide Web 上のセキュリティが重要な通信に広く使用されています。

HTTPS の主な機能は次のとおりです:

(1) データを暗号化し、送信中のデータのセキュリティを確保するための情報セキュリティ チャネルを確立します;

(2) 本物の ID 認証を実行しますウェブサイトのサーバー上で。

Webログインページやショッピング決済画面ではHTTPS通信を使用することが多いです。 HTTPS 通信を使用する場合、http:// は使用されなくなり、代わりに https:// が使用されます。また、ブラウザが有効なHTTPS通信でWebサイトにアクセスすると、ブラウザのアドレスバーに鍵のマークが表示されます。 HTTPSの表示方法はブラウザによって異なります。

2. HTTPS が必要な理由

HTTP プロトコルでは、情報の盗難や個人情報の偽装などのセキュリティ上の問題が発生する可能性があります。 HTTPS 通信メカニズムを使用すると、これらの問題を効果的に防ぐことができます。次に、まず HTTP プロトコルの問題を理解しましょう:

通信には平文 (暗号化されていない) が使用されるため、内容が盗聴される可能性があります

HTTP自体には暗号化機能がないため、通信全体(HTTPプロトコルで通信されるリクエストやレスポンスの内容)を暗号化することはできません。つまり、HTTP メッセージはクリア テキスト (暗号化されていないメッセージを指します) で送信されます。

HTTP プレーンテキスト プロトコルの欠陥は、データ漏洩、データ改ざん、トラフィック ハイジャック、フィッシング攻撃などのセキュリティ上の問題の重要な原因です。 HTTP プロトコルはデータを暗号化できず、すべての通信データはネットワーク内で平文で「裸で実行」されます。ネットワーク スニッフィング機器と何らかの技術的手段を介して、HTTP メッセージの内容を復元できます。

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

いわゆる完全性とは、情報の正確さを指します。完全性を証明できないということは、通常、情報が正確であるかどうかを判断できないことを意味します。 HTTPプロトコルは通信メッセージの完全性を証明できないため、リクエストやレスポンスを送信してから相手が受信するまでの間に、リクエストやレスポンスの内容が改ざんされたかどうかを知る方法がありません。 。つまり、送信したリクエスト/レスポンスと受信したリクエスト/レスポンスが同じであることを確認する方法はありません。

通信当事者の身元を確認しないため、マスカレードが発生する可能性があります

HTTP プロトコルのリクエストと応答は、通信当事者を確認しません。 HTTPプロトコルによる通信では、通信相手を確認する処理がないため、誰でもリクエストを行うことができます。また、サーバーはリクエストを受信すれば、相手が誰であってもレスポンスを返します（ただし送信元のIPアドレスやポート番号がWebサーバーで制限されていない場合に限ります）

HTTPプロトコルが検証できない 通信相手の身元については、誰でも偽のサーバーを偽造してユーザーを騙すことができ、ユーザーには検知できない「フィッシング詐欺」が実現します。

HTTPS プロトコルを振り返ると、HTTP プロトコルに比べて次のような利点があります (詳細は後述します)。

データ プライバシー: コンテンツは対称的に暗号化され、各接続で独自の暗号化キー

データの整合性: コンテンツの送信は整合性検証を受けます

ID 認証: 第三者がサーバー (クライアント) の ID を偽造することはできません

3. HTTPS は、HTTP の上記の問題を解決しますか?

HTTPS は、アプリケーション層の新しいプロトコルではありません。 HTTP 通信インターフェイス部分のみが SSL および TLS プロトコルに置き換えられます。

通常、HTTP は TCP と直接通信します。 SSL を使用する場合、最初に SSL と通信し、次に SSL が TCP と通信するように進化します。つまり、いわゆる HTTPS は、実際には SSL プロトコルのシェルでラップされた HTTP です。

SSL の採用により、HTTP には HTTPS の暗号化、証明書、完全性保護機能が追加されました。つまり、HTTP に暗号化処理、認証、整合性保護を加えたものが HTTPS です。

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

1. コンテンツが盗聴される可能性がある問題を解決する - 暗号化

方法 1. 対称暗号化

この方法では、暗号化と復号化に同じキーを使用します。キーは暗号化と復号化に使用されます。パスワードはキーがなければ解読できませんが、逆にキーを持っていれば誰でも解読できます。

対称暗号化を使用して暗号化する場合、キーも相手に送信する必要があります。しかし、どうすれば安全に転送できるのでしょうか?鍵がインターネット経由で転送される場合、通信が盗聴されると鍵が攻撃者の手に渡ってしまい、暗号化の目的が失われる可能性があります。受け取ったキーを安全に保管する方法も見つける必要があります。

方法 2. 非対称暗号化

公開キー暗号化では、非対称キーのペアを使用します。 1 つは秘密キーと呼ばれ、もう 1 つは公開キーと呼ばれます。名前が示すように、秘密キーは他の人に知られることはできませんが、公開キーは自由に公開され、誰でも利用できるようになります。

公開キー暗号化を使用すると、暗号文を送信する側は相手の公開キーを使用して暗号化し、相手は暗号化された情報を受け取った後、自分の秘密キーを使用して復号化します。これにより、復号に使用する秘密鍵を送信する必要がなく、攻撃者に秘密鍵が盗聴される心配もありません。

非対称暗号化の特徴は、情報が 1 対多で送信されることであり、サーバーは 1 つの秘密鍵を保持するだけで、複数のクライアントと暗号化通信を行うことができます。

この方法には次の欠点があります。

公開キーは公開されているため、秘密キーで暗号化された情報を傍受した後、ハッカーは公開キーを使用して復号化してコンテンツを取得できます。

公開キーにはサーバーの情報が含まれていません。非対称暗号化アルゴリズムを使用すると、サーバーの ID の正当性を保証できません。中間者攻撃のリスクがあります。公開キーは、次のユーザーによって送信されます。サーバーからクライアントへの送信プロセスは、送信プロセス中に仲介者によって傍受され、改ざんされる可能性があります。

非対称暗号化を使用すると、データの暗号化と復号化のプロセスに一定の時間がかかり、データ送信効率が低下します。

方法 3. 対称暗号化と非対称暗号化 (HTTPS はこの方法を使用します)

対称キーを使用する利点は、復号効率が比較的速いことです。非対称キーを使用する利点は、データを傍受したとしても、対応する秘密鍵がなければ解読できないため、送信されたコンテンツは解読できません。たとえば、金庫をつかんだものの、金庫の鍵がなければ金庫を開けることができません。そこで対称暗号と非対称暗号を組み合わせてそれぞれの利点を生かし、鍵交換段階では非対称暗号を使用し、その後の通信やメッセージ交換段階では対称暗号を使用します。

具体的な方法は、暗号文を送信する側が相手の公開鍵を使って「対称鍵」を暗号化し、相手が自分の秘密鍵を使って復号して「対称鍵」を取得するというものです。これにより、交換されるキーが安全であるという前提で、対称暗号化を使用して通信が実行されることが保証されます。したがって、HTTPS は対称暗号化と非対称暗号化の両方を使用するハイブリッド暗号化メカニズムを使用します。

2. メッセージの改ざんの可能性の問題を解決する - デジタル署名

ネットワーク送信プロセス中、多くの中間ノードを通過する必要があります。データは復号化できませんが、復号化される可能性があります。それを確認するにはどうすればいいですか? データの整合性はどうですか? ----デジタル署名を検証します。

デジタル署名には 2 つの機能があります:

他の人が送信者の署名を偽造できないため、メッセージが送信者によって実際に署名されて送信されたことを確認できます。

デジタル署名はメッセージの完全性を判断し、データが改ざんされていないことを証明できます。

デジタル署名を生成する方法:

ハッシュ関数を使用してテキストのメッセージ ダイジェストを生成し、送信者のプライベート情報で暗号化します。キーを使用してデジタル署名を生成し、元のテキストも一緒に受信者に送信されます。次のステップは、受信者がデジタル署名を検証するプロセスです。

検証デジタル署名プロセス:

#受信者は、送信者の公開キーを使用して暗号化されたダイジェスト情報を復号化し、HASH 関数を使用して、取得された元のテキストから要約情報が生成され、前のステップで取得した要約情報と比較されます。それらが同じであれば、受信した情報は完全で送信プロセス中に変更されていないことを意味し、そうでない場合は情報が変更されていることを意味するため、デジタル署名は情報の完全性を検証できます。

メッセージパッシングがコービーとジェームスの間で発生すると仮定します。 James はデジタル署名とともにメッセージをコービーに送信し、メッセージを受信したコービーはデジタル署名を検証することで、受信したメッセージが James によって送信されたものであることを確認できます。もちろん、このプロセスの前提は、コービーがジェームズの公開鍵を知っているということです。問題の核心は、メッセージ自体と同様に、公開鍵を安全でないネットワーク経由でコービーに直接送信できないこと、または取得した公開鍵がジェームズのものであることをどのように証明するかということです。

現時点では、認証局 (CA) を導入する必要があります。CA の数は多くありません。Kobe クライアントには、信頼できるすべての CA の証明書が組み込まれています。 CA は、James の公開鍵 (およびその他の情報) にデジタル署名した後、証明書を生成します。

3. 通信相手の身元が偽装される可能性がある問題を解決 - デジタル証明書

デジタル証明書認証局は、双方から信頼される第三者機関の立場にあります。クライアントとサーバー。

電子証明書認証局のビジネス プロセスを紹介します。

サーバー運用者は、公開鍵、組織情報、および個人情報 (ドメイン名) を認証局に提出します。第三者機関 CA ) およびその他の情報を取得して認証を申請します;

CAは、組織が存在するかどうか、企業が合法であるかどうか、ドメイン名の所有権を持っているかどうかなど、オンラインおよびオフラインなどのさまざまな手段を通じて申請者から提供された情報の信頼性を検証します;

情報が承認された場合、CA は認証文書証明書を申請者に発行します。証明書には、申請者の公開鍵、申請者の組織情報および個人情報、発行局 CA の情報、有効期間、証明書のシリアル番号などの情報が平文で含まれており、署名も含まれています。署名生成アルゴリズム: まず、ハッシュ関数を使用して公開平文情報の情報ダイジェストを計算し、次に CA の秘密キーを使用して情報ダイジェストを暗号化し、暗号文が署名になります。

クライアントが送信するサーバーへのメッセージ サーバーが要求を行うと、サーバーは証明書ファイルを返します。

クライアントは、証明書内の関連する平文情報を読み取り、同じハッシュ関数を使用して情報ダイジェストを計算し、対応する CA の公開鍵を使用して署名を復号し、そのデータと証明書の情報ダイジェストを比較し、それらが一致していれば、証明書の正当性、つまりサーバーの公開鍵が信頼できることが確認できます。

クライアントは、ドメイン名情報、有効期限、および証明書に関連するその他の情報も検証します。クライアントには、信頼できる CA 証明書情報 (公開キーを含む) が組み込まれています。CA が信頼できない場合は、該当する CA が見つからない場合、証明書も不正と判断されます。

4. HTTPS ワークフロー

1. クライアントは HTTPS リクエストを開始します (https://juejin.im/user など)。RFC2818 によると、クライアントは接続する必要があるサーバーの 443 (デフォルト) ポート。

2. サーバーは、事前に設定された公開キー証明書をクライアントに返します。

3. クライアントは、公開キー証明書を検証します: たとえば、有効期間内であるかどうか、証明書の目的がクライアントによって要求されたサイトと一致するかどうか、CRL 失効リストに含まれているかどうか、および上位レベルの証明書が有効かどうかを確認するこれは、ルート証明書 (オペレーティング システムに組み込まれているルート証明書、またはクライアントに組み込まれているルート証明書) が検証されるまでの再帰的なプロセスです。検証に合格した場合は続行します。そうでない場合は、警告メッセージが表示されます。

4.クライアントは擬似乱数生成器を使用して暗号化に使用する対称鍵を生成し、その対称鍵を証明書の公開鍵で暗号化してサーバーに送信します。

5. サーバーは独自の秘密キーを使用してメッセージを復号化し、対称キーを取得します。この時点で、クライアントとサーバーの両方が同じ対称キーを保持します。

6. サーバーは対称キーを使用して「プレーン テキスト コンテンツ A」を暗号化し、クライアントに送信します。

7.クライアントは対称鍵を使用して応答の暗号文を復号し、「平文コンテンツ A」を取得します。

8.クライアントは再度 HTTPS リクエストを開始し、対称キーを使用して要求された「平文コンテンツ B」を暗号化し、サーバーは対称キーを使用して暗号文を復号し、「平文コンテンツ B」を取得します。

5. HTTP と HTTPS の違い

HTTP はプレーン テキスト送信プロトコルであり、HTTPS プロトコルは SSL HTTP プロトコルから構築されたネットワーク プロトコルであり、暗号化通信と本人認証により、HTTP プロトコルよりも安全です。

セキュリティに関して、この 2 つの関係を説明する最も簡単な比喩は、トラックが商品を輸送することです。HTTP のトラックはオープントップで、商品は露出しています。また、https は密閉コンテナ トラックなので、当然セキュリティが大幅に向上します。

HTTPS は HTTP よりも安全で、検索エンジンにとって親しみやすく、SEO に役立ちます。Google と Baidu は HTTPS Web ページのインデックス付けを好みます。

HTTPS には SSL 証明書が必要ですが、HTTP には SSL 証明書が必要です。ではありません;

#HTTPS 標準ポート 443、HTTP 標準ポート 80;

#HTTPS はトランスポート層に基づいており、HTTP はアプリケーション層に基づいています;

HTTPS には緑色のマークが表示されますブラウザでセキュリティ ロックが発生すると、HTTP が表示されません;

6. すべての Web サイトが HTTPS を使用しない理由

HTTPS は非常に安全で信頼性が高いのに、なぜ使用しないのですかすべての Web Web サイトが HTTPS を使用しているのでしょうか?

まず第一に、HTTPS 実装にはしきい値があると考えている人がまだ多くいますが、このしきい値は、権威ある CA によって発行された SSL 証明書が必要であるという点にあります。証明書の選択、購入、導入に至るまで、従来のモデルはより時間と労力がかかります。

第 2 に、暗号化通信は平文通信よりも多くの CPU リソースとメモリ リソースを消費するため、HTTPS は HTTP よりもパフォーマンスの消費が高いと一般に考えられています。それぞれの通信を暗号化すると大量のリソースを消費するため、1台のコンピュータに分散すると処理できるリクエストの数は必然的に減ります。ユーザーは、パフォーマンスを最適化し、SLB または CDN に証明書を展開することで、この問題を解決できます。実例を挙げると、「ダブルイレブン」期間中、タオバオや天猫ではサイト全体にHTTPSを採用しており、ウェブサイトやモバイル端末でのアクセス、閲覧、取引などの操作がスムーズに行われていました。テストを通じて、多くの最適化されたページのパフォーマンスは HTTP のパフォーマンスと同じか、わずかに向上していることが判明したため、最適化後の HTTPS は実際には遅くなりません。

さらに、証明書の購入コストを節約したいことも理由の 1 つです。 HTTPS 通信を有効にするには、証明書が必須です。使用する証明書は認証局 (CA) から購入する必要があります。

最後は安全意識です。中国と比較して、海外のインターネット業界のセキュリティ意識と技術応用は比較的成熟しており、HTTPS 導入の傾向は社会、企業、政府が共同で推進しています。

以上がHTTPS が HTTP よりも安全なのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。