簡単に言うと、SSLとは、通信の両当事者が非対称暗号化を介して対称暗号化の鍵をネゴシエートすることを意味します。
デジタル証明書とCA
対称暗号化、非対称暗号化、ダイジェストアルゴリズムを組み合わせて使用することで、セキュリティの4つの主要な機能を実現しました。完璧ですか？
いいえ、ここには「公開鍵の信頼」の問題もあります。
誰でも公開鍵を公開できるため、***が公開鍵を偽造するのを防ぐ手段がまだありません。つまり、公開鍵があなたのものであるか、宝物の公開鍵であるかをどのように判断するのでしょうか。
http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
1. zfbは、独自の公開鍵、秘密鍵、および公開鍵を生成してWebサイトにダウンロードし ます。2。Xiaomingはzfb公開鍵をダウンロードし、この公開鍵を使用して情報data1（注文要求の生成）をdata1_encとして暗号化して送信します。それをzfb3.zfbに 移動し、暗号化された情報data1_encに移動し、独自の秘密鍵を使用してdata1の 関連データのロックを解除し、処理するビジネスデータdata2を計算し（Xiaomingにこの注文の支払いを通知）、 ハッシュアルゴリズムを使用しますdata2のダイジェストを生成するにはdata2_digest 独自の秘密鍵でダイジェストを暗号化するdata2_digest_encはデジタル署名署名で あり、data2 + data2_digest_encをXiaoming4に送信します。Xiaoming はdata2 + data2_digest_encを受信し、zfbの公開鍵でdata2_digest_encをdata2_digestに復号化します 。情報がzfbによって送信され 、次にdata2に送信されることを証明します。ハッシュ関数を使用して取得した結果は、data2_disgetと比較されます。1が正しければ、情報は完全であり、改ざんされていません -------- -------------------- ------------------------------ --- しかし、ある日、XiaoMingはXiaoHuiによって密かに使用されました。以前に取得したzfb公開鍵をXiaohui自身の公開鍵に置き換えました（Xiaohui がAlipay Webサイトを自分の公開鍵に置き換えた後、Xiaomingがzfbの代わりにXiaohuiの公開鍵をダウンロードする） Xiaoming here誰か（実際にはXiao Hui）が注文し、Xiao Huiの公開鍵でデータを暗号化してzfbに送信しました。XiaoHuiは、XiaoMing もちろん、Alipayは彼の秘密鍵でできませんでした。 が途中でAlipayに送信したデータを取得しました。そして彼の秘密鍵でそれを解読しました。 控除がない場合、Xiao Mingは支払いが成功したことを通知され、Xiao Mingが商品を配達した後、アカウントが注文の代金を受け取っていないことに気付きました ------------- --------- ----------------------------------------- --------- --Xiao Mingは異常な後、信頼できる機関CAを見つけることにしました。彼 が、公開鍵と秘密鍵をzfbに使用して公開鍵認証を行うために、CAへの公開鍵を使用してzfbを許可します。 デジタルで生成された他の暗号化情報の一部証明書の 後、zfbがXiaomingにメッセージを送信すると、デジタル証明書とともに送信されました。Xiaomingがメッセージを 受信した後、CAの公開鍵を使用して、証明書内の情報のロックを解除し、 zfbの実際の公開鍵。 現在の唯一の問題は、CAが信頼されていることです。
同様の鍵交換方法を使用して公開鍵認証の問題を解決し、他の秘密鍵を使用して公開鍵に署名することができます。明らかに、これは「無限再帰」に分類されます。しかし、今回は本当に「動きがない」ので、この「明確なループ」を終わらせるには、「外力」を導入し、認められた信頼できる第三者を見つけ、それを「信頼の出発点と再帰の終わり」にする必要があります。公開鍵の信頼の連鎖を構築します。この「サードパーティ」は、私たちがよくCA（認証局）と呼ぶものです。
オンライン世界の公安局、文部省、公証人センターのようなもので、信頼性が高く、各公開鍵に署名し、独自の評判を利用して、公開鍵が偽造されないようにし、信頼できるものにします。 。
公開鍵のCAの署名証明書もフォーマットされます。公開鍵を所有者のIDにバインドするだけでなく、シリアル番号、目的、発行者、有効時間なども含まれ、これらを入力します。次に、パッケージに署名して、公開鍵に関連付けられたさまざまな情報を完全に証明し、「デジタル証明書」（証明書）を形成します。
DigiCert、VeriSign、Entrust、Let's Encryptなど、世界でよく知られているCAはわずかです。発行される証明書は、DV、OV、EVに分けられます。違いは、信頼性の程度にあります。DVは最低であり、その背後にあることを知らないドメイン名レベルの信頼性にすぎません。EVは最高です。法律と監査による厳密な検証の後、Webサイトの所有者の身元を証明できます（会社の名前は、AppleやGitHubのWebサイトなどのブラウザーのアドレスバーに表示されます）。
しかし、CAはどのようにそれ自体を証明するのでしょうか？これはまだ信頼の連鎖の問題です。
小さいCAは大きいCAで署名できますが、チェーンの最後では、ルートCAはそれ自体を証明することしかできません。これは「自己署名証明書」または「ルート証明書」（ルートCA）証明書と呼ばれます。信じる必要があります。そうしないと、証明書の信頼チェーン全体がダウンしません。
この証明書システムでは、オペレーティングシステムとブラウザに主要なCAのルート証明書が組み込まれています。サーバーがインターネットを閲覧するときに証明書を送信する限り、証明書チェーン（証明書チェーン）に従って証明書の署名を検証できます。 ）レイヤーごとに検証した後、ルート証明書が見つかるまで、証明書が信頼できると判断できるため、内部の公開鍵も信頼できます。
実験環境で使用される証明書は、「Yeluzi」（LinuxのOpenSSLコマンドラインで発行）の自己署名証明書であり、ブラウザからは絶対に信頼されないため、Chromeでアクセスすると赤で表示されます。安全ではないとマークされています。ただし、システムのルート証明書ストアにインストールし、信頼チェーンのルートにする限り、危険な警告はありません。
認証制度の弱点
証明書システム（PKI、公開鍵インフラストラクチャ）は、オンライン世界全体の現在のセキュリティインフラストラクチャですが、絶対的なセキュリティは存在しません。また、弱点があり、「信頼」というキーワードです。
CAが間違いを犯したり、だまされて間違った証明書を発行したりした場合、証明書は本物ですが、それが表すWebサイトは偽物です。
さらに危険な状況があります。CAがVPNによって侵害されているか、CAが悪意のあるものです。これは、CA（ルート証明書）が信頼のソースであり、信頼チェーン全体のすべての証明書が信頼されていないためです。
これらの2つのことは「センセーショナル」ではなく、両方とも実際に起こっています。したがって、いくつかのパッチを証明書システムに適用する必要があります。
最初のタイプでは、問題のある証明書をタイムリーに取り消すために、CRL（証明書失効リスト）とOCSP（オンライン証明書ステータスプロトコル）が開発されました。
2番目のタイプの場合、関係する証明書が多すぎるため、オペレーティングシステムまたはブラウザーは、ルートから「冷酷」になり、CAの信頼を取り消して「ブラックリスト」に入れ、すべての証明書が発行されるようにすることしかできません。それによって安全でないと見なされます
- ダイジェストアルゴリズムは完全性を実現するために使用され、データに固有の「フィンガープリント」を生成できます。一般的に使用されるアルゴリズムはSHA-2です。
- デジタル署名は、ダイジェストへの秘密鍵の暗号化であり、公開鍵による復号化後に検証して、ID認証と否認防止を実現できます。
- 公開鍵の配布には、CAの信頼チェーンによって検証される必要があるデジタル証明書の使用が必要です。そうでない場合、信頼されません。
- 信頼の連鎖のソースとして、CAは信頼できない場合があります。ソリューションには、CRL、OCSP、および信頼の終了が含まれます。
機密性：ハイブリッド暗号化によって解決され、非対称暗号化は対称暗号化キー送信を実現し、対称暗号化はコンテンツ暗号化を実現します。
完全性：解決するにはダイジェストアルゴリズムに依存します。
ID認証：デジタル証明書によって解決されます。CA組織の信頼により、デジタル証明書は完全な信頼の連鎖になり、デジタル証明書を通じて相手の真のIDを証明しますが、真であることに注意してください。アイデンティティも悪い人かもしれません。したがって、CRL、OCSP、および信頼の終了を伴います。
拒否不可：デジタル署名に依存して解決し、コンテンツダイジェストアルゴリズムがダイジェストを取得し、秘密鍵がダイジェストを暗号化し、相手方が対応する公開鍵を使用して復号化し、ダイジェストを取得して、取得したサーバーは、このコンテンツが元のサーバーによって提供されていることを示しています。サーバーのIDは証明書によって記述されています。
証明書の検証
サーバーは証明書チェーン（ブラウザーで事前設定されているルート証明書を含まない）を返し、
ブラウザーは信頼されたルート証明書（ルート公開鍵）を使用して証明書チェーンのルート証明書を解析し、公開鍵を取得できます。 +第1レベルの証明書のダイジェスト署名を検証し
、プライマリ証明書の公開鍵を使用してプライマリ証明書を復号化し、検証のためにセカンダリ証明書の公開鍵とダイジェストを取得してから、セカンダリ証明書
の公開鍵を使用しますセカンダリ証明書を復号化してサーバーの公開鍵を取得し、検証のためにダイジェストします。検証プロセスは終了しました。
デジタル署名とデジタル証明書は、主にサーバーの公開鍵をブラウザーに正しく送信できるようにするために、TSL / SSLのハンドシェイクフェーズでのみ使用されます（偽の公開鍵を送信するために仲介者に偽装されることはありません）。
具体的なプロセスはおそらく次のとおりです。
- 1.サーバーはCAにアクセスして証明書を申請します。証明書には、クライアントに送信される公開鍵、発行者、有効期限などの情報が含まれています。
この方法で証明書をブラウザに送信するだけで、仲介者は簡単に自分の公開鍵に変更できます。その後の通信は安全ではない
ため、特定の暗号化方法が必要です。ここでの方法は、デジタル署名を使用することです。情報を使用する証明書内ダイジェストアルゴリズムがダイジェストを計算した後、CAの秘密鍵で暗号化されてデジタル署名が生成されます
- 2.サーバーはデジタル証明書とデジタル署名を一緒にブラウザに送信します。デジタル署名のため、仲介者はデジタル証明書を変更できません（変更後に生成されたデジタル署名は元のデジタル署名と一致しません）。ブラウザの後デジタル証明書を取得し、ローカルの信頼できる組織に移動して対応する組織を見つけ、その公開鍵を使用してデジタル署名を復号化し、証明書が変更されているかどうかを確認します。
この手順により、ブラウザによって取得された公開鍵が正しい必要があります。 - 3.公開鍵がブラウザに正しく送信されたら、次のステップは対称暗号化鍵をネゴシエートしてから通信することなどです。