CAがハッキングされる可能性はどのくらいありますか？どのデフォルトの信頼されたルート証明書を削除する必要がありますか？
この質問は、元のバージョンから大幅に改訂および明確化されました。
信頼されたルートストア内の信頼された証明書をそれぞれ確認する場合、どれだけ信頼する必要がありますか？
ローカルストアから削除される可能性がある各ルートCAの信頼性を評価する場合、どの要素を考慮する必要がありますか？
詳細：
CAが不適切に検証されたパーティに証明書を発行すると、そのCAを信頼するすべてのマシンがMITM攻撃に対して脆弱になります。その結果、すべてのCAは、特定のSSL証明書要求の要求者を厳格に検証して、CSチェーンの整合性を保証します。
ただし、このCA検証プロセスの大部分は人間の介入の影響を受け、証明書を間違った当事者に発行する機会を提供します。これは、CAオペレーターのエラー、政府の要求、またはCAオペレーターの強制（賄賂）によって行われる可能性があります。
間違った相手に証明書を発行する可能性が高いデフォルトのCAについて詳しく知りたい。この情報を使用して、Trusted Cert StoreからそのCAを削除するようユーザーにアドバイスします
例：
特定のCAを管理している政府がMicrosoft.comのIDを引き継ぐことを望んでおり、CAの検証プロセスに例外を要求するとします。その政府はまた、この例外の秘密を維持することを要求します。生成されたキーペアは、MITM攻撃で使用されます。
Windows Azureのデフォルトの信頼
Windows Azureは 次のリンク に示すように275のCAをサポートします。特定のCAの使用に応じて、それらのCAの一部は、特定の攻撃の表面積を増やす可能性があります。実際、これは一部のアプリケーションを正しく機能させるために技術的に必要になる場合があります。
Amazonデフォルトの信頼
（利用不可）Amazon、Google、およびVMWareのデフォルトCAリストへのリンクを見つけた場合は、それらを共有してください。
Mozilla
すべての証明書と監査ステートメントのリスト が利用可能です。
Apple iOS
すべてのリスト iPhoneルート証明書this＃WWDC2017。ビデオ
Update 5CAモデルの根本的な問題（heh）は、一般に、どのCAも任意のドメインの証明書を発行できるため、脆弱です最も弱いリンクへ。信頼できる人については、リスクが高く、セキュリティが難しいため、リストが非常に長いとは思えません。この件に関するクリストファーソゴイアンの投稿をお勧めします。これは、世界中の政府がプライベートユーザーデータへのアクセスを取得するために使用しているさまざまなアプローチを明らかにしています。またはハック： わずかなパラノイア：DigiNotarハックにつながった力 。
ここでいくつかの詳細を提供し、いくつかの潜在的な修正へのリンクで終わります。
2009年に、Etisalat（アラブ首長国連邦政府が60％所有）は、RIMデバイスにスパイウェアを挿入する無害に見えるBlackBerryパッチを展開し、電子メールの監視を可能にしたため、信頼できるとは言えません。しかし、それは多くの信頼できるCAリストにあります： http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars
更新1コモドに対する ComodoHacker というイラン人による攻撃の成功例も参照してください： 不正なSSL証明書（「ケースコモドゲート」）-F-Secure Weblog 。 F-Secureは、Mozillaには中国、イスラエル、バミューダ、南アフリカ、エストニア、ルーマニア、スロバキア、スペイン、ノルウェー、コロンビア、フランス、台湾、英国、オランダ、トルコ、米国、香港、日本で発行された証明書が含まれていると述べています、ハンガリー、ドイツ、スイス。
チュニジアは広く信頼されているCAを運営しているもう1つの国であり、プライバシーを侵害する政府の行動に関する優れた文書もあります。 Facebookがチュニジアのハックにどのように対応したかについての裏話-アレクシスマドリガル-テクノロジー-大西洋
Mozillaは、注意が必要な別の疑わしい慣行に注意します。RAパートナーが中間経由ではなくルートから直接証明書を発行できるようにするCA： Comodo証明書の問題– Mozillaセキュリティブログのフォローアップ 。
イランの孤独なハッカーによる責任の主張についての憶測を含む詳細もご覧ください Webブラウザとコモドが成功した認証局攻撃を公開、おそらくイランから|自由からティンカーへ
更新3：ComodoHackerによると思われるもう1つの成功した攻撃は DigiNotar CAに対するものでした。彼らのウェブサイトは2009年に侵害されましたが、これはDigiNotarが2011年にイラン人によってGoogle、Yahoo！、Mozilla、WordPressおよびTorプロジェクト。DigiNotarは、1か月以上サイトへの侵入の知識を明らかにしていませんでした。詳細は DigiNotar HackがSSL Webセキュリティモデルの重大な障害を強調| Tinker to Freeker を参照してください。
さまざまなCAの脆弱性の範囲は、その実用性と同様、かなり大きく異なると思います。したがって、私はあなたの戦略に再び焦点を当てることをお勧めします。保護しようとしている特定のアセットに絞り込むことができる場合は、それらのアセットの使用に必要なCAを除いて、すべてのCAを削除してください。それ以外の場合は、攻撃対象領域を減らすためだけに、資産を気にかける人々に対して最も脆弱である、または最も人気のないCAを排除することを検討してください。ただし、最も人気のある慎重なCAに対しても、高度な攻撃に対して脆弱なままであることを受け入れてください。
更新2：Freedom to Tinkerの危険なCAインフラストラクチャの修正に関する素晴らしい投稿があります： Building a better CA Infrastructure
それはこれらの革新について話します：
更新42011年8月のITセキュリティブログの投稿の1つでも、DNSSECへの移行のケースが取り上げられています。 リスクに基づく修正の確認認証局の問題"Stack Exchange Security Blog
Update 6いくつかの認証局がルールに違反していることが判明しました。これには、フランスのサイバー防衛機関（ANSSI）とTrustwaveが含まれます。これらはそれぞれ デジタル証明書のスプーフィングにリンクされています です。
更新72014年のインドの認証局の管理者（インドCCA）を介した「誤って発行された証明書」の別のセット： Google Online Securityブログ：デジタル証明書のセキュリティの維持
Certificate Transparency の質問も参照してください。これは、不正な証明書やポリシー違反を早期に発見するのに役立つアプローチのようです。
Matt Blazeがかつて書いたように、CAは、お金を受け取りたくない人からあなたを守ります。これは、CAのインセンティブがどこにあるか、および取り決めにおけるいくつかの潜在的なリスクについて何かを伝えているはずです。
この質問への短い答えは、私の知る限り、知ることは不可能だと思います。ほとんどの一般的なブラウザには多数のデフォルトCAがインストールされており、政府やその他の組織に証明書を配布することに関して、それらが「信頼できる」可能性を評価することは困難です。
CAが信頼できないものとして知られるようになった場合、ブラウザーのデフォルトのインストールリストから削除される可能性があります（以下の@xceに従って、DiginotarはここでもDigicertの良い例です）。
組織が自発的に証明書を提供することに加えて、要求者に対して適切なセキュリティチェックを行わずに証明書を提供する可能性があります。数年前のDefconでは、許可なしに証明書を取得できるというこのテーマに関するプレゼンテーションがいくつかありました。
これが重大な懸念事項である場合、私が検討できる唯一の方法は、確認し、提供されたセキュリティに慣れているCAのホワイトリストを作成することです。明らかに、これは一般的なインターネットへのアクセスには機能しません。これは、使用したいサイトへの証明書を発行しているCAを削除してしまう可能性があるためです。
知っておくべきことの中心にある2つの例ですが、明示的に求めているものではありません。
- 数年前（2006年、または2005年の終わり）に、SSLフィッシングのかなりよく知られた事件がありました-偽の銀行のWebサイトは、地域の銀行のサイトのスペルミスのために（GeoTrustから）正当なSSL証明書を受け取りました。 （更新：見つかりました この歴史的なリンク -アドレスは、短縮された頭字語ではなく銀行のフルネームでした）。それ以来、SSLフィッシングの他のケースがありました...ポイントは、「強制」に頼らずに証明書を取得することが可能であるということです。
- 最近の Stuxnet 小説は、他の戦術の中でも、盗まれた証明書に依存していました。これらはサードパーティのドライバメーカーから「借用」されたものであり、「信頼されている」ため、マルウェアを植えるために悪用される可能性があります。
もちろん、CAが呼び出されないソフトウェアシナリオもあります。 Webサービスを呼び出すシッククライアントでは、サーバーの証明書を検証する必要はありません。
私の要点は、SSLを介したMITMについて心配している場合は、たいていの場合、心配するのは政府の強制ではないということです。通常、より簡単でアクセスしやすい方法があります。
私は、「信頼できる証明書」が「信頼できる」と呼ばれることにさえ反対しています...あなたが誰であるかを知っているからといって、私があなたを信頼する必要があるわけではありません... elseです。
言うまでもなく、信頼されたストアから標準のルート証明書を削除すると、インターネット上の多くのサイトが期待どおりに動作しなくなります。
一方、を実行しないサーバー/アプライアンスを処理している場合は、一般的なブラウジング機能は必要ですが、特定のサーバー（またはサーバーのセット）、必ず削除[〜＃〜] all [〜＃〜]ルート証明書（必要なもののホワイトリストを除く）。
さらに、独自の内部CAを使用する場合は、さらに良い...
すべてのCAは、自身のキーを保護する方法を説明する証明書実践ステートメントを発行し、証明書を発行する前に証明書の要求を検証します。このドキュメントの場所へのURLは通常、CAによって発行された各証明書に埋め込まれています。問題のCAが実際にこのポリシードキュメントに従っていると仮定すると、証明書を要求しているエンティティの有効性を確認するために必要な長さを示す必要があります。ハードウェアセキュリティモジュールまたは暗号化モジュールを使用してCA署名キーを保護し、署名キー、多要素認証、および証明書に署名するためのクォーラムベースの承認などを使用してそれらのCA署名キーを保護するというステートメントを探します。これらの保護方法により、はるかに困難で高価になります。不正な第三者が署名キーを盗むため。
信頼できるCAの膨大なリスト（私のMacシステムルートキーチェーンには175があります）があり、HTTPSシステムをあなたやこの質問をしていない地球上のすべての人が使用できるようにしています。もちろん、個人的にその実務を監査していない限り、このリストからすべてのCAを除外できます。すべてのエンドポイントを制御し、信頼できる関係者の数が限られているクローズドシステムの場合、これは可能です。 Subversionバージョン管理システムには、信頼されたルート証明書は含まれていませんが、すべてのクライアントに独自の証明書を追加できます。ウェブ全体について、それを使用可能にするために私たちが見つけた唯一の方法は、アウトオブバンドの信頼できる当事者（オペレーティングシステムまたはブラウザーを提供する会社）が信頼できるもののリストを提供することです世界中のほとんどすべてのSSL対応サーバーに接続できる証明書。
信頼できるリストにこれらの証明書がすべて本当に必要ですか？おそらく違います。ただし、OS /ブラウザベンダーは、ビジネスを行う相手を予測することはできません（制御することもできません）。リストが大きい場合の問題は、すべての法域のすべての種類の検証方法で、まったく同じように扱われる、すべての羽のCAがあることです。すべてのCAが同じように機能するわけではありません。リセラーのログイン認証情報が侵害されたり、CAキーが侵害されたりする場合もありました。一部のCAは、定款の証明書と最初の出産の約束を必要とします。その他のCAは、証明書を要求しているドメインで電子メールを受信できることを確認するだけです。それでも、各CAはブラウザによってまったく同じように扱われます。
同じ共通名の不正な証明書に対する防御策は、元の証明書をクライアントにキャッシュすることです。別のCAからの別の証明書が突然表示された場合、これは問題の原因になるはずです。今日のブラウザーがこのケースをどのように処理するのかわかりません。
この種の議論は常に このMozillaのバグ を思い出させ、新しいCAの包含を要求します。かなり陽気ですが、かなり洞察力があります。
Windows PCで削除する証明書を調べるときは、まず、システムが必要とする証明書を削除しないようにしてください。そうしようとすると、次のエラーメッセージが表示されます
これは、Windowsシステムから削除してはならない証明書のリストを含むURLです http://support.Microsoft.com/?id=293781
次に、中間証明書の削除（削除のテスト）を検討する必要があります。これは、「 純粋にレガシーの理由から 」しか存在しないためです。
残りのすべての証明書の削除を評価するときは、 Microsoft Root Certificate Program がCAにこれらの監査基準のいずれかを渡す必要があることを考慮してください。
- ETSI 102 042
- ETSI 101 456
- CA向けWebTrust
- WebTrust EV準備監査
- ISO 21188（ISO 27001を受け入れないことに注意してください）
MSFT以外のブラウザ（IE）から証明書を削除する場合は、 これらのCA品質ガイドラインを確認する を使用することをお勧めします。
制限
プログラムには、キー使用法の内容に適用される追加の監査もあります。キーの使用は以下に制限されています。
サーバー認証（SSL）= 1.3.6.1.5.5.7.3.1
クライアント認証（SSL）= 1.3.6.1.5.5.7.3.2
安全な電子メール（SMIME）EKU = 1.3.6.1.5.5.7.3.4
コード署名EKU = 1.3.6.1.5.5.7.3.3
タイムスタンプEKU = 1.3.6.1.5.5.7.3.8
OCSP EKU = 1.3.6.1.5.5.7.3.9
暗号化ファイルシステムEKU = 1.3.6.1.4.1.311.10.3.4
IPSec（トンネル、ユーザー）EKU = 1.3.6.1.5.5.7.3.6、1.3.6.1.5.5.7.3.7
禁止されたキーの使用法
次の主要な使用法はプログラムによって禁止されています。
スマートカードログオンこれはエンタープライズのみのシナリオです。ActiveDirectoryの展開が必要であり、ルートをActive DirectoryのNTAuthストアに追加する必要があるためです。詳細については、次のKB記事を参照してください。 http://support.Microsoft.com/default.aspx?scid=kb;en-us;Q281245
デジタル著作権このEKUは廃止されました。 Windows Media DRMは、ライセンスに独自のXML形式を使用し、X.509を使用しません。
限定従属このEKUは廃止され、Windowsでは無視されます。
キー回復エンタープライズCAシナリオ。
ファイルの回復このEKUは廃止され、Windows暗号化ファイルシステム（EFS）では無視されます。
すべてのアプリケーションポリシー「すべての使用」を許可することはできません。これは、企業のみおよびその他の許容できないEKUを必ず許可するためです。
ディレクトリサービスの電子メールレプリケーションエンタープライズシナリオ
証明書要求エージェント
エンタープライズCAシナリオ
キー回復エージェントのエンタープライズCAシナリオ
CA暗号化証明書
エンタープライズCAシナリオ
合格基準
さらに、汎用または政府機関のCAをルートに追加する前に、次の基準を満たす必要があります。
CAは以下に要求される情報を提供し（ ステップ1. Microsoftに連絡する を参照）、プログラムのメンバーシップの事前承認を受ける必要があります。
CAは、テスト目的でCAのルート証明書から発行されたテスト証明書を提供する必要があります。必要に応じて、CAは、ルート証明書から発行された証明書を検証できる公的にアクセス可能なサーバーのURLをMicrosoftに提供できます。 （詳細はFAQを参照））
CAはMicrosoft CA契約を完了する必要があります。契約は、申請プロセスのステップ1を完了し、申請の事前承認を得た後にのみ提供されます。
ルート証明書は、以下の技術要件セクションに準拠している必要があります。特に、ルートとすべての発行元CAには、RSA 2048ビット係数の最小暗号鍵サイズが必要です。マイクロソフトは、RSA 1024ビットモジュラスの有効期限を持つルート証明書を受け入れなくなります。新しいルートは提出日から少なくとも8年間は有効ですが、特に2048ビットのRSA係数がある場合は、2030年より前に有効期限が切れることをお勧めします。
ルート証明書から発行された証明書は、CRL配布ポイント拡張をサポートする必要があります。 CRL配布ポイントは、一般にアクセス可能な場所を指す必要があります。
CAには失効ポリシーが文書化されている必要があり、CAは発行した証明書を取り消すことができる必要があります。
CAは監査を完了し、12か月ごとに監査結果をマイクロソフトに提出する必要があります。監査は、拡張キー使用法（EKU）の割り当てを通じてマイクロソフトが有効にするPKI階層全体をカバーする必要があります。私たちが有効にするすべての証明書の使用は、定期的に監査する必要があります。監査レポートは、監査の対象となる特定の種類の証明書を発行するサブCAを含む、PKI階層の全範囲を文書化する必要があります。適格な監査には以下が含まれます。
WebTrust for Certificate Authorities v1.0以降 、ライセンスされたWebTrust for CA監査人によって完了、
ISO 21188：2006 、「金融サービスのパブリックキーインフラストラクチャ-プラクティスとポリシーフレームワーク」、CA監査人のライセンスを取得したWebTrust、または評価者の法律とポリシーに従って動作する監査機関のいずれかによって完成CAと同じ管轄区域内。
これらは、現時点で非政府機関のCAに受け入れられている監査です。上記の監査を変更したり、将来的に他の同等の監査を受け入れる権利を留保します。
技術要件
新しいルート証明書は、次の技術要件を満たしている必要があります。
ルート証明書はx.509 v3証明書である必要があります。
サブジェクト名には、意味のあるCAの名前を含める必要があります（例：「ルート」または「CA1」は使用できません）
基本的な制約の拡張：cA = true
キーの使用（存在する場合）：keyCertSignおよびcRLSignのみ
ルートキーサイズの要件は NIST SP 800-57： に基づいています
RSA greater or equal to 2048-bit modulus ECC greater or equal to P256 modulusハッシュアルゴリズムは少なくともSHA1でなければなりません。 MD2、MD4、またはMD5ハッシュは受け入れられません。
ルートキーのサイズがRSA 2048ビットモジュラス以上の場合、ルート証明書は提出から少なくとも8年後、2030年までに期限切れにならないようにする必要があります。ルートキーのサイズが大きいほど、有効期限が長くなる場合があります。
中間CA証明書はルートCAプログラムから除外されます（詳細については、よくある質問を参照してください）
CAは、2009年1月15日から、プログラムによって配布されたルート証明書からMD2、MD4またはMD5の下位証明書またはエンドエンティティ証明書を発行しません。
マイクロソフトが提供する場合を除き、2010年12月31日のNIST期限まで、既存の（「レガシー」）1024ビットRSAルート証明書はプログラムによって配布されたままになる場合があります。
CAは、2010年12月31日のNIST期限までに、プログラムによって配布されたルート証明書から1024ビットのRSA証明書を発行する場合があります。
私は、米国政府が数年前に法律を可決し、CAに第三者に有効な第三者の盗聴などの有効な証明書を生成するよう強制する権利を与えようとしたと思います。私はこれの証拠を見つけることができなかったので、ロリーが述べたDefConの話し合いに沿って何かを覚えているかもしれません。
悪い政府がマシンのSSLトラフィックを見たいと思ったとします。デフォルトのCAが新しい証明書の発行を強制されることはどの程度実行可能ですか？
述語と質問は無関係です。 CAが新しい証明書を発行するよう強制することがどれほど簡単であるか、頻繁であるかは問題ではありません。盗聴者は、既にインストールされている証明書の秘密キーを持たない限り、データを見ることができません。 IIRC（ただし、これを確認することをお勧めします）CSRには秘密キーが含まれていないため、CAはそれを取得できません。マシンが使用しているキーを変更することはできません。
ただし、不正なCAが偽造された証明書を発行する可能性があり、サイトにMITM攻撃が行われる可能性があります。 MD5形式 およびEtisalatに関する最近の問題は、不可能ではないことを示唆しています。
2番目の質問に集中しようとしています。
"どのデフォルトの信頼されたルート証明書を削除する必要がありますか？"の問題基本的には相手に依存します。
接続するWebサイトのいずれかに署名するすべてのCAを信頼する必要があるだけです。
いつも同じ少数のサイトにアクセスするおばあちゃんタイプのユーザーの場合、おそらく少数のCAで十分ですが、インターネットのヘビーユーザーの場合、リストはそれほど速く成長しません*。
なぜそれほど速くない？直感に反して、一部のCAは頻繁に使用され（失敗が大きすぎるCAを含む）、一部のCAは、ほとんど地理的なもののように、インターネットでほとんど使用されません。
ツール SSLCop from securitybydefault は、不信/必要と思われない国からのブロックに役立つ場合があります（たとえば、ブロブディングナグ政府からのウェブサイトへのアクセスを期待していないため、たまたまそのCAのメインユーザーです）： http://www.security-projects.com/?SSLCop
ただし、あまりに多くのCAを信頼しないと、ユーザーが必要とするWebサイトにトラストアンカーを取得できなくなります（そして、ユーザーはアクセスしますとにかく、セキュリティ警告にもかかわらず）、それは同様に悪いです。
2012年6月12日の時点で、Microsoftは、信頼できないルート証明書および信頼できないとMicrosoftに報告されたその他の証明書を無効にする新しいアップデーターをリリースしました。
この更新プログラムはこちらから入手できますが、この更新プログラムがWindows Updateを通じて既に配布されているのか、それとも帯域外更新なのかは不明です。