OCSP、CRL、crlset-失効配信と攻撃
OCSP応答には「nextUpdate」フィールドがあり、これは新しい失効更新の予想時間であり、現在の失効は有効と見なすことができます。失効は中間証明書サーバーによってキャッシュすることができます。これは、ホチキス止めされた応答を提供する設計で使用されているのを見てきました。失効はすぐにルートCAから中間CAに配信されることを読みました。
この場合、ルートCAサーバーにDoS攻撃があったために失効を配信できない場合はどうなりますか？これは、中間サーバーのキャッシュされた失効エントリを使用して、Webサイトの証明書が無効である可能性がある場合に、Webサイトの証明書が有効であることを誤ってエンドユーザーのクライアントに通知する可能性のある機会を提供します。ユーザーのクライアントまたはブラウザは、DoSが停止されるまで、悪意のあるサイトとやり取りする可能性があり、すべての中間サーバーなどに最大7日間電話がかけられます。
ルートネームサーバーへのDoS攻撃は少なくとも3回発生しましたが、1時間以上持続しますが、CAサーバーが送信トラフィックを送信する機能にどのように影響するかはわかりません。おそらく、失効リストを公開するためのサイドチャネルがあるでしょう。
これの技術的な側面と、このタイプの攻撃が発生する可能性について、誰か他に情報がありますか？また、CRLのキャッシュインフラストラクチャと、一般的な中間CAで失効が発生することを期待するタイミングを知っている人がいるかどうか知りたいのですが。
ChromeはCRLをクロールする独自の適切な方法を使用し、Googleはそれらをcrlsetと呼ばれるチャンクでブラウザーにプッシュします。一見すると、OCSPはcrlsetと比較してタイミングの利点が優れています。これは、承認されたレスポンダーに直接連絡して失効ステータスを取得するためです。ただし、一部のプロバイダーが可変的に定義されたCRLキャッシュ更新期間を実装していることを確認した後、実際にそれが優れているかどうかはわかりません。 Googleによると、失効リストは毎日更新され、これは他のソリューションよりも頻繁に行われます。
OCSPとGoogleのcrlsetメソッド間のセキュリティのトレードオフを知っている人はいますか？具体的には、失効応答を取得するタイミングと信頼性のどちらが優れていますか？ Googleの主張は証拠によって裏付けられていますか？
私は昨日CRLとOCSPについて質問し、それについて読んだところ、現時点では「完全な」解決策はないという結論に達しました。
完璧なシステムでは、ブラウザは少なくとも毎回セッションごとにCA自体で失効ステータスを確認しますが、そのためには、すべてのCAが機能するために、世界中に広がる冗長接続を備えた巨大なサーバークラスタを作成して、応答時間を最小限に抑える必要があります。
それは実際には実現可能ではないので（すべてのCAがそのような大きなインフラストラクチャを作成することを期待することはできません）、OCSPステープリングは、あなたが述べたマイナス面を最初に作成されました。
Googleのcrlsetは基本的にはその中間にあり、CRLキャッシュとして機能します。有利な点は、GoogleにはDoS攻撃を受けにくい巨大なサーバーインフラストラクチャがあるため、理論的にはこれは良いことです。欠点は、プライバシーの問題やそれに伴うその他の問題について、Googleに依存していることです。
私の意見では、証明書には、「すべてのリクエストで必須の失効チェック」ブールフィールドが含まれている必要があります。これにより、クライアントはすべてのリクエストで失効ステータスを更新する必要があります。そのため、基本的に重要なインフラストラクチャや銀行サイトなどの高セキュリティアプリケーションは、すべてのセッションの開始時に常に最新の失効ステータスを適用し、重要度の低いサイトは（より高い）セキュリティではなく、使いやすさを選択します。また、サーバーによって強制されない限り（Cookieオプションなどと同様に）、ユーザーはすべてのサイトに対して個別にこれを設定するオプションを持つ必要があります（したがって、サーバーが強制するときに非アクティブにすることはできません）。
これは技術的なことよりも政治的なことであり、このようなものを導入するには規制が必要です。
しかし、繰り返しになりますが、このシナリオの攻撃方法は、考えれば実際にはかなりスリムです。基本的に、最初にサーバーを攻撃して証明書を破壊する必要があります（これは、高度なセキュリティアプリケーションでは非常にありそうもないことです）。同時に、ルートCAを巨大な攻撃でDoSするため、何も到達せず、その小さなウィンドウを使用して攻撃を実行します。非常に、非常にまれであり、nextUpdate期間がさらに短い場合（それは高セキュリティ環境である必要があります）、さらに軽減することができます。
したがって、「サーバーの整合性の責任者は誰か」の問題でもあります。誰かがあなたのサーバーの秘密鍵を手にしたとき、あなたの証明書の失効ステータスはあなたが持っている最大の問題ではありませんが、誰かがあなたのサーバーへのルートアクセス権を持っている（あるいはさらに悪いことにルートアクセス権なしであなたのキーを取得する）からです。