証明書認証局(CA)のLet's Encryptが、公開鍵の証明書の失効状態を取得する通信プロトコルであるオンライン証明書状態プロトコル(OCSP)のサポートを終了することを明らかにしました。

Intent to End OCSP Service - Let's Encrypt

https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls.html

Let's Encryptのエグゼクティブディレクター兼共同創設者であるジョッシュ・アース氏は2024年7月23日に、「私たちは本日、OCSPのサポートを終了し、証明書失効リスト(CRL)をできるだけ早く導入する意向を発表します」と述べました。

Let's Encryptは記事作成時点で約10年間にわたってOCSPのレスポンダーを提供してきましたが、2022年からはCRLのサポートも行っているとのこと。アース氏はOCSPのサポートを打ち切る主な理由について、「OCSPがインターネット上のプライバシーに多大なリスクをもたらすため」と説明しています。



ユーザーが、OCSP経由で証明書の状態をチェックするブラウザやソフトウェアでインターネットにアクセスすると、OCSPレスポンダーを提供しているCAは、その訪問者がサイトにアクセスしているIPアドレスを識別することができます。

Let's Encryptはそのようなデータを故意に保持しないようにしていますが、法的な命令によりデータの収集と提出を強制される可能性は排除できません。一方、CRLにはそのような問題はないとのこと。

アース氏の懸念とは直接関係ありませんが、OCSPにまつわる問題としては、2020年にリリースされたmacOS Big SurがOCSPでの認証を平文で行っていたことによるプライバシーの問題や、OCSPのチェックの遅延が原因で動作が低速になるパフォーマンスの問題が発生し、大きな議論になったことが知られています。

「Appleが起動中のアプリの情報を収集するせいでMacが低速化する」問題にAppleが対処、実際に何が起こっていたのかを説明する - GIGAZINE



また、Let's Encryptは設立以来OCSPサービスの提供と運用に相当なリソースを費やしてきましたが、CRLによりOCSPは必須ではなくなったため、CAインフラを可能な限り簡素化し効率性を維持するためにも、今回の措置は必要であったとアース氏は説明しています、

アース氏は「現在OCSPサービスに依存している人には、できるだけ早くその依存を解消するプロセスを開始することをお勧めします。また、VPNなどブラウザ以外の通信を保護するためにLet's Encryptの証明書を使用している場合は、証明書にOCSPのURLが含まれていなくてもソフトウェアが正しく動作することを確認する必要があります。幸い、ほとんどのOCSP実装は『フェイルオープン』、つまり問題が発生しても通信を継続する方式であるため、OCSPの応答を取得できなくてもシステムが破綻することはありません」と呼びかけました。

そもそも、OCSPはCRLの問題を解消するために策定された経緯があり、今回の変更にはメリットとデメリットがあります。SSL認証の自動化サービス・SSLMateの創業者であるアンドリュー・エア氏はソーシャルニュースサイト・Hacker Newsへの書き込みで、CRLはすべての証明書の状態ではなく取り消された証明書のみをリスト化するため、CAによる遺漏を検知できない点を指摘した上で、「証明書にOCSPのURLを含めなくてもいいようにするだけでなく、全発行者のOCSPのURLが共通認証機関データベース(CCADB)で開示されるようにすればよかったと思います。そうすれば、プライバシーの問題は解決し、OCSPレスポンダーの運用コストは削減され、証明書の状態に関する透明性も維持されたでしょう」と述べました。

これに対し、Hacker Newsに降臨したアース氏は「OCSPの実行をCAに要求することは、CAの運用を複雑で高価なものにします。これにはかなりのマイナス面があり、Let's EncryptがOCSPに費やすコストは、CAのほかの業務に投入できないコストに他なりません。OCSPを続ける代わりに何がおざなりになったのかは外部から見えませんが、実際にはかなりの負担になっており、OCSPにはそれに見合うだけの価値はないと私は考えています」と回答しました。