web-dev-qa-db-ja.com

ブラウザーがカスタムルートCAを許可するのはなぜですか?

私の仕事では、すべてのブラウザーにカスタムルートCAがインストールされています。これにより、ユーザーが安全なhttpsページを閲覧しているという誤った印象をユーザーが受ける一方で、すべてのhttpsトラフィックをスヌープできます。

なぜブラウザはhttpsのそのような簡単な敗北を許可し、それについてユーザーに警告しないのですか?

編集:回答/コメントに基づいて、私はおそらく混乱の間違った部分を誤って強調していたことに気づきました。 CAリストを変更する必要がある正当なニーズがあることを理解していますが、そのような変更が行われた場合にユーザーに警告したくないのはなぜですか。ユーザーにアドレスの横にある緑色のボックスのポイントを無効にすることを警告しませんか?本当に何回かクリックする必要がありますか?次に、(侵害された)検索を実行して、ルートCAが私が所有していないコンピュータの本物であるかどうか、および/または誰かに他の人に触れさせたかどうかを調べますぼくのコンピュータ?

25
eddi

ブラウザーがこれを許可する正当な理由は実際にはなく、許可しないようにする必要があります。欠陥のある正当化について1つずつ取り上げます。

  1. ウェブ開発。 root CAは必要ありません。開発を行っている単一のドメインまたはドメインの小さな有限セットの証明書だけに署名する必要があります。代わりに、ブラウザはCA証明書の追加を許可できます特定のドメインに対してのみ有効。このような証明書が使用されている場合は、任意に署名できるCA証明書の追加を許可するのではなく、URLバーで警告します。ドメイン。

  2. エンタープライズおよびAV MITM。これらは、他の場所で議論されている理由から、単に悪い考えです。 AVをMITMではなくエンドポイントに実装します。 MITMによる資産管理は、本当にナイーブなユーザー以外には機能しません。 MITMによる資産管理が必要と思われるほど機密性の高いデータがある場合は、おそらくインターネットにアクセスできないエアギャップシステムが必要です。

  3. 「ブラウザーが許可しない場合、ルートCAを追加したい管理者はブラウザーを変更するだけです。」はい、それは常に可能です技術的に可能ですが、ブラウザのベンダーは、CAトラストUXを改ざんしないようにブラウザの商標の使用を条件付けるだけで、それを法的に困難または不可能にする機会があります。私はこれを長い間提唱してきました。ブラウザーがこれを行った場合、ユーザーは、システム上で「Firefox」または「Chrome」を見るとすぐに、誰かがMITMを許可するための不正な証明書を受け入れないことを知るでしょう信頼する限りシステムを設置した当事者が法を遵守していること。これは、職場、学校、図書館などのコンテキストではかなり妥当な仮定であり、テスト可能であるため、誰かがルールに違反した場合でも、簡単にルールを破り、ブラウザーベンダーに法的措置を開始させることができます。

コメントと回答で指摘されているように、ブラウザーのトラストストアにCAを追加する正当な理由はたくさんあります。これを行うメカニズムには、マシン/ブラウザーへの管理者アクセスが必要です。

管理者(または過去)が信頼できるとは考えず、公に信頼されている(つまり、Mozillaの公に信頼されているCAによって発行されたCAによって発行された)証明書をブラウザに視覚的に区別させたい信頼モデルを示唆しているリスト)およびブラウザーのトラストストアに明示的に追加されたため、プライベートに信頼されているもの。多分私的に信頼されているための警告記号の付いた通常のグリーン?

良いアイデア!また、Firefoxの2つのコピーをインストールする必要があるという私の問題も解決します。1つは証明書のインストールが必要な製品のテスト用、もう1つはインターネットの閲覧用です。 Firefoxでこの機能がすでに拡張されているかどうかを確認し、拡張されていない場合は提案してください。

52
Mike Ounsworth

必要なのは、ローカル管理者が実行する「攻撃」からユーザーをブラウザに防御させることです。

このようなシナリオでは、防御は不可能です。 「悪意のある」管理者は、自分のCAを使用してコンパイルした詐欺師の代わりに、合法的なFirefoxをいつでも使用できます。緑色の南京錠が表示されます。あなたが仕事中に誰かのマシン(この場合は会社のもの)を使用しているとき、あなたはマシンの所有者のなすがままに100%です。会社が秘密裏にあなたをスヌープしたいと思った場合、彼らはいつでもキーロガーをインストールし、安全なブラウザに到達する前にパスワードを見ることができます。

緑色のボックスは、ローカルの脅威に対する安全性を示しているのではなく、リモートスヌーピングからの安全性を示しています。この場合は、TSLインスペクターへの安全な接続を示しています。同じLAN内の同僚がパスワードをスヌープできないことを示しているため、緑色のアイコンが表示されます。インスペクターがネットワーク管理者の責任を負うと、ブラウザーは実際にHTTPを使用しているかどうかを判断できなくなります。

ユーザーができることは、証明書を表示して、証明書のパスを調べることです。 DigiNotar によって発行された証明書がEvilCorpによって発行された証明書よりも「優れている」かどうかをブラウザが判断できません(これは、あなたの雇用主である)。証明書は常に変更され、CAも変更されます。ブラウザは、1つのCAが他のCAよりも信頼できるかどうかを判断できません。発行者が誰であるか、およびそれらを信頼できるかどうか、およびどのような種類の情報を使用して決定できるのは、あなただけです。あなたは仕事関連の活動にのみマシンを使用することになっているので、技術的にはEvilCorpに見られたくないようなことは何もしていません。

30
Agent_L
  1. 公式リストは時間とともに変化するからです。
  2. 企業には「内部」CAを含める正当な必要性があるためです。
  3. 企業は、セキュリティ、コンプライアンス、またはHRの目的で中間者ができることに正当な関心を持っているためです。
  4. 開発者とテスターに​​は中間者の正当なニーズがあるからです。

StartCom を今日信頼しますか?これは、重要な変更を加えた場合に得られることです。

9
gowenfawr

カスタムルートCAを許可する主な理由の1つは、Web開発者のためです。開発とテストビルドでは、社内証明書を使用することが非常によくあります(主にコストと作成の容易さのため)。ルートCAの追加を許可しないと、dev/buildインスタンスと本番インスタンスの間で(より)異なる状態が発生し、バグの修正が困難になる可能性があります。

また、会社のプロキシは、会社が(ほとんどの法律では)インターネットで何をするかについて責任を負っているので、倫理的に疑わしいが主に合法であり、期待されている中間者をしばしば使用します。

ルートCAをハードコーディングしないもう1つの理由は、ブラウザーの考慮事項とは無関係に、信頼できないものを削除できるようにすることです(おそらく、信頼できない政府の管理下にあるか、最近キーが漏洩した可能性があります)。それら。

6
Sefa

通常、新しいルート証明書を追加するには、管理者またはルートレベルのアクセス権が必要です。そのため、コンピューターの所有者の同意なしにインストールすることはできません(エクスプロイトが使用されない限り)。

問題は、コンピュータの所有者を誤解していることです。コンピューターが雇用主によって発行され、ルートアクセス権がある場合、それは「あなたの」コンピューターではありません。それは彼らのものであり、彼らはあなたにそれを使用させています。そのシステムを使用してプライバシーを期待する必要はありません。それはおそらくあなたの従業員の合意にその影響を与える何かを言いました。 (これの詳細は、地域の法律によって異なる場合があります。)

1
myron-semack

コンピューターが企業ネットワークの一部である場合、HTTPSを使用する内部Webサイト、またはクライアントにプッシュするさまざまな更新パッケージまたは内部アプリ用のカスタムルートCAを追加することは理にかなっています/ =。

0
Godonsplork