大手工場の面接：HTTPSを3回連続で聞かれ、最後の質問は人が多いかどうか
- Java后端技术全栈転載
- 2023-08-28 16:43:231364ブラウズ
皆さんこんにちは。有益な情報を共有することを専門にしている Lao Tian です。また、インタビュー資料が必要な友人は、バックステージで忘れずに返信してください。インタビュー
##序文
HTTPS が HTTP よりも安全であることは誰もが知っています。また、SSL、非対称暗号化、CA 証明書など、HTTPS プロトコルに関連する概念についても聞いたことがあるでしょう。しかし、次の 3 つの魂を苦しめる質問には答えられないかもしれません:
なぜ HTTPS は安全なのでしょうか? HTTPS の基本原理を実装するにはどうすればよいですか? #HTTPS の使用は必ずしも安全ですか?
HTTPS の実装原理
HTTPS プロトコルが安全である理由は次のとおりであると誰もが聞いたことがあるかもしれません。 HTTPS このプロトコルは送信データを暗号化し、暗号化プロセスは非対称暗号化を使用して実装されます。しかし、実際には、HTTPS は対称暗号化を使用してコンテンツ送信を暗号化し、非対称暗号化は証明書の検証フェーズでのみ機能します。
HTTPS の全体的なプロセスは、証明書の検証段階とデータ送信段階に分かれており、具体的な対話プロセスは次のとおりです:
- ブラウザは HTTPS リクエストを開始します。 #サーバーは HTTPS 証明書を返します。
- クライアントは証明書が合法かどうかを検証し、合法でない場合は警告を発します。
- データ送信フェーズ:
- 証明書が正当であることが検証されると、乱数がローカルで生成されます。
- 乱数を公開鍵で暗号化し、暗号化された乱数をサーバーに送信します。
- サーバーは秘密キーを使用して乱数を復号します。
- サーバーは、クライアントから渡された乱数を使用して対称暗号化アルゴリズムを構築し、返された結果コンテンツを送信する前に暗号化します。
まず、非対称暗号化の暗号化と復号化の効率は非常に低く、HTTP アプリケーションのシナリオでは通常、エンド間で多くの対話が発生し、非対称暗号化は行われません。効率は受け入れられません。
さらに、HTTPS シナリオでは、サーバーのみが秘密キーを保存し、公開キーと秘密キーのペアでは一方向の暗号化と復号化しか実現できないため、HTTPS でのコンテンツ送信暗号化には対称暗号化が採用されます。非対称暗号化の代わりに暗号化を使用します。
HTTP プロトコルは、リスナーが送信プロセスを簡単にフックしてサーバーを監視したり偽造したりできるため、安全ではないと考えられていますが、HTTPS プロトコルは主にネットワーク送信のセキュリティ問題を解決します。 。
まず、認証局が存在せず、誰でも証明書を作成できると仮定しますが、これによってもたらされるセキュリティ リスクは、典型的な「中間者攻撃」の問題です。
「中間者攻撃」の具体的なプロセスは次のとおりです。
- ローカル リクエストがハイジャックされ (DNS ハイジャックなど)、すべてのリクエストが仲介者のサーバーに送信されます。
- 仲介者サーバーは仲介者自身の証明書を返します。
- クライアントは乱数を作成し、仲介者証明書の公開キーを使用して乱数を暗号化して仲介者に送信し、その乱数を使用して対称暗号化を構築して暗号化します。送信内容。
- 仲介者はクライアントの乱数を持っているため、対称暗号化アルゴリズムを通じてコンテンツを復号化できます。
- 仲介者は、クライアントのリクエスト コンテンツを使用して、通常の Web サイトへのリクエストを開始します。
- 仲介者とサーバー間の通信プロセスは合法であるため、通常の Web サイトは確立された安全なチャネルを通じて暗号化されたデータを返します。
- 仲介者は、正規の Web サイトで確立された対称暗号化アルゴリズムを使用してコンテンツを復号します。
- 仲介者は、クライアントとの間で確立された対称暗号化アルゴリズムを通じて、通常のコンテンツによって返されるデータを暗号化して送信します。
- クライアントは、仲介者と確立した対称暗号化アルゴリズムを通じて、返された結果データを復号します。
証明書には次の情報が含まれています:
#発行機関情報 公開鍵 - ##会社情報 # #ドメイン名
- 有効期間
- フィンガープリント
- ....
証明書の法的根拠は何ですか? まず、権威ある組織が認証される必要があります。どのような組織でも証明書を発行できる資格があるわけではありません。そうでなければ、その組織は権威のある組織とは言えません。
また、証明書の信頼性はトラストシステムに基づいており、権威ある組織が発行した証明書を承認する必要があり、権威ある組織が発行した証明書である限り、合法であること。
したがって、権威ある組織が申請者の情報を審査します。さまざまなレベルの権威ある組織には異なる審査要件があるため、証明書も無料、安価、高価に分かれています。
ブラウザは証明書の有効性をどのように検証するのでしょうか? ブラウザが HTTPS リクエストを開始すると、サーバーは Web サイトの SSL 証明書を返します。
ブラウザは証明書に対して次の検証を実行する必要があります:
- ドメイン名、有効期間、その他の情報が正しいかどうかを確認します。証明書にはこの情報が含まれているため、検証を簡単に完了できます。
- 証明書のソースが合法かどうかを確認します。発行された各証明書は、検証チェーンに従って対応するルート証明書を見つけることができます。オペレーティング システムとブラウザは、権限のある組織のルート証明書をローカルに保存します。ローカル ルート証明書を使用して、対応する組織によって発行された証明書のソース検証を完了できます。組織。
- #** 証明書が改ざんされているかどうかを確認します。 **CA サーバーによる検証が必要です。
OCSP をステップ 3 で使用すると、CA サーバーとの対話を削減し、検証効率を向上させることができます。
ブラウザは、上記の手順のいずれかが満たされた場合にのみ、証明書が正当であるとみなします。
**私が長い間考えてきた質問をここに挿入しますが、答えは実際には非常に簡単です: **証明書は公開されているため、中間者を起動したい場合この種の証明書詐欺を回避するにはどうすればよいですか?
実際には、これは暗号化されていない対称性での公開鍵と秘密鍵の使用であり、仲介者は証明書を取得できますが、秘密鍵は取得できません。
公開鍵から対応する秘密鍵を推測することは不可能であり、仲介者が証明書を取得したとしても、クライアントから渡された暗号化データを復号化できないため、正規のサーバーになりすますことはできません。
ブラウザでセキュリティ リスクについてのプロンプトを表示しないようにする必要がある場合は、証明機関が発行した証明書のみを使用できます。 しかし、ブラウザは通常、セキュリティ リスクを要求するだけで、Web サイトへのアクセスを制限しないため、技術的には誰でも証明書を生成でき、証明書がある限り Web サイトの HTTPS 送信を完了できます。 。 たとえば、初期の 12306 では、プライベート証明書の手動インストールを使用して HTTPS アクセスを実現していました。
証明書の検証は非対称暗号化を使用して実装されますが、送信プロセスでは対称暗号化が使用され、対称暗号化アルゴリズムの重要な乱数はローカルで生成され、ローカルに保存されます。はい、その方法HTTPS は乱数が盗まれないことを保証しますか?
実際には、HTTPS には乱数のセキュリティ保証は含まれていません。HTTPS は送信プロセスのセキュリティのみを保証し、乱数はローカルに保存されます。ローカル セキュリティは別のセキュリティ カテゴリに属します。対策には、アンチウイルスのインストールが含まれます。 - ウイルス ソフトウェア、トロイの木馬対策、脆弱性を修正するためのブラウザのアップグレードなど。
HTTPS データは暗号化されています。通常の状況では、プロキシ要求後にパケット キャプチャ ツールによってキャプチャされたパケットの内容は暗号化されているため、直接表示することはできません。
ただし、上で述べたように、ブラウザはセキュリティ リスクを警告するだけであり、ユーザーがそれを許可すれば、引き続き Web サイトにアクセスしてリクエストを完了することができます。
したがって、クライアントが自分の端末であり、それを許可する限り、仲介ネットワークを構築でき、パケット キャプチャ ツールが仲介者の役割を果たします。
通常、証明書の生成には HTTPS パケット キャプチャ ツールが使用されます。ユーザーは証明書をクライアントに手動でインストールする必要があります。その後、端末によって開始されたすべてのリクエストは、これを介してパケット キャプチャ ツールとの対話を完了します。証明書。
次に、パケット キャプチャ ツールはリクエストをサーバーに転送し、最後にサーバーから返された結果をコンソールに出力し、それを端末に返します。これにより、リクエストの閉ループ全体が完了します。
HTTPS ではパケット キャプチャを防ぐことはできないのですが、HTTPS には何の意味があるのでしょうか? HTTPS は、ユーザーが知らないうちに通信リンク上で監視されることを防ぐことができますが、このシナリオのユーザーはすでにリスクを認識しているため、アクティブなクレジット付与パケット キャプチャ操作に対する保護は提供されません。
パケット キャプチャを防ぐには、プライベート対称暗号化や、ローカル アルゴリズムのクラックを防ぐためのモバイル端末の逆コンパイル防止強化など、アプリケーション レベルのセキュリティ保護を採用する必要があります。
概要
以下は、全文の簡単な Q&A の概要です。 # Q: HTTPS が安全なのはなぜですか?#A: HTTPS は通信のセキュリティを確保し、通信プロセスの監視やデータの盗難を防ぎ、Web サイトの信頼性を確認できるためです。
Q: HTTPS の送信プロセスは何ですか?
#A: クライアントは HTTPS リクエストを開始し、サーバーは証明書を返し、クライアントは証明書を検証し、検証に合格した後、対称暗号化アルゴリズムの変更に使用される乱数をローカルで生成します。 乱数は暗号化され、証明書内の公開キーを使用してサーバーに送信されます。乱数を受信した後、サーバーは秘密キーを使用して乱数を復号します。その後のデータのやり取りは対称暗号化を使用して暗号化および復号されます。アルゴリズム。
Q: 証明書が必要なのはなぜですか?A: 「中間者」攻撃を防止し、Web サイトに ID 証明を提供します。
Q: HTTPS を使用するとパケットはキャプチャされますか?A: パケットはキャプチャされます。HTTPS は、ユーザーが知らない間に監視されることを防ぐだけです。ユーザーが積極的にクレジットを付与すると、「仲介者」ネットワークが構築され、プロキシ ソフトウェアがパケットを監視できます。送信されたコンテンツを復号化します。 HTTPS を学習するプロセス図を共有したいと思います:
以上が大手工場の面接：HTTPSを3回連続で聞かれ、最後の質問は人が多いかどうかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。