OCSP ステープル

オンライン証明書ステータス プロトコル (OCSP) ステープリングは、正式にはTLS 証明書ステータス要求拡張と呼ばれ、 X.509デジタル証明書の失効ステータスを確認するための標準です。^[1]これにより、証明書の提示者は、CA (証明機関) によって署名されたタイムスタンプ付きのOCSP 応答を最初のTLS ハンドシェイクに追加 (「ステープリング」) することで、オンライン証明書ステータス プロトコル(OCSP) 応答の提供に伴うリソース コストを負担できるようになり、クライアントが CA に連絡する必要がなくなり、セキュリティとパフォーマンスの両方が向上します。

オリジナルのOCSP実装にはいくつかの問題があります。

まず、証明書発行局 (CA) は、特定の証明書のすべてのクライアントにリアルタイムで応答する必要があるため、多大なコストがかかります。たとえば、トラフィックの多い Web サイトに証明書が発行されると、CA のサーバーは、証明書の有効性を問い合わせる膨大な量の OCSP 要求に悩まされる可能性があります。^[2]

また、OCSPチェックでは、クライアントが遭遇する各証明書の有効性を確認するために第三者（CA）に連絡する必要があるため、ユーザーのプライバシーが損なわれ、ブラウジングの速度が低下する可能性があります。^{[2] [3]}

さらに、クライアントがCAに接続してOCSP応答を得ることができなかった場合、(a)とにかく接続を継続するか（OCSPの目的に反する）、(b)攻撃があるという仮定に基づいて接続を終了するか（ただし、過度の誤った警告やブロックにつながる可能性がある）、のいずれかを選択することを余儀なくされます。^[4]

OCSPステープリングは、元のOCSP実装におけるこれらの問題に対処することを目的としています。^{[5] [6]}

OCSP ステープリングは、 Kerberos チケットを彷彿とさせる方法で両方の問題を解決します。ステープリング シナリオでは、証明書所有者自身が OCSP サーバーに定期的にクエリを実行し、署名された タイムスタンプ付きの OCSP 応答を取得します。サイトの訪問者がサイトに接続しようとすると、この応答は、証明書ステータス要求拡張応答を介してTLS/SSL ハンドシェイクに含められます (「ステープリング」) (注: TLS クライアントは、ClientHello TLS/SSL ハンドシェイク メッセージに証明書ステータス要求拡張を明示的に含める必要があります)。^[7]

サイト運営者が検証応答を制御できるようにすると、詐欺サイトが失効した証明書に対して偽の検証を発行できるようになると思われるかもしれませんが、ステープル応答はサーバーではなく証明機関によって直接署名される必要があるため、偽造することはできません。 ^[6]クライアントがステープル応答を受信しない場合は、クライアント自身がOCSPサーバーに接続します。^[4] ただし、クライアントが無効なステープル応答を受信した場合は、接続を中止します。^[1] OCSPステープルのリスクが増加するのは、証明書の失効通知が最後に署名されたOCSP応答の有効期限が切れるまで遅れる可能性があることだけです。

その結果、クライアントは、証明書が現在有効である（またはごく最近有効であった）という証明機関からの検証可能な保証を引き続き得ることができますが、OCSP サーバーに個別に問い合わせる必要がなくなります。これは、リソースの負担の大部分が証明書所有者に戻ってくることを意味します。また、クライアント ソフトウェアは、ユーザーのブラウジング習慣を第三者に開示する必要がなくなることも意味します。^[2]

全体的なパフォーマンスも向上します。クライアントがCAから直接OCSP応答を取得する場合、通常はDNSでCAのOCSPサーバーのドメイン名を検索し、OCSPサーバーへの接続を確立する必要があります。OCSPステープリングを使用すると、証明書のステータス情報は既に確立されたチャネルを介してクライアントに配信されるため、オーバーヘッドが削減され、パフォーマンスが向上します。^[5]

TLS 証明書ステータス要求拡張は、 RFC  6066 のセクション 8 で指定されています。

RFC  6961 では、サーバーが TLS ハンドシェイクで複数の OCSP 応答を送信できるようにする複数の証明書ステータス要求拡張機能が定義されています。

2013 年 4 月に期限切れとなった X509v3 拡張フィールドのドラフト提案では、TLS クライアント hello で status_request 拡張が指定されている場合、拡張を含む証明書を提示する準拠サーバーは、応答で有効な OCSP トークンを返す必要があると規定されていました。^[8]現在の提案バージョンは、追加の TLS 拡張をサポートするように拡張されています。^{[9] TLS 開発者の Adam Langley は、} Heartbleed OpenSSL バグの修復後の 2014 年 4 月の記事でこの拡張について説明しました。^[10]

OCSPステープル サポートは段階的に実装されています。OpenSSLプロジェクトは、 Mozilla Foundationからの助成金の支援を受けて、0.9.8g リリースにサポートを組み込みました。

Apache HTTP Serverはバージョン2.3.3以降でOCSPステープルをサポートしています。^[11] nginxウェブサーバーはバージョン1.3.7以降、^[12] LiteSpeed Web Serverはバージョン4.2.4以降、^[13] MicrosoftのIISはWindows Server 2008以降、^[14] HAProxyはバージョン1.5.0以降、^[15] F5 Networks BIG-IPはバージョン11.6.0以降、^[16] KEMP LoadMastersはバージョン7.2.37.1以降、lighttpdはバージョン1.4.56以降でOCSPステープルをサポートしています。^[17]

多くのウェブサーバーはOCSPステープルのサポートを宣伝していますが、実装は必ずしも信頼できるものではありません。^[18]たとえば、ApacheがOCSPサーバーにクエリを実行すると、一時的な障害が発生した場合、以前のリクエストからキャッシュされた正常な応答が破棄され、不良な応答の提供が開始されます。^[19] NginxはOCSP応答の遅延読み込みを実行するため、最初の数回のウェブリクエストではOCSP応答を追加できません。^[20]

ブラウザ側では、OCSPステープルはFirefox 26、^{[4] [21]} Windows Vista以降 のInternet Explorer、^{[22] Linux、} ChromeOS、Windows Vista以降のGoogle Chromeに実装されています。 ^[23]

SMTPの場合、Exim メッセージ転送エージェントはクライアント^{[24]モード} とサーバー^[25]モードの両方でOCSPステープルをサポートします。

OCSP ステープルは、特に多数の同時ユーザーにサービスを提供する大規模サイトで、クライアントと OCSP レスポンダーの両方にとって OCSP 検証のコストを削減するように設計されています。ただし、OCSP ステープルは一度に 1 つの OCSP 応答しかサポートしないため、中間 CA 証明書を含む証明書チェーンには不十分です。^{[26] [27]}

この制限は、 RFC 6961で規定されている複数証明書ステータス要求拡張によって解決されています。 これにより、複数のOCSP応答を送信するためのサポートが追加されます。^[28]

TLSv1.3 ではこの制限が自動的に削除され、ますます多くの Web サーバーが TLS 1.2 のサポートを中止するにつれて、ブラウザーによるRFC  6961 のサポートは無意味になります。TLS 1.2 では、サーバーが送信できるのは、エンド証明書に関連付けられた OCSP 応答という 1 つのステープル応答のみです。TLS 1.3 では、サーバーは複数の OCSP 応答を送信できます。通常は、証明書チェーン内の各証明書に対して 1 つずつです。^[29]