最近 DigiNotar CAがハッキングされました 、そして不正な証明書が発行されました。オランダ政府に代わって証明書も発行するため、政府はそれについても声明を出し、基本的には「ブラウザからセキュリティ警告が表示された場合はWebサイトにアクセスしないでください」と主張しました。それ自体は良いアドバイスであり、「警告を無視すると99.9%安全である」と主張するDigiNotar自体よりも優れていますが、まだ更新されていないCAトラストストアを持つブラウザーは無視されます。
更新されていないブラウザー(トラストストア)を想定すると、任意のWebサイトへの中間者攻撃に対して脆弱ではなく、有効なものだけではありませんDigiNotar証明書? Webサイトで証明書チェーンを確認できることは知っていますが、私は確認できません。また、両親が確認することはありません。
SSL信頼は本当に最も弱いCAと同じくらい強いだけですか?それを修正する方法はありますか?
Update 2011-09-06: Fox-ITによるDigiNotarハックに関する独立した報告 が公開されました
脆弱性の深さに依存する具体的なケースについて:
攻撃者がSSLサーバー証明書に署名するプログラム(Webフロントエンド)にのみアクセスできた場合、影響を受けるのはそれらのサイトのみです。適切なロギングメカニズムがあれば、影響を受けるすべてのドメインの完全なリストを作成できます。
CAビットが設定された証明書の作成を許可された秘密キーまたはプログラムにアクセスできる場合、攻撃者は任意のサイトの証明書を作成できます。
一般的なケースの場合:はい、現在の形式のCAモデルは、最も弱いCAの信頼に依存しています。
過去にそれぞれの政府に対して偽の証明書を発行したことが知られている(アラブ首長国連邦でのBlackBerry Interceptionの更新で最も注目されている)、または合法的傍受の広告資料が漏洩したことがわかっている一般的なブラウザーのデフォルトリストには、多数のCAがあります。 (アメリカ合衆国で最も注目に値する)。
私の知る限り、ブラウザリストから完全なCAが削除されたのはDigiNotarだけです。他のケースでは、偽のサーバーまたはソフトウェア証明書のみが取り消されています。
Jeff Ferlandがセキュリティブログに優れた記事を投稿しました、認証局の問題を修正するためのリスクベースの見解。
収束 インターネットのさまざまな角度からサーバー証明書を記録することにより、問題を軽減しようとします。これは、他の公証人が実際の証明書を見ることができるように、攻撃者が被害者に比較的近いと想定しています。
CAを使用してサーバー証明書に署名する代わりに、 [〜#〜] dnssec [〜#〜] が広く適合していると仮定して、証明書をDNSに含めることができますが、まだそうではありません。
Googleは、有効なハッシュをChromeブラウザーがそれを呼び出す 公開キーの固定 のソースコードにハードコーディングします。このアプローチはスケーリングされず、限られた数しか配置できません。そこに交通量の多いサイト。
はい、SSL Webブラウジングは、最も弱いCAとまったく同じくらい強力です。 DigiNotarは世界中のあらゆる証明書に署名できるため、理論的には、SSL会話はすべてMITM化できます。
さらに、世界中のどのサイトにも署名できる約1500の証明書があるため、問題が発生する可能性のある場所がたくさんあります。
2か月前は、DigiNotarがWebサイトの証明書の一番上にあり、その正当性を疑う理由がありませんでした。その上、証明書について何かが検証されない場合、ブラウザはすでに大きな悪い恐ろしいページを表示します。悲しいかな、自分で信頼の連鎖をチェックするためにこれ以上できることはありません。
明確にするために、DigiNotarの「99.9%」のアドバイスは ひどい エンドユーザーにとって、そして疑いを持たない一般の人々にそのようなひどい勧告をしたことに対する彼らへの厳しい反響が引き続きあることを願っています。
平均的なユーザーのリスクはMITM攻撃に関連し、2つの(ソーシャル)カテゴリに分類されます。誰かがセッションに侵入し、電子メール、銀行の詳細などを乗っ取り、それを使用してIDを盗んだり、困惑させたり、 新聞記事を書く 。もう1つの社会的カテゴリーは、政府がそれを行うときです。同じ技術的効果ですが、より強力であなたを逮捕する能力があります。
Convergence.io は、いくつかの異なるサイトから見られるように、さまざまな要因に信頼を置くことによってそれを修正することを目的としています
DNSSECは、特定のドメインに対して可能なチェーンを1つだけ提供することでこれを修正することを目的としています。
この問題の詳細については、「 認証局の問題を修正するためのリスクベースの見方 」を参照してください。