1.httpsを使用する理由
httpは安全ではないため、httpsを使用する理由は実際には非常に単純です。
httpを使用して通信する場合、サーバーにさらに多くの個人データ（銀行カード、IDカードなど）を送信する場合。その場合、セキュリティは保証されません。まず、データ送信の過程で、仲介者がデータを取得し、仲介者がデータを盗む可能性があります。第二に、仲介者がデータを取得した後、仲介者はデータを変更または置換してからサーバーに送信することができます。最後に、サーバーはデータを受信した後、データが変更されたか置き換えられたかを判断できません。もちろん、サーバーがデータが実際にクライアントからのものであると判断できない場合。
要約すると、httpには3つの欠点があります。
- メッセージの機密性は保証できません
- メッセージの完全性と正確性は保証できません
- 情報源の信頼性は保証できません
httpsは上記の問題を解決するために生まれました。
第二に、httpsに関連する基本的な概念
httpに存在する問題を解決するために、httpsはいくつかの暗号化と復号化、デジタル証明書、およびデジタル署名技術を採用しています。まず、これらのテクノロジーの基本的な概念を紹介しましょう。
1.対称暗号化と非対称暗号化
メッセージの機密性を確保するために、暗号化と復号化が必要です。現在の主流の暗号化および復号化アルゴリズムは、対称暗号化と非対称暗号化に分けられます。
1.対称暗号化（共有キー暗号化）：クライアントとサーバーは、メッセージを暗号化および復号化するためのキーを共有します。この方法は、対称暗号化と呼ばれます。クライアントとサーバーは暗号化キーについて合意します。クライアントは、メッセージを送信する前にキーを使用してメッセージを暗号化し、サーバーに送信した後、サーバーはキーを使用してメッセージを復号化し、メッセージを取得します。
対称暗号化の利点：対称暗号化は、httpでのメッセージの機密性の問題を解決します
対称暗号化のデメリット：1。対称暗号化はメッセージの機密性を保証しますが、クライアントとサーバーはキーを共有するため、キーが特に漏洩しやすくなります。
2.キー漏洩のリスクが高いため、メッセージの送信元の信頼性、およびメッセージの整合性と正確性を保証することは困難です。
2.非対称暗号化（公開鍵暗号化）：対称暗号化では鍵が漏洩しやすいため、非対称暗号化方式を使用して解決できます。非対称暗号化を使用する場合、クライアントとサーバーの両方に公開鍵と秘密鍵があります。公開鍵は外部に公開できますが、秘密鍵は自分だけに表示されます。公開鍵で暗号化されたメッセージは、対応する秘密鍵によってのみロックを解除できます。逆に、秘密鍵で暗号化されたメッセージは、公開鍵でのみロックを解除できます。このように、クライアントは最初にメッセージを送信する前にサーバーの公開鍵で暗号化し、次にサーバーがメッセージを受信した後に独自の秘密鍵でメッセージを復号化します。
非対称暗号化の利点：1。非対称暗号化は公開鍵と秘密鍵を使用します。これにより、httpでのメッセージの機密性の問題が解決され、秘密鍵の漏洩のリスクが軽減されます。
2.公開鍵暗号化メッセージは、対応する秘密鍵によってのみロックを解除できるため、メッセージの送信元とメッセージの正確性および完全性が大幅に保証されます。
非対称暗号化のデメリット：1。非対称暗号化では、メッセージを暗号化するために受信者の公開鍵が必要ですが、公開鍵は機密ではなく、誰でも取得でき、仲介者も取得できます。次に、仲介者は2つのことを実行できます。最初のことは、クライアントがサーバーと公開鍵を交換するときに、仲介者がクライアントの公開鍵を自分のものに置き換えることができるということです。このように、サーバーによって取得された公開鍵は、クライアントではなくサーバーに属します。サーバーは、公開鍵のソースの正確さを判断できません。2つ目は、仲介者は公開鍵を置き換えることはできませんが、クライアントから送信されたメッセージを傍受して改ざんし、サーバーの公開鍵で暗号化してサーバーに送信することはできます。サーバーは誤ったメッセージ。
2.非対称暗号化のパフォーマンスは、システムリソースを消費する対称暗号化のパフォーマンスよりも数倍または数百倍遅くなります。httpsが2つの暗号化を組み合わせるのは、まさにこのためです。
2.デジタル証明書とデジタル署名
非対称暗号化における公開鍵のソースの不安定さを解決するため。この問題を解決するために、デジタル証明書とデジタル署名を使用できます。
1.デジタル証明書の申請
実際には、デジタル証明書の発行に使用される専門機関がいくつかあります。これらの組織をCA認証局と呼びます。私たち（サーバー）は、これらのCAからデジタル証明書を申請できます。申請プロセスはおおまかに次のとおりです。最初にローカルで鍵のペアを生成し、次に独自の公開鍵とその他の情報（会社名など）をCAに渡して、デジタル証明書を申請します。CAは情報を取得した後、一方向ハッシュアルゴリズム（一般的なMD5など）を選択して情報を暗号化します。暗号化されたものはダイジェストと呼ばれます。一方向ハッシュアルゴリズムの特徴の1つは、一方向で元に戻せないことです。元のコンテンツが少し変更されている限り、暗号化されたデータは大きく異なります（もちろん、そうなる可能性はわずかです。繰り返します。興味がある場合は、情報が改ざんされるのを防ぐハトの巣の原則について学びます。）ダイジェストが生成された後、CAは独自の秘密鍵を使用してダイジェストも暗号化します。ダイジェストが暗号化された後のデータはデジタル署名と呼ばれます。最後に、CAはアプリケーション情報（サーバーの公開鍵を含む）をデジタル署名と統合して、デジタル証明書を生成します。次に、CAはデジタル証明書を私たちに渡します（これは別の質問につながる可能性があります。認証局はどのようにしてデジタル証明書をサーバーに安全に渡すことができますか？送信プロセス中にデジタル証明書が仲介者に置き換えられた場合はどうなりますか？この質問の場合実は、今申請すれば、認証センターはhttps経由で渡されますが、最初にhttpsがない場合は？実はよくわかりませんが、絡む必要はありません。ニワトリ卵を産む、終わりのない、デジタル証明書は誰もが申請できるものではないと考えており、厳格な認証が必要です。とにかく、デジタル証明書は安全にサーバーに到達できます）。
2.デジタル証明書はどのように機能しますか？
サーバーがデジタル証明書を取得した後、サーバーはデジタル証明書をクライアントに送信します。クライアントはCAの公開鍵を使用してデジタル証明書を復号化し、デジタル証明書の正当性を検証する必要があります。CAの公開鍵を取得するにはどうすればよいですか？機関のルート証明書の一部はコンピューターとブラウザーに組み込まれており、これらのルート証明書にはCAの公開鍵が含まれています。
ルート証明書の理由は、実際には、認証センターが階層的であるためです。つまり、最上位の認証センターと、その下の各サブレベルの認証センターがあります。これはツリー構造であり、構築されています。 -コンピュータ内が最上位の組織のルート証明書ですが、心配しないでください。ルート証明書の公開鍵はサブレベルにも適用できます。
クライアントはCAの公開鍵を使用してデジタル証明書を復号化します。復号化が成功した場合、証明書は法的な認証局から取得されます。復号化が成功すると、クライアントはダイジェストを取得します。このとき、クライアントはCAと同じハッシュアルゴリズムに従ってアプリケーション情報の概要を生成し、復号化されたコピーと比較します。同じ場合、コンテンツは完全であり、改ざんされていません。最後に、クライアントは証明書からサーバーの公開鍵を安全に取得し、安全な非対称暗号化でサーバーと通信できます。サーバーは、同じ方法でクライアントの公開鍵を取得しようとしています。
次の図は、一般的な証明書の適用と使用プロセスをグラフで示しています。
3、httpsの原則
上記の調査を通じて、対称暗号化と非対称暗号化の特性、長所と短所、およびデジタル証明書の役割を理解しています。httpsは、単一のテクノロジーを使用して実現するのではありませんが、その特性に応じて、これらのテクノロジーを完全に統合して、最大のパフォーマンスと安全性を実現します。この統合テクノロジーはSSL（Secure Scoket Layer）と呼ばれます。したがって、httpsは新しいプロトコルではなく、暗号化されたシェルをhttpに配置するだけです。
httpsの確立
確立されたフローチャートを見てみましょう。
ここでは、httpsの確立から切断までを6つの段階と12のプロセスに分けています。以下では、12のプロセスを1つずつ説明します。
1.クライアントは、ClientHelloメッセージを送信してSSL通信を開始します。メッセージには、クライアントでサポートされている指定されたバージョンのSSLと、暗号化コンポーネント（Cipher Suite）のリスト（使用されている暗号化アルゴリズムとキーの長さなど）が含まれています。
2.サーバーがSSL通信を実行できる場合、サーバーはServerHelloメッセージで応答します。クライアントと同様に、SSLバージョンと暗号化コンポーネントがメッセージに含まれています。サーバーの暗号化コンポーネントのコンテンツは、クライアントの受信した暗号化コンポーネントからフィルタリングされます。
3.サーバーは証明書メッセージを送信します。メッセージには公開鍵証明書が含まれています。
4.最後に、サーバーはServer Hello Doneメッセージを送信して、最初のSSLハンドシェイクネゴシエーション部分が終了したことをクライアントに通知します。
5.最初のSSLハンドシェイクが終了した後、クライアントはクライアントキー交換メッセージで応答します。メッセージには、通信暗号化で使用されるプリマスターシークレットと呼ばれるランダムなパスワード文字列が含まれています。メッセージは、手順3で公開鍵で暗号化されています。
6.次に、クライアントはChange CipherSpecメッセージを送信し続けます。このメッセージは、このメッセージの後の通信がプリマスター秘密鍵で暗号化されることをサーバーに促します。
7.クライアントはFinishedメッセージを送信します。このメッセージには、これまでに接続されたすべてのメッセージの全体的なチェック値が含まれています。ハンドシェイクネゴシエーションが成功するかどうかは、サーバーがメッセージを正しく復号化できるかどうかによって決まります。
8.サーバーはChangeCipherSpecメッセージも送信します
9.サーバーはFinishedメッセージも送信します
10.サーバーとクライアントのFinishedメッセージが交換された後、SSL接続が確立されます。もちろん、通信はSSLによって保護されます。ここから、アプリケーション層プロトコルの通信が開始されます。つまり、HTTP要求が送信されます。
11.アプリケーション層プロトコル通信、つまりHTTP応答の送信。
12.最後に、クライアントが切断されます。接続が切断されると、close_notifyメッセージが送信されます。上の図はいくつか省略されています。この手順の後、TCPFINメッセージを送信してTCPとの通信を閉じます。
また、上記のフローチャートでは、アプリケーション層がデータを送信するときに、MAC（メッセージ認証コード）と呼ばれるメッセージダイジェストが添付されています。MACは、メッセージの整合性を確保するために、メッセージが改ざんされているかどうかを確認できます。
ダイアグラムを使用して視覚的に説明しましょう。このダイアグラムは、上記のデジタル証明書のダイアグラムよりも詳細です（写真は「グラフィックHTTP」からのものです）
上記の紹介の後、httpsが最初にデジタル証明書を使用して、サーバーの公開鍵がクライアントに安全かつエラーなしで到達できることを確認していることがわかります。次に、非対称暗号化を使用して共有キーを安全に転送し、最後に共有キーを使用してデータを安全に交換します。
第四に、httpsの使用
httpsは非常に安全ですが、どのようなシナリオで通信にhttpsを使用しますか？答えは否定的です。
1. httpsは安全なメッセージ送信のためのチャネルを提供しますが、各メッセージの暗号化と復号化には時間がかかり、メッセージシステムリソースが必要です。したがって、銀行システムやショッピングシステムなど、セキュリティが比較的高いシナリオでは通信にhttpsを使用する必要があり、セキュリティ要件が低い他のシナリオでは、実際にはhttpsを使用する必要はありません。
2. httpsの使用にはデジタル証明書の使用が必要ですが、一般的に権威ある機関によって発行されたデジタル証明書は有料であり、価格も高いため、一部の個人Webサイト、特に学生の場合、セキュリティ要件が高くない場合は、 httpsを使用する必要はありません。
参照
https://www.jianshu.com/p/4932cb1499bf
https://mp.weixin.qq.com/s/StqqafHePlBkWAPQZg3NrA
「図解されたHTTP」