HTTPS / SSLリクエストをスニッフィングできるのはなぜですか？
私はHTTPリクエストとセキュリティの領域などすべての良いものに不慣れですが、私が読んだことから、リクエストとレスポンスを暗号化したい場合は、HTTPSとSSLを使用すれば、大丈夫です。 前の質問 の誰かがこのアプリへのリンクを投稿しました http://www.charlesproxy.com/ これは、実際にHTTPSリクエストを傍受して、 PLAINテキストでの要求と応答。
私はfacebook.comのログインでこれを試してみましたが、実際にユーザー名とパスワードがプレーンテキストで表示されました。それはも簡単でした。どうしたの？それがHTTPSの核心であると思いました-要求と応答を暗号化することですか？
これは SSLプロキシ のページで説明されていますが、おそらく十分な説明はありません。
プロキシは、定義により man-in-the-middle です。クライアントはプロキシに接続し、プロキシはサーバーに接続します。
SSLは2つのことを行います。
- 確立された接続の機密性と完全性を保証します。
- 接続している相手の確認を行います。
これは重要で、壊れているように見える2番目の部分です。ブラウザの前に座って、ブラウザがFacebookに接続することを期待していたのに、プロキシに接続していることに驚いています。技術的には、プロキシはHTTPSトラフィックをスニッフィングせず、リレーします。
サイトには certificate があり、「私は本当に_www.facebook.com_」と表示されているため、ブラウザはFacebookに接続されていることを認識しています。 公開キーの暗号化 、ここでは説明しませんが、秘密キーの所有者のみがこの証明書との有効な接続を開始できるようにします。それは戦いの半分に過ぎません。サーバーは、それが本当に_www.facebook.com_であり、_randomhijacker.com_ではないという主張しかありません。ブラウザーが行うことは、証明書が 認証局 によって検証されていることをさらに確認することです。ブラウザまたはオペレーティングシステムには、信頼できる認証局のリストが付属しています。繰り返しになりますが、公開鍵暗号化により、CAのみがブラウザが受け入れる証明書を発行できるようになります。
プロキシに接続すると、ブラウザは「私は本当に_www.facebook.com_」という証明書を受け取ります。ただし、この証明書は、ブラウザーがデフォルトで信頼するCAによって署名されていません。そう：
- 安全でないHTTPS接続に関する警告を受信したか、クリックして_
https://www.facebook.com/_で濃度を確認しました。 - または プロキシの証明書に署名したCAを追加 （「チャールズのCA証明書」）を、ブラウザが信頼するCAのリストに追加します。
どちらの方法でも、プロキシを信頼するようにブラウザに指示しました。そうです。ランダムな見知らぬ人を信頼し始めた場合、SSL接続は安全ではありません。
詳細情報の推奨読書：
セッション 対称キー にアクセスできない限り、 https を解除することはできません。つまり、 https セッションは次のように機能します。
- クライアントとサーバーはいくつかの初期情報を交換します
- この情報を使用して、クライアントは サーバーを認証 でき、信頼できるものであることを確認します
- クライアントはサーバーの 公開鍵 を使用して暗号化された秘密を送信します
- サーバーは彼の 秘密鍵 を使用してこの秘密を復号化します（認証されたサーバーのみがそれを実行できます！）
- クライアントとサーバーの両方が秘密を使用してセッション対称鍵をローカルに生成します
- 他の誰も自分のセッション対称鍵を知らないので、今や彼らは安全にお互いに話すことができます
途中で第三者が共有シークレットにアクセスできるようになった場合、セッションの対称鍵を生成して通信を復号化することもできます。