HTTPを介したCRLの公開は潜在的な脆弱性ですか？
少なくとも1つの主要なCA（Comodo）がCRLをHTTPSではなくHTTPで公開していることに気付きました。
攻撃者がCRLをダウンロードしようとするHTTP接続をハイジャックする可能性があり、 [〜＃〜] hsts [〜＃〜] がドメインに対するDoS攻撃に実質的に相当するものを最小限に実行します。 （HSTSがアクティブな場合、ブラウザーはユーザーが無効な証明書の警告をバイパスできないようにする必要があります。RFC6797 セクション8.4 および セクション12.1 を参照してください。）
CRLは通常署名されています であり、正常な実装では署名検証に合格しない署名付きCRLを拒否する必要があるようですが、どのWebでもCRLの署名者を特定する方法はありませんブラウザなので、 独自のルート証明書キーで置換CRLに署名する でさえ、比較的リスクの低い操作のようです。そしてもちろん、これはブラウザがCRLが最初に署名されていることを要求することを前提としています。そうでない場合は、署名なしのCRLで置き換えることができます。 （そしてもちろん、実装がdoes署名の検証に失敗した署名されたCRL、または署名されていないCRLを拒否した場合、UAをだますことは簡単になります取り消されたが、まだ有効期限に達していない証明書を使用するようにします。）
これは実際の潜在的な問題ですか？ CRLが実際の問題になるのを防ぐために、CRLに関してUAが通常実行するチェックは何ですか？
署名されていないCRLのようなものはありません。署名フィールドは必須であり、CRLを使用するシステムは署名を検証します。
pure X.509 では、CRLは特定の証明書の失効ステータスに関する情報のソースとして「許容可能」と見なされます[〜＃〜] e [ 〜＃〜]「許可された失効発行者」によって署名されている場合：CRLの署名は、subjectDNが等しい検証済みの証明書に含まれる公開鍵と一致する必要があります[〜＃〜] e [〜＃〜]のissuerDN（[〜＃〜] e [〜＃〜]には、関連するCRL配布ポイント拡張およびが含まれますCRLには一致する発行者配布ポイント拡張がありますが、この追加の複雑さを忘れてください）。完全なルールは セクション6. で公開されています。 「純粋なX.509」は、明確な識別名ですべてを参照する一種の世界的なLDAPサーバーであるディレクトリのコンテキストで機能することになっていることに注意してください。
Directoryは実際には機能しないため、現状ではまったく存在しないため、既存の実装はより厳密で単純なルールを実装する傾向があります。一般的に言えば、証明書を検証するWebブラウザー[〜＃〜] e [〜＃〜]CAによる問題 [〜＃〜] c [〜＃〜]は、同じCAによって同じ鍵で署名されている場合にのみ、CRLを受け入れます。このルールは、パスの検証を単純かつ制限のない状態に保ちます（そうでない場合、パス内の各証明書のCRLを取得する必要があり、各CRLが独自のパス検証を必要とする別のCRL発行者証明書に対して検証されるという状況を想像するかもしれません。オン）。したがって、独自のルートCAに対して相対的に独自のCRLを作成しても、実際の影響はほとんどありません。
したがって、証明書と同様に、CRLは常に署名されるオブジェクトであり、その署名（*）を検証せずに使用されることはないため、プレーンなHTTPで提供できます。 HTTPSを使用してCRLを提供することは、無駄なリソースです。一部の実装（Windowsなど）は証明書の検証時にHTTPS URLに従うことを拒否するため（CRL、OCSP、または追加の中間CAダウンロードの場合）、SSLを検証し、次に検証する別の証明書のため、CRLのダウンロードが機能しなくなることさえあります。そしておそらく無限ループ。
（*）ここでは、従来は自己署名されていたルートCAの「証明書」を除外します。これらはX.509の意味での実際の証明書ではなく、証明書のエンコーディングルールを模倣するオブジェクトのみです。
一部の（少なくとも）Mozillaブラウザーには構成変数security.OCSP.require（IRL about：configを参照）があり、デフォルトでfalseに設定されていることを追加したいと思います。
Security.OCSP.requireが "false"に設定されている場合、ブラウザーはフォールバックして、指定されたCRL配布ポイントURIでのCRLの検証にフォールバックする必要があります。 CAとCRLが見つかります。
経験的に（少なくともLinuxでは）このURLがブロックされている場合、少なくともMozillaブラウザー（Firefox、Sea Monkey、Chrome）は、証明書が取り消されて置き換えられているかどうかを確認せずに証明書を渡します。
これがどのように脆弱性ではないのか理解できませんが、それは元の質問の要点ではありませんでした。
参考：Windowsでは、CRLとOCSPの設定はグループポリシー（ローカルコンピューターポリシー、コンピューターの構成、Windowsの設定、セキュリティの設定、公開キーのポリシー）の機能であるように見えますが、少なくともWindows 2003以降では構成できます。デフォルトでは設定されていないようです。 Macでは、サードパーティをパスワードで信頼する傾向があるユーザーのために、これをキーチェーンでさらに軽減することができます。