web-dev-qa-db-ja.com

現在のブラウザは証明書の失効をどの程度うまく処理していますか？

私はFirefoxユーザーで、最近 Liu、Yabingなどに出会いました。「WebのPKIにおける証明書失効のエンドツーエンド測定」。 2015 Internet Measurement Conference。ACM、2015 調査の結果、しばらくすると、失効リストのチェックまたはOCSPがまだ実装されていないか、最新のもので部分的に実装されているのかと疑問に思いましたFirefoxだけでなく他のブラウザのバージョン。失効リストのチェックとOCSPに関する限り、しばらくの間Webをクロールして最新の更新を探していましたが（検索はほとんどFirefoxの更新に限定されていたため、認めざるを得ませんでした）、意味のあるものを見つけることができませんでした。

最近のアップデートはありますか？以下の表（以前に引用した調査からの引用）の多くが、評価全体がもう一度行われた場合、赤でクロスされたままになるでしょうか？そのような再評価をすべきだという印象を受けました。

enter image description here

Chrome=およびFirefoxなど）が採用している別のアプローチは、埋め込みCRLセットです。それらはどのくらいの頻度で更新され、セットの更新遅延は大部分の攻撃を回避するのに十分小さいですか？

web-browserfirefoxcertificate-revocationocspcrl
8
Cobalt Scales

あまりよくない。

理論的には、システムは機能するはずです。実際には、そうではありません。取り消しを管理することを目的とした実装、つまり [〜＃〜] crl [〜＃〜] と [〜＃〜] ocsp [〜＃〜] の両方に問題があります。この回答のほとんどは この記事はAlexey Samoshkinによる と この記事はScott Helmeによる に基づいています。

CRLについてはどうですか？

証明書失効リストは、証明書が有効かどうかを判断する非常に簡単な方法です。取り消されたすべての証明書のリストです。証明書が取り消されたかどうかを確認する場合は、関連する取り消しリストを確認する必要があります。

このリストは非常に大きくなる可能性があり、ダウンロードに時間がかかり、証明書の有効性を確認できるようにするにはオンラインである必要があります。ブラウザにとってオンライン要件は問題ではないように見えますが、実際にはオフラインになっている可能性のあるWebサーバーを認証するよりも、証明書の用途が多くあります。

実際には、CRLは非常に多くのオーバーヘッドを提供する古くなったメカニズムと見なされ、実際には実行できません。

OCSPについてはどうですか？

OCSPは、CRLに関するすべての問題を解決する黄金のガチョウになるように設計されました。実際には、一連の新しい問題が発生しました。

  • OCSPエンドポイントにインラインリクエストを行う必要があるため、レイテンシが増加します。
  • OCSPエンドポイントの可用性の依存関係。
  • OCSP情報を取得する証明書（およびドメイン）を送信する必要があるため、CAに対するプライバシーの侵害。

失敗についてはどうですか？

CRLまたはOCSPエンドポイントが利用できない場合はどうなりますか？結局、何もない。証明書のステータスを検証できない場合、ブラウザはデフォルトでそれらを正当なものと見なします。これは、OCSPデータを取得しようとする際にブラウザを正常に「放棄」することができる攻撃者（つまり、OCSPエンドポイントに向かうことを目的としたすべてのパケットをドロップすることにより）を意味し、失効した証明書も有効と見なされます。

失効を修正するのか、それともあきらめるのか？

これらの問題を緩和する試みがあります。 ChromeはCRLSetを使用し、MozillaはOneCRLを使用します。基本的に、私のブラウザーにはすべてのCRLのリストが含まれ、定期的に（たとえば、1日1回）更新されます。

もう1つの試みはOCSP Staplingです。これにより、証明の負担がサーバーに再度移動します。この考え方は、サーバーが定期的にCAに証明書がまだ有効かどうかを尋ね、その後、サーバーが証明書に含める時間指定された応答を受け取るというものです。

これにより、上記の問題のいくつかが修正されます。

  • 証明書とその失効ステータスは1回の送信で送信されるため、待ち時間が短縮されます。
  • CAは、ユーザーが要求したドメインに関する情報を取得しません。
  • メッセージがしばらくの間有効であるため、CAのOCSPエンドポイントの可用性が低下する可能性があります。
  • OCSPエンドポイントは、Webサーバーにより多く分散されるため、負荷が低くなります。

では、どこに漁獲物があるのでしょうか？

証明書失効の現状は悪いので、明らかに落とし穴があるはずだと述べました。 Webサーバーは、OCSPステープリングの実装にはそれほど優れていないことがわかります。 Alexeyの記事 はそれを説明するのに素晴らしい仕事をしているので、すべての詳細には触れません。基本的な要点は、有効にされていても、一部のサーバーがステープルされた応答をすぐに送信しない可能性があることです。 nginxのような一部のサーバーは、証明書が取り消された場合に応答を送信しません。これは、証明書が取り消されていることをWebサーバーが知っていても、次の理由でユーザーに通知しないことを意味します... 理由？

must-stapleはどうですか？

よろしくお願いします！アイデアは単純です。証明書には、サーバーが必須でOCSP応答をステープルする必要があることを示すフラグが含まれます。そうしないと、検証が失敗します。理論的には良さそうに聞こえるので、どこが問題なのでしょうか。

問題は、ブラウザがこのフラグに奇妙に反応することです。 FirefoxはMOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSINGをスローします。これは、それが何を意味するかをすでに知っている場合に、ある程度意味があるだけです。 T_PAAMAYIM_NEKUDOTAYIM をスローするよりもわずかに優れています。一方、Chromeはまったく気にしません。 ChromeはOCSPをまったくサポートしていないため、それを必要とする拡張機能が単に無視されているのは論理的です。

結論として、証明書の失効は壊れており、それを修正するために私たち一人一人ができることはほとんどありません。

5
MechMK1