HTTPSはTLS/SSLプロトコルを使用してコンテンツを暗号化しますが、TLSが動作するレイヤーは多岐にわたり、トランスポートレイヤーに分類されるものもあれば、アプリケーションレイヤーに分類されるものもあります。簡単に言うと、トランスポート層とアプリケーション層の間にあるプロトコルの層で、一番下がTCP、一番上がHTTPSです。
まず、HTTPSのTLSハンドシェーク・プロセスを見てください：
SSL/TLS は秘密鍵のネゴシエーションの段階では 非対称暗号を使い、メッセージの送信の段階では 対称暗号を使うことがわかります。対称暗号の秘密鍵は非対称暗号を使ってネゴシエートされます。対称暗号と非対称暗号の詳細には触れませんが、 SSL/TLS において非常に重要な概念は証明書です。以下の節では証明書の役割に焦点を当てます。
最初に考えなければならないのは、暗号化の目的が何であるかということです。暗号化の主な目的の1つは、中間者攻撃を防ぐことです。では、HTTPSがどのようにして中間者攻撃を防ぐのか、順を追って見ていきましょう。
まず、最も単純なシナリオである平文通信について考えてみましょう。この場合、攻撃者が2人の通信トラフィックをハイジャックしている限り、すべての情報は攻撃者にとって透過的です。** HTTPS 暗号化の基本的な目的は、トラフィックをハイジャックされた仲介者が通信の特定の内容を解析できないようにすることです。**以下のすべての操作は、いくつかのシナリオで問題を解決するために、この目的からです。
暗号化が必要である以上、秘密鍵が必要であり、両者が秘密鍵を知っている必要があり、これが有名な秘密鍵交渉です。これは有名な秘密鍵の交渉です。 両方が秘密鍵を知る必要があるので、秘密鍵も送信する必要があります。そこで問題なのは、もしネゴシエーションのプロセスもハイジャックされたらどうなるか、ということです。仲介者も秘密鍵を持っていて、あなたの操作と同じであれば、攻撃者にとっては無意味です。そこで、この問題を解決するメカニズムが必要です。
秘密鍵ハイジャック問題の解決
この問題を解決するには、非対称暗号化という大きな名前を使う必要があります。公開鍵で暗号化されたものは秘密鍵でしか復号化できず、公開鍵は公開することができます。同様に秘密鍵で暗号化されたものは公開鍵で復号化できますが、秘密鍵は主にデジタル署名に使われ、公開鍵で検証されます。この場合、秘密鍵のネゴシエーションの段階では、相手から渡された公開鍵で暗号化することができます。公開鍵がハイジャックされても、公開鍵で暗号文を復号する方法がないので問題ありません。しかし、中間業者が交換プロセスを乗っ取り、自分の公開鍵と秘密鍵のペアを通信に使っていたらどうでしょうか。<->例えば、A Bが通信中で、Cが攻撃者だとします。B->Aが公開鍵を送信する過程で、Cがトラフィックをハイジャックし、BがAに送信する公開鍵をC自身のものに置き換えます。こうすることで、Aは実際にはCの公開鍵を取得し、Cは自分の秘密鍵を保持することになります。詳しくは図をご覧ください。
ID偽造問題への対応
HTTPSは、この問題を解決するために証明書を使用して、証明書はあなたがあなたが言う人であることを証明します。秘密鍵を通じて非対称暗号化メカニズムでは、情報に署名することができますし、当事者の署名を受信する公開公開鍵を使用して確認することができます知っています。証明書は、本質的にドメイン名や公開鍵などの証明書に添付された他の情報が正しいことを証明するために、正しいエンティティと公開鍵の対応を格納する信頼できる当事者です。
CA 証明書と証明書チェーン
認証局と証明書
上記の認証問題を解決する鍵は、公開鍵のパスが正当なものであり、サーバーの身元情報を検証できることを保証することです。そのためには、公開鍵の所有者の情報を検証し、認証「証明書」を発行する責任を持ち、同時に利用者に証明書認証サービスを提供できる権威ある第三者組織CA（例えばVodafone CA）を導入すること、すなわちPKIシステムが必要です。
基本的な原則は、CAが情報を確認する責任を負い、秘密鍵を使用して鍵情報に「署名」し、対応する公開鍵を開示することで、クライアントが公開鍵を使用して署名を検証できるようにすることです。CAはまた、発行済みの証明書を失効させることができ、基本的な方法には、CRLファイルとOCSPの2種類があります：
a. サービスプロバイダ S は、公開鍵、組織情報、個人情報などの情報を第三者機関 CA に提出し、認証を申請。
b. CA は、組織が存在するかどうか、事業が合法的かどうか、ドメイン名の所有権があるかどうかなど、オンライン、オフラインを含む様々な手段で、申請者から提供された情報の信憑性を検証します。
c. 情報監査に合格した場合、認証局は申請者に対し、認証文書である証明書を発行します。 証明書には、申請者の公開鍵、申請者の組織情報および個人情報、発行局 CA の情報、有効期限、証明書シリアル番号などの情報が平文で記載され、署名も含まれる。署名生成アルゴリズム：まず、ハッシュ関数を使用して公開情報の情報概要を平文で計算し、次に CA の秘密鍵を使用して情報概要を暗号化し、署名となる暗号文を生成。
d. クライアントCがサーバSにリクエストを送信すると、サーバSは証明書ファイルを返します。
e. クライアントCは、証明書の関連する平文情報を読み取り、同じハッシュ関数を使用して情報要約を計算し、対応するCAの公開鍵を使用して署名データを復号化し、証明書の情報要約を比較し、一致する場合、証明書の正当性を確認することができます。
f. 次に、クライアントは、証明書に関連するドメイン名情報、有効期間、その他の情報を検証します。
g.クライアントは、信頼できるCAの証明書情報を組み込みます。 信頼できないCAの場合、該当するCAの証明書が見つからず、不正な証明書と判断されます。
このプロセスのいくつかのポイントに注意してください：
a. 証明書の申請に秘密鍵は不要であり、秘密鍵はサーバのみが永久に保持することができます。
b. 証明書の正当性は依然として非対称暗号化アルゴリズムに依存しており、証明書は主に署名だけでなくサーバー情報も追加します。
c. 組み込みCAに対応する証明書はルート証明書と呼ばれ、発行者と利用者が同一であり、自己のために署名する、すなわち自己署名証明書です。
d. 証明書＝公開鍵＋申請者・発行者情報＋署名
証明書の連鎖
CAルート証明書とサーバ証明書は、中間証明書、つまり、真ん中に認証局のレベルを追加する場合は、証明書の生成と検証の原則は、単に最後の信頼できるCAルート証明書によって検証することができる限り、検証のレイヤーを追加し、変更はありません正当なものです。
a. サーバ証明書server.pemは中間認証局interによって発行され、中間認証局interは、server.pemが本当に証明書inter.pemに基づいて自分自身によって発行された有効な証明書であることを検証します。
b. 中間証明書inter.pemの発行CAはrootであり、inter.pemが証明書root.pemに基づいて自ら発行した正当な証明書であることを検証します。
c. クライアントはCAのroot.pem証明書に対する組み込みの信頼を持っているので、サーバ証明書server.pemは信頼されています。
サーバ証明書、中間証明書、ルート証明書が組み合わされて正規の証明書チェーンを形成し、証明書チェーンの検証はボトムアップの信頼移転プロセスです。 セカンダリ証明書構造が存在するメリット
a. ルート証明書構造の管理における作業負荷が軽減され、より効率的な審査と証明書の発行が可能になります。
b.ルート証明書は一般的にクライアントに内蔵され、秘密鍵は一般的にオフラインで保管され、一旦秘密鍵が流出すると、失効プロセスは非常に困難であり、時間内に修復することはできません。
c. 中間証明書構造の秘密鍵が危殆化した場合、オンラインで迅速に失効させることができ、利用者に対 して新しい証明書を再発行することができます。
d. レベル 4 までの証明書チェーンは、一般に HTTPS のパフォーマンスに大きな影響を与えません。
証明書チェーンには以下のような特徴があります：
a. 同じサーバ証明書に対して、複数の正当な証明書チェーンが存在する可能性があります。 証明書の生成と検証は公開鍵と秘密鍵のペアに基づいて行われるため、同じ公開鍵と秘密鍵を使用して異なる中間証明書を生成した場合、発行者にとっては、中間証明書の発行局が異なるだけで、正規のCAです。
b. 異なる証明書チェーンのレベルは必ずしも同じではなく、2つ、3つ、または4つのレベルの証明書チェーンがあるかもしれません。 中間証明書の発行局はルート証明書局である場合もあれば、別の中間証明書局である場合もあり、証明書チェーンのレベルは必ずしも同じではありません。
1.パフォーマンス上の理由から、平文の真の暗号化には対称暗号を使用し、非対称暗号は秘密鍵ネゴシエーションにのみ使用します。
2.HTTPSはパケット・キャプチャを防止しません。通信の両当事者が攻撃者によって作成されたルート CA 証明書をインストールしていれば、偽造された証明書チェーンを使用して攻撃者の CA 証明書を検証できます。
3.TLSとSSLの関係についてですが、TLSはSSL3.0の後継です。TLSとSSL 3.0の間には、主にサポートする暗号アルゴリズムに大きな違いがあり、TLSとSSL 3.0は相互運用できません。TLSは現在一般的に
