Logo for Sunlight

Let's Encryptは、最新のWeb PKIの機会と制約を念頭に置いて一から構築した、Certificate Transparencyログの新しい実装であるSunlightを発表できることを誇りに思います。設計と実装を主導したFilippo Valsorda氏とのパートナーシップにより、GoogleのChromeチームとTrustFabricチーム、Sigsumプロジェクト、その他のCTログおよびモニターの運用者を含む、より広範なトランスペアレンシーロギングコミュニティからのフィードバックを取り入れました。彼らの洞察は、プロジェクトの方向性を形作る上で非常に役立ちました。

CTはWeb PKIにおいて重要な役割を果たし、証明書の発行を監視および調査する機能を強化します。しかし、CTログの運用は、証明書の量の増加に伴い、増大する課題に直面しています。たとえば、Let's Encryptは毎日400万件を超える証明書を発行しており、それぞれを2つの別々のCTログに記録する必要があります。現在確立されている「Oak」ログには7億件を超えるエントリが保持されており、これらの課題の重大な規模を反映しています。

この記事では、Sunlightの背後にある動機と、その設計がCTエコシステムの堅牢性と多様性を向上させると同時に、Let's Encryptのログの信頼性とパフォーマンスを向上させることをどのように目指しているかを探ります。

データベースからのボトルネック

Let's Encryptは2019年からパブリックCTログを運用しており、運用に関して多くの経験を積んできましたが、問題がないわけではありません。「Oak」ログにデプロイしたアーキテクチャにおける最大の課題は、データがリレーショナルデータベースに格納されていることです。私たちは、1年分のデータを独自のデータベースを持つ「シャード」に分割し、その後、シャードを1年ではなく6か月をカバーするように縮小することで、スケールアップしました。

運用負担とコストが増加するため、データベースをますます分割するというアプローチは、永遠に続けたいものではありません。CTログシャードの現在のストレージサイズは5〜10テラバイトです。これは単一のデータベースにとって懸念されるほど大きく、以前はMySQLで16TiBの制限に達したときにテストログが失敗しました。

読み取り容量のスケールアップには、高速ディスクと大量のRAMを備えた大規模なデータベースインスタンスが必要ですが、これは安価ではありません。ログ内のすべてのデータを読み取ろうとするクライアントによってCTログが過負荷になり、その過程でデータベースが過負荷になるというインスタンスが多数発生しています。過負荷を防ぐためにレート制限が課されると、クライアントはAPIをゆっくりとクロールすることを余儀なくされ、誤って発行された証明書を検出するための高速なメカニズムとしてのCTの効率が低下します。

タイルの提供

当初、Let's Encryptは新しいCTログ実装の構築のみを計画していました。しかし、Filippo氏との話し合いで、他のトランスペアレンシーシステムが元のCertificate Transparency設計を改善しており、読み取りパスAPIを変更することでログをさらに堅牢でスケーラブルにすることができることに気付きました。特に、Go Checksum DatabaseはCertificate Transparencyにインスパイアされていますが、データを簡単に保存およびキャッシュできるタイルのシリーズとして公開するためのより効率的な形式を使用しています。

Certificate Transparencyログはバイナリツリーであり、すべてのノードには2つの子のハッシュが含まれています。「リーフ」レベルには、ログの実際のエントリである証明書がツリーの右側に追加されます。ツリーの最上位はデジタル署名されています。これは、Merkleツリーと呼ばれる暗号化によって検証可能な構造を形成し、証明書がツリーに含まれているかどうか、およびツリーが追加専用であるかどうかを確認するために使用できます。

Sunlightタイルは、それぞれ256個の要素を含むファイルであり、特定のツリーの「高さ」のハッシュ、またはリーフレベルの証明書（または事前証明書）です。Russ Cox氏はブログでタイルの仕組みについて素晴らしい説明をしており、Sunlight仕様の関連セクションを読むこともできます。現在実行しているCTの実装であるTrillianでさえ、内部ストレージとしてこれらのタイルに似たサブツリーシステムを使用しています。

以前のCT APIの動的エンドポイントとは異なり、ツリーをタイルとして提供するには、動的な計算やリクエスト処理は必要ないため、APIサーバーの必要性を排除できます。タイルは静的であるため、証明書ごとに異なるレスポンスを持つget-proof-by-hashなどのCT APIとは対照的に、効率的にキャッシュされるため、共有キャッシュはありません。リーフタイルは圧縮して保存することもでき、ストレージをさらに節約できます。

ログを一連の静的タイルとして公開するというアイデアは、読み取りパスを水平方向に、比較的安価にスケールアウトしたいという願望からきています。S3などのクラウドオブジェクトストレージにタイルを直接公開したり、キャッシングCDNを使用したり、Webサーバーとファイルシステムを使用したりできます。

オブジェクトストレージまたはファイルストレージはすぐに利用でき、簡単にスケールアップでき、クラウドプロバイダーのデータベースよりもはるかに低コストです。これは明白な前進のように思われました。実際、既存のCTログの前にS3でサポートされるキャッシュが既にあります。つまり、現在データを2回保存しています。

المزيد من السجلات قيد التشغيل المزيدのログの実行

タイルAPIは読み取りパスを改善しますが、書き込みパスでもアーキテクチャを簡素化したいと考えていました。Trillianでは、書き込みを処理するノードを選択するためのリーダー選出のために、etcdとともにノードの集合を実行します。これはやや複雑であり、CTエコシステムでは別のトレードオフが可能であると考えています。

重要な認識は、Certificate Transparencyは既に分散システムであり、クライアントは複数のログに証明書を送信し、利用できないログから他のログに正常にフェールオーバーすることです。個々のログの書き込みパスには、可用性の高いリーダー選出システムは必要ありません。単純な単一ノードライターは、CTログ プログラムで必要な99％のサービスレベル目標を満たすことができます。

単一ノードのSunlightアーキテクチャにより、同じ量のコンピューティング能力で複数の独立したログを実行できます。これにより、個々のログの潜在的な稼働時間が短くても、システム全体の堅牢性が向上します。リーダー選出は不要になりました。チェックポイントを保存し、ツリーがフォークされる可能性のある2つのインスタンスを誤って同時に実行することを防ぐために、単純な比較とスワップのメカニズムを使用しますが、これはリーダー選出よりもオーバーヘッドがはるかに少なくなります。

マージ遅延の解消

CTの目標の1つは、ログへの送信の遅延を制限することでした。それをサポートするために、マージ遅延と呼ばれる設計機能が追加されました。証明書をログに送信すると、ログはすぐに署名付き証明書タイムスタンプ（SCT）を返すことができ、ログの最大マージ遅延（通常は24時間）以内にログに含めることを約束します。これは発行を遅らせないための良いトレードオフのように思えますが、ログがマージされていない証明書で動作を停止し、最大マージ遅延に間に合わず、その約束を破るというインシデントやニアミスが複数発生しています。

Sunlightは異なるアプローチを採用し、証明書をバッチ処理してログに統合している間、送信を保留し、マージ遅延をなくします。これはわずかな遅延の増加につながりますが、より一般的なCTログ障害ケースの1つを回避することは価値があると考えています。

また、SCTの拡張機能に最終リーフインデックスを埋め込むことができ、CTをMerkleツリー証明の直接クライアント検証に一歩近づけることができます。この拡張機能により、クライアントはサーバー側のルックアップテーブルまたはデータベースを必要とせずに、新しい静的タイルベースのAPIからログ包含の証明を取得することもできます。

明るい未来

Sunlightの今日の発表はほんの始まりに過ぎません。Sunlightのソフトウェアと仕様をリリースし、Sunlight CTログを実行しています。開始するためのリソースについては、sunlight.devをご覧ください。CAはLet's Encryptの新しいSunlight CTログへのテスト送信を開始し、CTモニターと監査人はSunlightログの使用をサポートし、CTプログラムはこの新しいアーキテクチャで実行されているログの信頼を検討することをお勧めします。Sunlightログは、将来的にブラウザによって実行されるCTプログラムによってSCTに使用できるようになり、CAはブラウザのCTロギング要件を満たすためにそれらに依存できるようになることを願っています。

これまでに、「TrillianのメンテナーであるGoogleのTrustFabricチームは、この方向性とSunlightの仕様をサポートしています。サーバーレスツールを使用して他のエコシステムでキャッシュ可能なタイルベースのログを目指して取り組んでおり、これをTrillianとctfeに組み込むとともに、Sunlight APIのサポートを追加します。」などのコメントで肯定的なフィードバックを得ています。

設計に関するフィードバックがある場合は、ct-policyメーリングリスト、またはtransparency-dev Slackの#sunlightチャネル（参加するには招待状）でご意見をお聞かせください。

Sunlightの開発をサポートしてくださったChromeと、CTログ運用への継続的なサポートを提供してくださっているAmazon Web Servicesに感謝いたします。CTの監視や重要性を感じている組織の方は、ぜひご支援をご検討ください。詳細はhttps://www.abetterinternet.org/sponsor/をご覧ください。または、sponsor@abetterinternet.orgまでお問い合わせください。