次のスクリーンショットによると、firefox-3.6.17-1.fc14.i686からの抜粋ですが、Firefoxには、OCSPサーバーに接続できないときに閉じて失敗するオプションがあります。
これがデフォルトで有効になっていない理由を誰かが説明できますか?
OCSPにはいくつかの問題があります。それらのいくつか:
一部のCAはOCSPサーバーを提供せず、代わりにCRLに依存しています(特に、クライアントナンスをサポートする完全なOCSPはCAにとってかなり高価です)。そして、OCSPを実装する人の間では、多くの人が仕事を妨害し、結果としてOCSP応答を検証できませんそれ自体、検証可能(たとえば、OCSP応答は、失効ステータスの専用OCSPレスポンダー証明書で署名されます)取得できません)。したがって、OCSPチェックを必須にすることは、現時点では、無視できない割合の既存のSSL Webサイトとの通信を拒否することを意味します。世界は単にOCSPを広く受け入れる準備ができていません。
大きな問題-IMO-は速度です。ブラウザーでOCSPを有効にするためにいくつかの異なるプラグと構成を使用しました。また、OCSPサーバーに負荷がかからず、高帯域幅環境で1ホップ離れているラボ環境でも、OCSPチェックはセッションの確立で深刻な遅延になる可能性があります。ユーザーが何が起こっているのかを正確に理解している他のエンジニアであっても、ユーザーからの苦情はたくさんあります。
Firefoxのようなパブリックブラウザでは、すぐに使える設定でオンラインショッピングをするときはいつでもブラウザが痛々しく遅くなることを望まないでしょう。
また、OCSPチェックにはある程度の構成があります。証明書の構成に優先するローカルOCSPサーバーがありますか?証明書はどのように構成されていますか?OCSPチェックのURLを設定する完璧な方法は1つではありません。ブラウザはOCSPリクエストに署名する必要がありますか?ナンスが必要ですか?安全なシステムの場合、これは1 OCSPチェックではなく、自己署名ルート以外のチェーン内のすべての証明書のチェックです。
また、ブラウザは何回応答なしでリクエストを再試行しますか?また、応答がなかったと判断するまでどのくらいの時間がかかりますか?
これらは、平均的なユーザーが回答できる質問ではなく、ブラウザーは、共通の最低限のもののために完全に構築されています。
CAにとって負担が大きすぎるため、いくつかの見解には同意しません。通常、OCSPサーバーはCAから分離されています。 CAはCRLに署名し、このCRLをOCSPレスポンダーに渡します。負荷分散されたOCSPレスポンダのスイートをステージングして、トラフィックを処理できます。 OCSP自体は、大きな負荷ではありません。これはかなり小さなトランザクションで、かなり単純なデータが含まれています。パフォーマンスは通常、CRLのサイズと、接続のセットアップ/ティアダウンの影響に関連しています。この種のサービスは、プッシュがそこにある場合、絶対に実行可能です。より大きな問題は、サービス自体が依然として複雑で、設定が容易でないか、普遍的でないことです。また、平均的なエンドユーザーがSSLセッションを遅らせるほどの価値があるとは言えません。
OCSPはCAに過度の負担をかけるからです。あなたが信頼できるCAであると想像してください。サーバーへの毎秒数百万のOCSPリクエストを処理するために配置する必要があるインフラストラクチャを想像してください。良いビジネスですか?