httpsはプロキシサーバーによる中間者攻撃を防ぎますか？
Https接続でウェブサイトWに接続しているデスクトップクライアントAがあります。
A --> W
どういうわけかAとWの間には、プロキシGがあります。
A --> G --> W
- この場合、GはAが以前にWから取得した証明書を取得できますか？
- Gが証明書を取得できる場合、それはGがデータを復号化できることを意味しますか？
HTTPSはどのように機能しますか？
HTTPSはpublic/private-key cryptographyに基づいています。これは基本的に鍵ペアがあることを意味します。公開鍵は暗号化に使用され、秘密秘密鍵は復号化に必要です。
certificateは基本的に、所有者を識別するラベルが付いた公開鍵です。
そのため、ブラウザーがHTTPSサーバーに接続すると、サーバーは証明書で応答します。ブラウザ証明書が有効かどうかを確認：
- 所有者情報は、ユーザーが要求したサーバー名と一致する必要があります。
- 証明書は、信頼できる証明機関によって署名されている必要があります。
これらの条件のいずれかが満たされない場合、ユーザーは問題について通知されます。
検証後、ブラウザは公開鍵を抽出しますを使用して、サーバーに送信する前に情報を暗号化します。 サーバーに一致する秘密キーがあるであるため、サーバーはそれを復号化できます。
HTTPSは中間者攻撃をどのように防止しますか？
この場合、GはAが以前にWから取得した証明書を取得できますか？
はい、証明書はラベル付きの公開鍵です。ウェブサーバーはそれに接続する誰にでもそれを送ります。
Gが証明書を取得できる場合、それはGがデータを復号化できることを意味しますか？
いいえ。証明書にはウェブサーバーの公開鍵が含まれています。悪意のあるプロキシは、一致する秘密鍵を所持していません。したがって、プロキシが実際の証明書をクライアントに転送する場合、クライアントがWebサーバーに送信する情報を復号化することはできません。
プロキシサーバーは、証明書を偽造し、代わりに独自の公開キーを提供しようとする場合があります。ただし、これは証明機関の署名を破棄するになります。ブラウザは無効な証明書について警告します。
プロキシサーバーがHTTPSを読み取る方法はありますか？
コンピュータの管理者が協力するの場合、プロキシサーバーがhttps接続を傍受する可能性があります。これは、ウイルスをスキャンし、許容できる使用のガイドラインを実施するために、一部の企業で使用されています。
ローカル認証局がセットアップされ、管理者がブラウザにこれをCAが信頼できるであることを伝えます。プロキシサーバーはこのCAを使用して、偽造された証明書に署名します。
もちろん、ユーザーはセキュリティ警告をクリックして離れる傾向があります。
ユーザーが証明書の警告をクリックしていないと仮定し（変更されていないクライアントを実行していると想定）、答えは次のとおりです：いいえ、プロキシはデータを復号化できません。
HTTPSが中間者によるトラフィックの復号化を防ぐ方法の詳細については、SSL/TLSの標準リソースを参照してください。たとえば、
追伸証明書は公開データです。サーバーの公開鍵とドメイン名が含まれていますが、どちらも秘密ではありません。証明書を確認しても、攻撃者がデータを復号化することはできません。 （はい、プロキシは証明書を監視できますが、これは無害です。）
Philipp C. Heckelのハイテクブログ から若干の編集を加えたもの：
暗号化されていないHTTPトラフィックを攻撃することは、X.509証明書や認証局（CA）を処理することなく実行できますが、SSL暗号化HTTPS接続は、クライアントとサーバー間のすべての要求と応答をエンドツーエンドで暗号化します。また、転送されたデータは共有シークレットで暗号化されているため、仲介者（またはプロキシ）は交換されたデータパケットを解読できません。クライアントがセキュアなウェブサーバーへのSSL/TLS接続を開くと、2つの条件をチェックしてサーバーのIDを確認します。最初に、クライアントが知っているCAによって証明書が署名されているかどうかをチェックします。次に、サーバーの共通名（CN、ホスト名）が接続先の名前と一致することを確認します。両方の条件に該当する場合、クライアントは接続が安全であると想定します。
接続を探知できるようにするために、Proxyサーバーは認証局として機能できますが、信頼できるものではありません。実際の個人または組織に証明書を発行する代わりに、プロキシは接続に必要なホスト名に動的に証明書を生成します。たとえば、クライアントが https://www.facebook.com に接続する場合、プロキシは「www.facebook.com」の証明書を生成し、独自のCAで署名します。クライアントがこのCAを信頼している場合、上記の両方の条件が当てはまります（信頼されたCA、同じCN）。つまり、クライアントは、プロキシサーバーが実際には「www.facebook.com」であると信じています。次の図は、このシナリオの要求/応答フローを示しています。このメカニズムは透過的HTTPSプロキシと呼ばれます。
この攻撃が機能するためには、いくつかの条件を満たす必要があります。
- 標準ゲートウェイとしてのプロキシサーバー（HTTPおよびHTTPS）：HTTPとHTTPSの両方のプロキシでは、プロキシサーバーがIPパケットを傍受できる必要があります—つまり、パケットパスの途中にある必要があります。これを実現する最も簡単な方法は、クライアントデバイスのデフォルトゲートウェイをプロキシサーバーのアドレスに変更することです。
- 信頼できるプロキシCA（HTTPSのみ）：HTTPSプロキシが機能するには、クライアントはプロキシCA、つまりCAキーを知っている（そして信頼する）必要があります。ファイルをクライアントのトラストストアに追加する必要があります。
プレーンなSSLソケットを透過的にスニッフィングすることに関心がある場合は、透過的なTLS/SSL中間者プロキシである
SSLsplitを試してみてください。 SSLを攻撃する方法はたくさんありますが、偽のSSL証明書、不正な認証局（CA）、またはセキュリティの専門家であるMoxie Marlinspikeの中間者SSL攻撃のバリエーションは必要ありません。 Blue Coat SystemsのProxySGや最近取得したNetronome SSLアプライアンスなどのSSLインターセプトプロキシを購入して、その仕事をすることができるのに、なぜそんな面倒なことをするのでしょうか。
From ZDNetのSteven J. Vaughan-Nichols （抜粋）：
SSLインターセプトビジネスの最大の名前であるBlue Coatは、SSLインターセプトを提供し、箱から出して提供する唯一のものではありません。たとえば、最近まで、MicrosoftはForefront Threat Management Gateway 2010というプログラムを販売していました。 SSLインターセプトプロキシプログラムまたはデバイスを配置すると、実際に次のことが起こります。
会社がプロキシを正しく設定している場合、プロキシの内部SSL証明書が有効な証明書としてマシンに登録されるように設定されているため、何もオフになっていないことはわかりません。そうでない場合は、ポップアップエラーメッセージが表示されます。続行するためにクリックすると、「偽の」デジタル証明書を受け入れます。どちらの場合も、プロキシへの安全な接続が確立され、外部サイトへの安全な接続が確立されます。プロキシを介して送信されたすべてのものがプレーンテキストで読み取られます。おっと。
使用しているネットワークの構成によっては、管理者がHTTPS接続（および場合によってはVPN）の内容を表示できる可能性があります。
明らかにネットワーク上のトラフィックを傍受することは可能ですが、通常の問題は、アクセスするすべてのサイトに対して有効な証明書を発行できないため、HTTPSサイトにアクセスするたびに多くの証明書警告が表示されることです。彼らはそれを見てトラフィックを解読しようとします。
ただし、会社が提供するマシンを使用している場合は、新しい認証局をインストールし、それを使用して、アクセスするサイトのSSL証明書を作成できるため、問題として表示されません。
VPNに関しては、VPNがSSLを使用しない場合はさらに複雑になる可能性がありますが、同じ理論が適用されます。あなたが彼らが制御するネットワーク上の他の誰かが所有するマシンからインターネットにアクセスする場合、彼らはあなたが入力したあらゆるコンテンツにアクセスする可能性があります。
この種の問題を回避したい場合は、あなたが所有/管理しているデバイスを使用してインターネットにアクセスします。そうすれば、SSLインターセプトが発生した場合に警告が表示されます。
企業のネットワーク管理者は、自分のCAを使用してTLSクライアントに対する中間者攻撃を実装し、ネットワークから何が流出しているかを確認できるようにします。彼らはおそらく、gmail.comにアクセスしたときにgmail.comに有効な証明書を即座に作成するデバイスを持っているでしょう。彼らがこれを行う理由は、Dr。Evilをプレイするためではありません。それは、彼らがインターネット接続を介して彼らの建物から企業秘密が送られるのを防ぐことができるようにするためです。真剣に、仕事用のコンピューターでプライベートバンキングを行わないでください。
システム証明書ストアを使用しないソフトウェア製品（たとえば、OpenVPNインスタンス）を使用している場合、CAを信頼していないため、トラフィックを傍受してデコードすることはできません。たとえば、Firefoxポータブルアプリを使用しても同じ結果が得られる場合があります。また、ほとんどのブラウザでは、安全な接続の詳細をチェックし、誰がCAであるかを確認して、誰がリッスンしているかどうかを確認できます。
プロキシはhttpsをブロックし、ブラウザからのhttpのみを許可できます。次に、独自のhttps接続を開始して、リクエストをサーバーに渡すことができます。
ほとんどのユーザーは気付かないでしょう。
HSTSはこれを止めるはずですが、広く使われていません。
SSLターミネーションまたはBluecoatなどのSSLプロキシ製品はネットワーク上にある必要があり、コスト、関連するインストール手順、およびこれらの製品をインストールする組織が持つであろう通常のセキュリティポリシーを考慮してください-商用SSLターミネーション製品を使用する悪意のある攻撃者の脅威はほぼゼロ。 OTOH-NOC（ネットワークオペレーションセンター）にアクセスできる信頼できるインサイダーは、実際にはSSLで終了するトラフィックを監視し、機密情報を開示する可能性があります。
これは、DLPシステムを実装する企業に共通する懸念事項（正当化されるかどうかにかかわらず）です。
ただし、ホームバンキングスペースでは一般的な、ネットワークプロキシを必要とせず、ブラウザでのピッグバック/シム攻撃である別の攻撃方法があります。DOMは、ヒットする前にクリアテキストトラフィックにアクセスできるためです。 SSLパイプ-これは便利な攻撃経路であり、多くの場合、ブラウザ拡張機能を介してインストールされます。シムに関する優れたStackexchange記事があります- シム（別名ポリフィル）をIE、FF、またはChromeにユーザーの知識なしにインストールでき、ユーザーが入力したパスワードを読み取ることができますか？ログインページで？