Let's Encrypt推出新的憑證透明度日誌服務Sunlight

Let's Encrypt推出Sunlight專案，這是一個憑證透明度（Certificate Transparency，CT）日誌實作，更符合現代Web公共金鑰基礎設施（PKI）的設計，官方提到，他們與知名資安專家Filippo Valsorda合作，並且參照廣泛透明度日誌記錄社群的意見，開發出了Sunlight。

Web PKI是一種保護網際網路通訊的機制，仰賴數位憑證來驗證實體身分並加密資料，而憑證透明度日誌則是為了增加Web PKI系統透明度所加入的技術，由於任何人都可以檢查和監控憑證的發行狀況，因此有助於辨識錯誤或是惡意的憑證頒發，可以強化Web PKI的可信度。

Let's Encrypt從2019年以來，一直在運作公開的憑證透明度日誌，雖然大致運作順利，但還是有一些待解決的問題。最初Let's Encrypt的Oak日誌架構採用關聯式資料庫，因此需要將每半年生成的資料，儲存在獨立的資料庫分片（Shard）中。

但隨著營運負擔和成本增加，Let's Encrypt認為繼續拆分出資料庫並不是辦法，因為目前憑證透明度日誌分片大小約在5到10 TB左右，官方提到，這對於單一資料庫來說非常大，之前他們就曾遭遇到MySQL存在16 TiB的限制，導致測試日誌失敗的案例。

擴大日誌儲存裝置對Let's Encrypt來說是一個龐大的壓力，官方表示，擁有高速磁碟和大量記憶體儲存的執行個體並不便宜，憑證透明度日誌可能因為客戶端試圖讀取所有資料而導致過載，但是施加速率限制避免執行個體過載，又會使客戶端運作緩慢，而這導致原本用於偵測錯誤憑證的透明度日誌，成為快速頒發憑證的阻礙。

為此，Let's Encrypt建立了新的憑證透明度日誌實作Sunlight專案。Sunlight採用一種稱為Tiles的結構來儲存和快取資料，以更有效地管理和提供憑證透明度日誌中的資料。憑證透明度日誌是一種二元樹，每個節點都包含兩個子節點的雜湊，而葉層級則包含日誌的實際憑證資料，樹的頂端經過數位簽署，形成一個稱為墨克樹（Merkle Tree）的可加密驗證結構。

這樣的設計讓任何人都可以驗證日誌中的憑證，同時也保證了日誌的透明度和不可篡改性。雖然墨克樹可用於校驗資料的完整性，但是卻需要進行大量的雜湊運算，對於非常大的資料集，可能產生效能瓶頸。

Sunlight的Tiles結構則是將大樹切割成許多小塊（下圖），每塊Tiles包含樹的一部分，當需要查詢特定憑證時，系統就只需找到包含該憑證的Tiles，而不需要從整棵樹的根部開始搜尋。官方提到，Tiles API與之前CT API的動態端點不同，由於CT API需要根據憑證的雜湊值獲取憑證證明，所以CT API對每個憑證都有不同回應，因此無法使用共享快取。

而Tiles API將樹作為Tiles提供，便不需要動態運算或是請求處理，因此也就不需要API伺服器，而且因為Tiles是靜態的，所以能夠被有效地快取，另外，葉子Tiles還可以壓縮儲存，能夠節省更多的儲存空間。

將日誌以一系列靜態Tiles公開，使得Let's Encrypt可以用更便宜方式水平擴展日誌服務，像是直接在S3等雲端物件儲存中切分Tiles，或是使用CDN、Web伺服器、檔案系統等。由於物件和檔案儲存更易取得且可簡單擴展，比雲端資料庫服務的成本更低。

另外，過去憑證透明度日誌採用了一種稱為合併延遲（Merge Delay）設計，來限制提交日誌的延遲。意思是向日誌提交憑證時，日誌可以立刻回傳簽署憑證的時間戳記，並承諾在日誌最大合併延遲，通常是24小時內，在日誌中包含憑證。

也就是說，合併延遲是一個憑證被提交到日誌之後，與實際被合併進日誌的時間延遲，這種延遲讓日誌營運者有時間進行不要的處理和驗證，但這也代表有一段時間，憑證存在卻沒有公開紀錄。這樣的情況可能導致一些問題，像是日誌服務出現問題，導致無法在最大合併延遲內將憑證合併到日誌中，如此日誌就無法履行對提交憑證的承諾，而影響憑證的有效性，而且沒有即時合併憑證，攻擊者也可能趁著空窗時間進行惡意行為。

因此Sunlight採用批次處理的方法，將憑證以批次的方式整合到日誌中，而這會導致提交憑證過程增加一些延遲，但官方表示，這輕微的延遲可以避免常見憑證透明度日誌失敗的情況。

Let's Encrypt目前已經發布了Sunlight軟體與規範，並開始運行Sunlight憑證透明度日誌服務，官方建議憑證頒發機構開始測試提交憑證資料到新的Sunlight日誌中，也建議讓憑證透明度程式考慮信任該新架構日誌。