web-dev-qa-db-ja.com

スーパーフィッシュ対企業MITM

私はコンサルティング会社で働いており、すべてのユーザートラフィック用のクラウドプロキシであるセキュリティベンダーのツールを実装しています。マルウェアのスキャンとすべてのWebトラフィックのフィルタリングを実行します。これは、プロキシ自動構成ファイルを適用して、HTTP/HTTPSトラフィックをベンダーのグローバルデータセンターの1つにリダイレクトすることで機能します。もちろん、HTTPSトラフィックをプロキシし、マルウェアスキャンのためにMITMを実行するために、各ワークステーションに証明書を展開する必要があります。

私の質問:これはスーパーフィッシュがルート証明書をインストールするのとどう違うのですか? Superfishの秘密鍵がマシンにどのように保存されるかについて読んでいます。企業のMITM攻撃には同じ脆弱性がないと思いますが、企業環境ではアーキテクチャがどのように異なるのですか?

23
jay-charles

Superfish、および同様の製品(ここではすべて「Superfish」と呼ぶ)が企業のMitMと異なる点は、SuperfishがクライアントマシンでMitMを実行していることです。企業のMitMは、別のサーバーまたはアプライアンスで実行されます。

MitMを実行するシステムが機能するには、信頼されたルートCAの秘密キーが必要なので、これは重要です。 (厳密に言えば、ルートCAは信頼されている必要はありません。信頼されていない場合、ユーザーには赤いフラグが表示されます。)

Superfishの場合、これはキーがクライアントデバイス上にある必要があることを意味します。これは、よくメンテナンスされておらず、一般に攻撃に対して非常に脆弱です。

企業のMitMの場合、キーは監視サーバーにあります-通常、定期的なメンテナンスを行い、システムを不必要なリスクにさらすようなこと(例:Webブラウジング、追加のソフトウェアのダウンロード、ドキュメントのオープンなど)を行わない経験豊富な担当者が保守します。 。

ただし、すべてのSSLプロキシ(企業またはその他)は、リモートシステムの証明書を自己検証するクライアントの機能が削除されているという事実を考慮して、慎重に実装する必要があります。特にこれは以下を意味します:

  1. SSLプロキシmustリモートシステムの証明書を適切に検証し、ユーザーに適切に警告するか、何かが間違っている場合は接続を完全にドロップします。 Charles Duffyがコメントで述べたように、証明書を適切に検証するには、プロキシが自身の組み込みCAを信頼しないことも必要です。
  2. 理想的には、SSLプロキシは、履歴またはコミュニティで集約された参照証明書に対して整合性の検証も行う必要があります。これは一部のWebブラウザー拡張機能に実装されており、通常の状況ではユーザーが手動で実行できるため、それ以外の場合は信頼できるルートCAの不正使用を検出できます。 SSLプロキシは、ユーザーが自分でこれを実行したり、この目的でブラウザ拡張を効果的に使用したりする機能を削除するため、プロキシが独自のチェックを行って補正できるのが最適です。 (これはほとんどの企業のMitM製品で利用できるとは思えませんが)。

このサービスは外部のベンダーから提供されているとのことですが、SSLプロキシはユーザーのすべてのトラフィックを暗号化されていないかのように見ることができるということも注意する必要があります。 (それがSSLプロキシの目的です。)つまり、サードパーティのビューアから保護する必要があるデータは、信頼を乱用することを選択した場合、ベンダーによって完全に表示されます。

40
Iszi

Superfishと企業プロキシの主な違いは、新しいSSL証明書が生成される方法です。

Superfishの場合、CA証明書および秘密鍵はクライアントコンピューター上にあり、ソフトウェアは自身が持っている鍵を使用して新しいSSL証明書を生成します。トラフィックはローカルで傍受され、クライアントで新しい証明書が生成され、ブラウザに送信されます。デバッグツールにアクセスできる人はだれでも証明書とキーを抽出できます。これらは両方ともクライアントコンピューター上にあるためです。

コーポレートプロキシの場合、CA証明書はすべてのクライアントコンピュータにインストールされますが、秘密鍵はプロキシサーバーにあります。サーバーが適切に保護されている場合、キーは危険にさらされません。トラフィックはプロキシサーバーで傍受され、新しい証明書と共にクライアントに送信されます。秘密鍵はサーバー上にのみ存在するため、クライアントで秘密鍵を抽出することはできません。

5
ThoriumBR

他の問題は実装の詳細については正しいですが、関係するセキュリティの問題は承認の問題です。

Superfishおよび関連するものの場合、システム所有者は通常、SuperfishがHTTPS経由で送受信されるすべてのものを読み取れることを望んでいません。自宅のコンピュータでは、おそらくSuperfishにクレジットカードの詳細やオンラインの健康の詳細などを持たせたくないでしょう。企業では、通常、Superfishがビジネス目的でアクセスするすべてのものを管理できるようにしたくはありません。企業のWebメールクライアントにアクセスする場合、または企業秘密について何かを調査する場合。また、superfishは、コンピュータを入手する前にインストールされ、適切に配置されていることを警告されないという点で、これらのことを少しこっそりと行います。そのため、その使用を承認または拒否する機会はありません。

企業のMitMでは、会社はシステムの所有者であり、エンドユーザーではなく、Superfishではありません。会社は、セキュリティを向上させるために、承認され、そのリスクと価値が受け入れられているプロキシサーバーをセットアップします。

プロキシの基本的な考え方が必ずしも悪いわけではありません。許可されていない会社/個人があなたのものにアクセスすることを許可する許可されていないプロキシが悪いということです。

0
atk