最近、Superfish(および同様のアドウェア)について多くのことを読み、基本的にMITM攻撃に対する脆弱性を理解しています。しかし、実際には、Kaspersky Antivirusによる " secure connection scan "がSuperfishの例と同じくらい壊れているのではないかと思っています。
つまり、Kasperskyは私のコンピューターにルート証明書をインストールし、マルウェアをスキャンするためにすべての接続を「中間者」にします。私の理解では、これはスーパーフィッシュの災害よりも良いことではありません...カスペルスキーをより安全にするものは何ですか?
うまくいけば、誰かがテストを行い、カスペルスキーの決定的な答えをあなたに提供してくれるでしょう。一方、一般的なケースの答えは次のとおりです。
状況によります
自分に対してSSLプロキシを実行すると、セキュリティ体制が弱まりますか?もちろん。特定の製品は、スーパーフィッシュと同じくらい悪いあなたのセキュリティ態勢を弱めるでしょうか?これは非常に実装依存であり、個々の製品自体に対する脅威にもさらされます。
スーパーフィッシュは2つの重要なポイントで失敗しました。
脆弱なパスワードを使用して、各システムに固有ではない秘密鍵を保護しました。これにより、キーが簡単に解読されて公開されるため、誰もが承認されたSuperfishプロキシのふりをすることができます。
SSL証明書の特定の条件を適切に検証できなかったため、Superfishプロキシは無効な証明書を受け入れ、正当なものであるかのようにWebサイトをエンドユーザーに提示できました。
最初の部分は重要な中断ですが、間違いなく最も重大な欠陥であるのは2番目の部分です。 2番目の欠陥がなければ、キーが秘密のままである限り、ユーザーは依然として比較的よく保護されます。 (Kerckhoffsの動作原理)ただし、2番目の欠陥を考えると、攻撃者はSuperfishユーザーと他の方法で安全なWebサイトとの間で説得力のあるMan-in-the-Middle攻撃を開始するためのキーすら必要としません。
これを考慮に入れると、ユーザーを大幅に保護できるいくつかの簡単な対策があります。
インストールごとに一意のルートキーを生成し、強力で一意のパスワードでそれらを保護します。プロキシが存在するホストを超えてキーを配布しないでください。これにより、1つのシステムのキーの開示が他のシステムのセキュリティに大きな影響を与えることが防止されます。
SSL証明書を適切に検証し、何か誤りがある場合はユーザーに適切な通知を提供します。これがなければ、キーはそれほど重要ではありません-攻撃者は、検証プロセスの欠陥を悪用することによって、自分のサイトが正当であることをプロキシに説得する必要があり、プロキシはそのようなサイトをユーザーに提示します。
これらを正しく取得すれば、問題ありません。まあ、そうではありません。
さて、今度はユーザーに証明書を提示するときに問題が発生します。プロキシはトラフィックを傍受し、独自の資格情報でキーを再入力する必要があるため、ユーザーはサイトの元の資格情報を見ることはありません。すべてのサイトには、プロキシによって発行された証明書があり、プロキシがMitM証明書をいつ生成したかに応じた日付と時刻のスタンプが付いています。これにより、ユーザー自身が信頼できるCAまたは信頼パスを決定したり、時間の経過に伴う証明書の変更を認識したりするユーザー自身の機能が完全に削除されます。また、他の信頼できる外部エンティティとの証明書の裏付けも防止します。
DigiNotarを例にとります。攻撃者は、一般的に信頼されているルートCAを使用して、Googleサービスの偽の証明書を生成することができました。 SSLプロキシが配置されていない場合、ユーザーは、いくつかの方法の1つ以上によって不審なアクティビティを警告される可能性があります。
プロキシを使用すると、これらのオプションはすべてエンドユーザーが利用できなくなります。プロキシ自体は、これらの問題を監視して警告するように構成できます(一部のブラウザプラグインと同じように)が、最終的にエンドユーザーは自分自身でそれを見ることができなくなります。