HTTPS の原則の説明

HTTPS ウェブサイトの構築コストが下がるにつれて、ほとんどのウェブサイトが HTTPS プロトコルを使用するようになりました。 HTTPS が HTTP よりも安全であることは誰もが知っており、SSL、非対称暗号化、CA 証明書など、HTTPS プロトコルに関連する概念についても聞いたことがあります。しかし、次の 3 つの自問自答には答えられないかもしれません。

1. HTTPS の使用が安全なのはなぜですか?

2. HTTPS の基本原理はどのように実装されていますか?

3. HTTPS を使用すると安全ですか?

この記事では、HTTPS のセキュリティを原理からさらに詳しく説明します。

HTTPSの仕組み

HTTPS プロトコルが安全である理由は、HTTPS プロトコルが送信されるデータを暗号化し、暗号化プロセスが非対称暗号化を使用して実装されているためであると聞いたことがあるかもしれません。しかし実際には、HTTPS はコンテンツの送信に対称暗号化を使用し、非対称暗号化は証明書の検証段階でのみ機能します。

HTTPS の全体的なプロセスは、証明書の検証とデータ転送の段階に分かれています。具体的な相互作用プロセスは次のとおりです。

① 証明書検証フェーズ

ブラウザがHTTPSリクエストを開始する

サーバーはHTTPS証明書を返します

クライアントは証明書が合法かどうかを確認し、合法でない場合は警告が表示されます。

②データ伝送段階

1. 証明書が正当であることが検証されると、ローカルで乱数が生成されます。

2. 公開鍵で乱数を暗号化し、暗号化された乱数をサーバーに送信する

3. サーバーは秘密鍵を使用して乱数を復号化する

4. サーバーはクライアントから渡された乱数を使用して対称暗号化アルゴリズムを構築し、返された結果を暗号化して送信します。

データ転送に対称暗号化が使用されるのはなぜですか?

まず、非対称暗号化の暗号化と復号化の効率は非常に低いです。HTTP アプリケーションのシナリオでは、通常、エンド間のやり取りが多いため、非対称暗号化の効率は受け入れられません。

さらに、HTTPS シナリオでは、サーバーだけが秘密鍵を保存し、公開鍵と秘密鍵のペアでは一方向の暗号化と復号化しか実現できないため、HTTPS でのコンテンツ伝送暗号化では非対称暗号化ではなく対称暗号化が採用されます。

証明書を発行するために CA が必要なのはなぜですか?

HTTP プロトコルは、送信プロセスが盗聴者によって簡単に傍受され、サーバーが偽造される可能性があるため安全ではないと考えられていますが、HTTPS プロトコルは主にネットワーク送信のセキュリティ問題を解決します。

まず、認証局が存在せず、誰でも証明書を作成できると仮定します。これによって生じるセキュリティ リスクは、典型的な「中間者攻撃」の問題です。

「中間者攻撃」の具体的なプロセスは以下のとおりです。

プロセス原理:

1. ローカルリクエストがハイジャックされ（DNSハイジャックなど）、すべてのリクエストが仲介者のサーバーに送信される

2. 仲介者サーバーは仲介者自身の証明書を返す

3. クライアントは乱数を生成し、それを仲介者の証明書の公開鍵で暗号化して仲介者に送信し、その乱数を使用して対称暗号化を構築し、送信内容を暗号化します。

4. 仲介者はクライアントの乱数を持っているため、対称暗号化アルゴリズムを通じてコン​​テンツを復号化できる。

5. 仲介者はクライアントのリクエスト内容を通常のウェブサイトに送信します。

6. 仲介者とサーバー間の通信プロセスは合法であるため、正当なウェブサイトは確立された安全なチャネルを通じて暗号化されたデータを返します。

7. 仲介者は、公式サイトで確立された対称暗号化アルゴリズムを使用してコンテンツを復号化する

8. 仲介者は、クライアントと確立した対称暗号化アルゴリズムを使用して、通常のコンテンツから返されたデータを暗号化して送信します。

9. クライアントは、仲介者と確立した対称暗号化アルゴリズムを使用して、返された結果データを復号化する。

証明書の検証がないため、クライアントが HTTPS リクエストを開始しても、クライアントはネットワークが傍受され、送信内容が仲介者によって完全に盗まれたことにまったく気づきません。

ブラウザはどのようにして CA 証明書の正当性を確認するのでしょうか?

1. 証明書にはどのような情報が含まれていますか?

発行機関情報

公開鍵

会社情報

ドメイン名

有効

指紋

......

2. 証明書の法的根拠は何ですか?

まず第一に、権威ある組織は認証を受ける必要があります。すべての組織が証明書を発行する資格を持っているわけではなく、そうでなければ権威ある組織とは言えません。

さらに、証明書の信頼性は信頼システムに基づいています。権威ある組織は、発行する証明書を承認する必要があります。証明書が権威ある組織によって生成されたものである限り、私たちはそれを合法であるとみなします。

したがって、権威ある組織は申請者の情報を審査します。異なるレベルの権威ある組織は審査の要件が異なるため、証明書は無料、安価、高価に分かれています。

3. ブラウザは証明書の正当性をどのように検証しますか?

ブラウザが HTTPS リクエストを開始すると、サーバーは Web サイトの SSL 証明書を返します。ブラウザは次のように証明書を検証する必要があります。

1. ドメイン名、有効期間などの情報が正しいかどうかを確認します。証明書にはこの情報が含まれているため、検証が容易になります。

2. 証明書の発行元が合法かどうかを判断します。発行された各証明書は、検証チェーンに基づいて対応するルート証明書を見つけることができます。オペレーティング システムとブラウザーは、認証局のルート証明書をローカルに保存します。ローカル ルート証明書を使用して、対応する組織によって発行された証明書のソース検証を完了できます。

3. 証明書が改ざんされていないかどうかを確認します。 CA サーバーで検証する必要があります。

4. 証明書が取り消されているかどうかを確認します。これは、CRL (証明書失効リスト) と OCSP (オンライン証明書ステータス プロトコル) によって実現されます。OCSP は、ステップ 3 で使用すると、CA サーバーとのやり取りを減らし、検証の効率を向上させることができます。

ブラウザは、上記の手順のいずれかが満たされた場合にのみ、証明書を正当なものとみなします。

これは私が長い間考えてきた質問ですが、答えは実はとても簡単です。

証明書は公開されているため、中間者攻撃を仕掛けたい場合は、公式 Web サイトから証明書をサーバー証明書としてダウンロードすると、クライアントは確実にこの証明書が正当なものであると認識します。このような証明書のなりすましを回避するにはどうすればよいですか?

実際、これは暗号化されていない対称認証における公開鍵と秘密鍵の使用です。仲介者は証明書を取得できますが、秘密鍵を取得することはできません。公開鍵から対応する秘密鍵を推測することは不可能です。仲介者が証明書を取得できたとしても、クライアントから渡された暗号化されたデータを復号化できないため、正当なサーバーに偽装することはできません。

4. 証明書を生成できるのは認証局だけですか?

ブラウザでセキュリティ上のリスクが発生しないようにするには、認証局が発行した証明書のみを使用できます。ただし、ブラウザは通常、セキュリティ上のリスクを通知するだけで、Web サイトへのアクセスを制限しないため、技術的には誰でも証明書を生成でき、証明書があれば Web サイトの HTTPS 送信を完了できます。たとえば、初期の 12306 では、HTTPS アクセスを実現するためにプライベート証明書を手動でインストールする方法が採用されていました。

ローカル乱数が盗まれた場合はどうすればいいですか?

証明書の検証は非対称暗号化を使用して実装されますが、送信プロセスでは対称暗号化が使用されます。対称暗号化アルゴリズムの重要な乱数はローカルで生成され、保存されます。HTTPS ではどのようにして乱数が盗まれないようにするのでしょうか?

実際、HTTPS には乱数のセキュリティ保証は含まれていません。HTTPS は送信プロセスのセキュリティのみを保証します。乱数はローカルに保存され、ローカル セキュリティは別のセキュリティ カテゴリに属します。対策としては、ウイルス対策ソフトウェア、トロイの木馬対策ソフトウェアのインストール、脆弱性を修正するためのブラウザのアップグレードなどがあります。

HTTPS を使用するとキャプチャされますか?

HTTPS データは暗号化されます。通常、プロキシ要求後にパケット キャプチャ ツールによってキャプチャされたパケットの内容は暗号化されており、直接表示することはできません。 WeChat のパブリック アカウント「Java Technology Stack」をフォローし、バックグラウンドで返信してください: tools と入力すると、私がまとめた最新の開発ツール チュートリアルの N 個が入手できます。これらはすべて実用的なものです。

ただし、前述のように、ブラウザはセキュリティ上のリスクのみを通知します。ユーザーが承認した場合は、引き続き Web サイトにアクセスし、リクエストを完了できます。したがって、クライアントが自社端末であり、それを認証していれば、仲介ネットワークを形成でき、パケットキャプチャツールが仲介エージェントとして機能します。

通常、HTTPS パケット キャプチャ ツールは証明書を生成するために使用されます。ユーザーはクライアントに証明書を手動でインストールする必要があります。その後、端末によって開始されたすべての要求は、証明書を介してパケット キャプチャ ツールとのやり取りを完了します。次に、パケット キャプチャ ツールは要求をサーバーに転送します。最後に、サーバーから返された結果がコンソールに出力され、その後端末に返され、要求全体のクローズド ループが完了します。

HTTPS ではパケット キャプチャを防止できないので、HTTPS の意味は何でしょうか?

A: クライアントが HTTPS リクエストを開始し、サーバーが証明書を返し、クライアントが証明書を検証します。検証に合格すると、対称暗号化アルゴリズムを変換するための乱数がローカルで生成されます。乱数は証明書の公開キーを使用して暗号化され、サーバーに送信されます。乱数を受信したサーバーは、秘密キーを使用して乱数を復号化し、乱数を取得します。その後のデータ インタラクションは、対称暗号化アルゴリズムを使用して暗号化および復号化されます。

Q: なぜ証明書が必要なのですか?

A: 「中間者」攻撃を防ぎ、Web サイトの ID 検証を提供します。

Q: HTTPS を使用するとキャプチャされますか?

A: パケットはキャプチャされます。HTTPS は、ユーザーの知らないうちにユーザーの通信が監視されるのを防ぐだけです。ユーザーが積極的に信頼を与えると、「中間者」ネットワークが構築され、プロキシ ソフトウェアが送信されたコンテンツを復号化できます。

上記は、HTTPS 原則の詳細な説明です。HTTPS 原則の詳細については、123WORDPRESS.COM の他の関連記事に注目してください。