ChromeやEdgeはCRLやOCSPレスポンダーへ毎回アクセスして失効検証をしているのだろうか。
FirefoxやSafariはどうなのだろうか。
Chrome, Edgeは利用者がウェブ閲覧時に、ウェブサーバー上のTLSサーバー証明書に記載のCRLやOCSPのURLへアクセスして失効検証を行っていない。
以下の理由が挙げられる。
- 失効検証を行うためには、時間がかかる。OCSPクエリに数秒かかることもあり、失敗することも多い。（ウェブコンテンツを高速で表示する妨げ）
- ウェブ閲覧者がOCSPクエリを認証局に行うとき、認証局ではどのウェブサイトにどのIPアドレスのウェブ閲覧者が訪問しているか情報収集することが可能であり、プライバシーが懸念されている。
Chrome, Edge
ウェブ閲覧のたびにOCSPやCRLで失効検証をしない。
代わりにCRLSetsを利用している。
GUI上で、ウェブ閲覧のたびにOCSPやCRLで失効検証させるチェック項目は存在しない。
CRLSetsファイルは、250KBに制限されているため、失効されたすべての証明書が掲載される仕組みではない。
EdgeもChromeiumベースのブラウザになっているので、これに準拠している。
ただし、ウェブサーバー側で定期的に最新のOCSP情報を保持し、それを失効検証に利用する仕組みであるOCSPステープリングはサポートしている。
CRLSets (バックグラウンド) は主に、緊急時に Chrome が証明書を迅速にブロックできる手段である。
二次的な機能として、いくつかの非緊急の失効を含めることもできる。
失効は、CA によって公開された CRL をクロールすることによって取得される。オンライン (OCSP および CRL) チェックは、通常、Chrome では実行されない。
これらはポリシーによって有効にすることができ、場合によっては、Chromium の動作に関係なく、基盤となるシステム証明書ライブラリが常にこれらのチェックを実行する。CRLSets を実装する Chromium ソース コードは、当然のことながら publicである。
しかし、それらが生成されるプロセスはそうではない。我々は、中間CAの失効をカバーすることを目的とした、クロールされた CRL の内部リストを維持している。
そのセットの CRL は、公開された CRLSet を構成する。
リスト上の CRL は、多くても数時間に 1 回程度取得され、その CRL の正しい署名証明書と照合して検証される。現在の CRLSet は、 https://github.com/agl/crlset-tools のコードを使用してフェッチおよびダンプできる。
Chrome で使用されている CRLSet のバージョンは、chrome://components に移動することで確認できる。
https://www.chromium.org/Home/chromium-security/crlsets
OCSP リクエストにより、個人の閲覧履歴の詳細が OCSP レスポンダーのオペレーターに明らかになります。
これらは、偶発的 (ログデータ侵害など) または意図的 (令状など) に公開される可能性があります。
これが、Chrome がデフォルトでドメイン認証 (DV) または組織認証 (OV) 証明書の OCSP チェックを行わない理由の 1 つであり、Chrome Ver.106 以降では、Chrome がEV証明書に対してもチェックを行わなくなります。
ユーザーのプライバシーをより良く保護します。選択失効チェックのサポートは CRLSets を通じて引き続き利用可能であり、OCSP ステープリングも引き続きサポートされます。
Revocation checking for EV server certificates in Chrome
Chrome は、オンライン失効チェックを有効にするエンタープライズ ポリシーもサポートしていますが、これは将来削除される可能性があります。
Google Chromeの公式見解
crt.shでは、「CRLSets」に掲載されているかどうかを確認できる。
Firefox
Firefoxは中間CA証明書は、OneCRLを使用して、ウェブ閲覧者がウェブ閲覧の都度、中間CA証明書の失効検証をせずに、高速で失効検証を行う仕組みが採用されており、OneCRLの一覧は公開されている。
TLSサーバー証明書（エンドエンティティ証明書）は、wiki.mozilla.org (CA/Revocation Checking in Firefox)によればCRLは利用せず、OCSPにて失効検証を行っている。デフォルトでは、Firefox は 2 秒以内に OCSP サーバーから有効な応答を受信しない場合 (EV 証明書の場合は 10 秒)、失効チェックを無視する (フェイルソフト)。
wiki.mozilla.org (CA/History of Revocation Checking)によればCRLによる失効検証は、Firefox Ver.24にて削除されている。
CRLiteという失効検証方法も採用されている。CRLiteでは、300 MBの失効情報を 1 MBに圧縮できる。
Firefoxでは、以下の設定で失効検証のON/OFFが行うことができる。
デフォルトでは、失効検証を行う設定となっている。（チェック済み）
- メニューボタン
をクリックし、設定 を選択。 - プライバシーとセキュリティ パネルを選択。
- 「OCSP レスポンダーサーバーに問い合わせて証明書の現在の正当性を確認する」のチェックを外すと、OCSPおよびCRLでの失効検証を行わなくなる。
失効検証の結果、失効された証明書を使用しているサイトの場合以下のような表示となる。
Safari
デフォルトでCRL または OCSP をチェックしないが、OCSP ステープリングはサポートされている。
「Apple’s Revocation Enhancement」と呼ばれる機能を提供しており、必要に応じて OCSP クエリが行われる可能性がある。
「Apple’s Revocation Enhancement」は、以下のような機能となっている。
- 証明書のCTログエントリは Apple によって収集される。
- この情報を使用して、Apple は CA からの失効に関する情報を収集する。
- この集約された情報は、定期的にすべての Apple クライアントに自動的に提供される。
- この情報に基づいて、iOS アプリが失効した証明書を使用してサーバーに接続しようとすると、OCSP 経由で追加のチェックが実行される。
認証局等が用意している失効済み証明書を使用したウェブサイト
- DigiCert – DigiCert Global Root G3
（TLSサーバー証明書にはCRLとOCSPのURLのみ記載あり）
- Let’s Encrypt – ISRG Root X2
（TLSサーバー証明書にはOCSPのURLのみ記載あり）
- badssl – ISRG Root X1
（TLSサーバー証明書にはOCSPのURLのみ記載あり）
