記事ディレクトリ
序文
前回の記事で、httpは安全ではない、Cookieやセッションを採用していても途中でユーザー情報が抜き取られる可能性がある、という話をしましたが、httpの安全でない特性に着目してhttpsが誕生しました。
HTTP
http の送信プロセスでは、完全に平文で送信されるため、情報が改ざんされ、盗まれる可能性があります。https は、データの安全性と信頼性を確保するために、http に基づいて暗号化層を追加し、改ざんされないこと。
私たちのデータパケットはオペレーター/ハッカーのネットワーク機器を通過するため、オペレーターのネットワーク機器は私たちが送信したデータを解析し、直接改ざんすることができます。
暗号化方式
インターネット上で平文を送信することは非常に危険なので、データを暗号化した方がよいでしょう。一般的な暗号化方式には次のものがあります。
対称暗号化
- 体系的な暗号化を使用すると
单密钥、同じキーで暗号化と復号化の両方が可能になります。 - アルゴリズムが公開されており、計算量が少なく効率が高い
非対称暗号化
- 暗号化には公開キーと秘密キーの 2 つのキーが必要です。
- アルゴリズムは非常に強力ですが、暗号化速度は非常に遅いです。
公開キーでデータを暗号化すると暗号文が形成され、
秘密キーで暗号文が復号化されると平文が形成されます。
秘密鍵で平文が暗号化された後、暗号文が形成され、
公開鍵で暗号文が復号化された後、平文が形成されます。
データの概要 (データのフィンガープリント)
データ フィンガープリント (データ サマリー): 文字通り、一方向ハッシュ関数を使用して情報を操作し、一連の固定長のデジタル サマリーを生成します。このプロセスは不可逆です。
データ フィンガープリントは暗号化メカニズムではありませんが、変更があるとデータ フィンガープリントが大幅に変更されるため、データが改ざんされているかどうかを判断できます。
デジタル署名
デジタル ダイジェストが暗号化された後、デジタル署名が形成されます。
デジタル ダイジェストも暗号化する必要があります。暗号化しないと、仲介者がハッシュ値を再計算し、私たちを騙す可能性があります。
暗号化方式
対称暗号化のみを使用する
オプション 1 だけを使用するのは安全ではありません。キーを交換するときにプレーン テキストで送信する必要があり、仲介者はキーを取得できる可能性があるからです。同時に、サーバーは各クライアントに対応するキー関係を維持する必要があり、これも非常に面倒です。
非対称暗号化のみを使用する
サーバーは依然として公開鍵を平文でクライアントに送信する必要があるため、仲介者は公開鍵を秘密裏に独自の公開鍵 B に置き換える機会を得ることができます。
両側で非対称暗号化を使用する
この方法は依然として仲介者によって乗っ取られる可能性があり、効率の問題も生じます。
対称+非対称
オプション 4 では、3 に基づいて効率が向上しますが、それでもセキュリティの問題は回避できません。中間者は依然として公開鍵 A を置き換えることができます。
証明書
上記の解決策に基づいて、たとえ仲介者が後で介入できないとしても、クライアントが受け取った公開鍵がクライアントによって送信される必要があることを保証できないことがわかりました。
HTTPS を使用する前に、サーバーは CA 組織にデジタル整数を申請する必要があります。サーバーはブラウザに証明書を渡し、ブラウザは証明書から公開キーを直接取得します。証明書は信頼できるものでなければなりません。
CA 認証プロセス:
署名と検証:
では、CA 組織の公開鍵は仲介者によって傍受される心配はないのでしょうか? CA 組織は権威ある組織であるため、合法性を確保するために、CA の公開キーは通常、工場からダウンロードされたときにブラウザとオペレーティング システムに組み込まれます。
- データを変更するとハッシュ値が変更され、正しいハッシュ値とは異なります
- 署名を変更すると、正しい CA 公開キーで正しく復号化できなくなります
- CA だけが秘密キーを持っているため、自分で証明書を置き換えることはできません
要約すると、対称 + 非対称 + CA 認定証明書によって、https が安全なプロトコルであることが保証されます。
その他の問題:
-
なぜハッシュは暗号化されるのでしょうか? 仲介者によるハッシュの再計算を防ぐため
-
署名を直接暗号化するだけで、なぜハッシュするのでしょうか? 時間を節約するために。