Squarespace が、ホストしている数百万のサイトを HTTPS で保護することを決定したことを嬉しく思います！ 彼らのチームとの話し合いの中で、彼らが最初から OCSP ステープリングを展開していることを知り、感銘を受けました。彼らに、最初のゲストブログ投稿（今後さらに増えることを期待して）で、彼らの経験を読者と共有してもらうようお願いしました。

- Josh Aas、ISRG / Let's Encrypt エグゼクティブディレクター

OCSP ステープリングは、証明書の失効ステータスを確認するためのオンライン証明書ステータスプロトコル (OCSP) の代替アプローチです。これにより、証明書の提示者は、CA が署名したタイムスタンプ付きの OCSP 応答を最初の TLS ハンドシェイクに追加 (「ステープリング」) することで、OCSP 応答の提供に伴うリソースコストを負担できるようになり、クライアントが CA に連絡する必要がなくなります。証明書所有者は、定期的に OCSP レスポンダーにクエリを送信し、応答をキャッシュします。

従来の OCSP では、CA は証明書の失効情報を要求する各クライアントに応答を提供する必要があります。人気のある Web サイトの証明書が発行されると、大量のクエリが CA の OCSP レスポンダーサーバーに殺到し始めます。これにより、情報がサードパーティを経由する必要があり、サードパーティが誰がどのサイトをいつ閲覧したかを特定できるため、プライバシーリスクが生じます。また、ほとんどのブラウザが Web ページに何かをロードする前に OCSP レスポンダーに連絡するため、パフォーマンスの問題が発生する可能性もあります。OCSP ステープリングは、ユーザーが CA に個別に接続する必要がなく、OCSP 応答がデジタル署名されているため、検出なしに変更できないため安全であるため、効率的です。

Squarespace での OCSP ステープリング

Squarespace プラットフォーム上のすべてのカスタムドメインに対して SSL の展開を計画していた際、私たちはローンチ時に OCSP ステープリングをサポートしたいと考えました。当社のエッジインフラストラクチャチームが構築したリバースプロキシがすべての SSL トラフィックの終端を担っており、Java で記述され、Netty を搭載しています。残念ながら、Java JDK 8 には、予備的なクライアントのみの OCSP ステープリングサポートしかありません。JDK 9 では、JEP 249 を使用した OCSP ステープリングが導入されていますが、まだ利用可能ではありません。

当社のリバースプロキシは、JDK の SSL 実装を使用していません。代わりに、netty-tcnative を介して OpenSSL を使用しています。現時点では、オリジナルの tcnative と Netty のフォークの両方に OCSP ステープリングのサポートはありません。ただし、tcnative ライブラリは、SSL コンテキストとエンジンのアドレスポインタなど、OpenSSL の内部動作を公開します。私たちは JNI を使用して netty-tcnative ライブラリを拡張し、tlsext_status OpenSSL C 関数を使用して OCSP ステープリングサポートを追加することができました。私たちの拡張機能はスタンドアロンのライブラリですが、netty-tcnative ライブラリ自体に組み込むこともできます。関心があれば、Netty の次の API 破壊的な開発サイクルの一環として、アップストリームに貢献できます。

私たちの最初の OCSP ステープリング実装の目標の 1 つは、OCSP レスポンダーのオペレーター（この場合は Let's Encrypt）の負担を軽減することでした。当社のプラットフォームでの Web サイトトラフィックの性質上、非常に長いテールを持っています。少なくとも開始時点では、すべての OCSP 応答をプリフェッチしてキャッシュすることはありません。OCSP 応答を非同期でフェッチし、近い将来に複数のクライアントが使用する場合にのみフェッチしようとすることにしました。Bloom フィルタは、キャッシュする価値のない「一発屋」を識別するために使用されます。

Squarespace は、お客様の Web サイトと訪問者のセキュリティに投資しています。私たちは、すべてのリクエストに OCSP ステープルが最終的に含まれるように、OCSP ステープリング実装の改良を継続していきます。従来の OCSP のセキュリティ上の課題に関するより詳細な議論については、このブログ投稿をお勧めします。