証明書の透明性
私が読んだもの here から、中間CAが侵害された場合、偽の証明書が発行され、エンドユーザーのプライバシーも侵害される可能性があります。この状況を修正するには、誰かがこれを報告し、中間証明書を発行するCAによってこの証明書が取り消されるようにする必要があります。
記事の最後に、CT（Certificate Transparency）を提案しました。 CTの「監査人」が常に「モニター」と「ログサーバー」に照会して、証明書の有効性を確認することを理解しています。一方、「monitor」はログサーバーにもクエリを送信します。ただし、はっきりしないのは、証明書またはCAが侵害されたと誰も報告しなかった場合、CTはどのように役立つのでしょうか。
また、CAと証明書の検証が他人に依存している場合、CTをP2P CRL/OCSPの一種と考えることができますか？
私はコメントできないので、明らかに、いくつかの点を明確にしたいと思います。
CTはすべてのブラウザーで使用する必要はありません。たとえ1つのブラウザーでしか実行されない場合でも、群れの免疫が付与されます。そして、ところで、Chromeの次のリリースにはCTサポートが含まれています。
CTをサポートするためにWebサーバーを変更する必要はありません。CAは、発行された証明書にSCTを含めることができます。一部のCAは既にこれを行っており、他のCAはそれに取り組んでいます。
CTは新しい信頼されたエンティティを導入しません-CTログはそれら自身の正しい操作を証明し、逸脱はそれらの不正行為の署名された証拠を残します。
CTの目的は、関係者（ドメイン所有者、研究者など）がパブリックPKIを完全に可視化できるようにすることです。これにより、証明書の発行ミスを迅速に発見しやすくなります。たとえば、CTが配備されていれば、DigiNotarは数か月ではなく数時間で発見されたでしょう。
Certificate Transparency はヒューリスティックな防御メカニズムであり、not誤って発行された証明書を検出します。代わりに、それはallow誤って発行された証明書のより高速な検出を目指しています。
核となるアイデアは Glasnost のアイデアです。偶然にも、成功する攻撃のほとんどは情報の非対称性に依存しています。 Googleのサーバーを偽装したいとします。詐欺、贈収賄、無能、および/または運により、「www.google.com」が書かれた偽の証明書を取得します。次に、ターゲットの被害者（たとえば、sysadmin機能を持っている会社のすべての従業員）にonlyと応答する偽のサーバーにそれを使用します。攻撃者としての私の興味は、外部に誰もいないことですnoticesその偽の証明書、特にGoogle自体の存在。 Googleのユーザーは、自分の名前が付いているが自分の名前ではないこの証明書に気付いた場合、すぐに発行元のCAに連絡して、すぐに失効を要求します。厳しい言葉が予想されます。
証明書の透明性は、証明書の公開ログです。これは、SSL/TLSクライアント（Webブラウザ）mayが証明書を受け入れるように構成されているシステムですonly検証可能な証明（「署名された証明書タイムスタンプ」）は、証明書がすべての人、特に証明書の所有者と言われる人（上記の例ではGoogle）に表示されるログに追加されたことを示します。これは検出を保証するものではありません。実際、証明書は技術的に完全に有効です。 CTが保証するのは、クライアントが見るどの証明書もプレーンビューにあり、したがって想定されるが不正である場合、すぐに検出されることです。
（CTログには、信頼できるエンティティによって署名されたタイムスタンプが含まれていることに注意してください。通常どおり、信頼はありません作成されただけ移動されたです。）
CTの弱点は、全員が参加する場合にのみ機能することです。 CTは、SSL/TLS clients（つまりWebブラウザー）がSCTに付属していないサーバー証明書を正当に拒否する場合にのみ、実際のセキュリティを向上させます。これは、次のすべてが当てはまる場合にのみ機能します。
- すべてのCAが参加するので、すべての「通常の」証明書がいずれかの時点でCTログにあることが期待できます。
- すべてのWebブラウザーがCTをサポートし、ログにない証明書を拒否します。
- すべてのWebサーバーはCTをサポートし、指定されたSSL/TLS拡張を使用して署名済み証明書のタイムスタンプオブジェクトをブラウザーに送信します。
このシステムが実際にそのbootstrap=フェーズを10％未満で完了する可能性があります。
PKIには2つの要素があります。技術的なプロトコルと、それらを中心に構築する手順です。
技術的な領域では、非常に明確です。信頼できるシステムを決定するためのメカニズムがあり、どのような条件下で、どのような方法でその信頼システム（CRL、OCSPなど）の（ほとんどの）変更を伝達するかを決定します。
ただし、これらの技術要素は手順をカバーしていません。どうやって知っているなどのルートを信頼できるか？ユーザーとして、通常、ルートCAリストを作成および管理する会社（Microsoft、Mozilla、Google、Appleなど）を（暗黙的に）信頼しているため。アクターとして、これらのルートが検証された方法を確認するか、自分で検証するため（たとえば、プライベートルートを使用している場合は、ルートの管理方法について適切な調査を行うことが重要です）。
では、（中間またはルート）CAが侵害されたことをどのようにして知るのでしょうか。これは、そのCAの不適切な使用（たとえば、キーに署名する権限のない証明書によって署名されたリーフ証明書を見つける）を見つけたことが原因である可能性がありますが、それはおそらく何らかの手順の要素が原因である可能性があります。監査の結果、当該証明書の不適切な使用に気づいた。
あなたがリンクした特定のケースでは、問題は本当にその性質のものでした：ANSSIは、本来実行するはずのないことを行いました（あるエンティティの名前で証明書を別の無関係なエンティティに発行します）。そのため、証明書は取り消されましたGoogleおよびMozillaによる。
これは、パブリックPKIシステム全体の問題を浮き彫りにします。理解するのが簡単ではなく、従うのが簡単ではない、あまりに多くのルールに従う必要のあるアクタが多すぎます。そして、システム全体のセキュリティが崩壊するのに失敗するのは、俳優の1人だけです。すべてが非常に壊れやすいのです。