證書透明化的工作原理

2019 年 11 月 3 日
筆記

日誌基本功能
日誌基本操作
監視器和審計的基本操作
典型系統配置
其他系統配置

證書透明為當前的SSL證書系統增加了三個新的功能組件：

證書日誌
證書監控
證書審計

這些功能組件代表了能提供補充的監控和審核服務的離散軟體模組。他們不替代當前的SSL證書系統，也不作為一個選擇。實際上，這些組件沒有改變基礎的信任鏈模型–讓客戶端驗證域並與伺服器建立安全的連接。相反，這些組件通過支援整個SSL證書系統的公開監督和審查擴充了信任鏈模型

日誌基本功能

證書透明系統的中心在於證書日誌。一天證書日誌是一個簡單的網路服務，保存了一條SSL證書記錄。證書日誌有三條重要的特性：

只能追加–證書只能被添加到日誌中；證書不能被刪除，修改或追溯地插入到日誌中。
加密確認–日誌使用特殊的Merkle Tree Hashes加密機制來防止篡改和違規行為。
公開審核–任何人都能查詢一條日誌並且驗證日誌的行為，或驗證SSL證書已被正確地添加到日誌中。

日誌數量不必太大：需要足夠的日誌來保證日誌失敗或臨時中斷，但是還不能多到讓監控變的困難–例如，超過10條但遠小於1000條。每條日誌的操作要獨立於其他日誌（也就是，日誌間沒有自動複製）。

日誌的只能追加的性質允許使用特殊類型的加密哈希來驗證日誌沒有損壞，並且這條日誌中沒有刪除或修改任何證書的操作。這種特殊的哈希–Merkle Tree Hash–也能讓審計發現是否有人分叉了日誌或向日誌中注入過期的證書。關於哈希機制的更多資訊看證書透明化日誌工作原理。

每條證書日誌必須公開地公布其URL和公鑰（除此之外的其他東西）。任何人都可以通過HTTPS的GET和POST消息與日誌交互。

日誌基本操作

任何人都能向日誌提交證書，儘管大多數證書被證書機構和伺服器運營商提交。向日誌提交有效證書時，日誌以簽名證書時間戳(SCT) 回應。SCT是一個在某個時間段內將證書添加到日誌中的簡單的保證。這個時間段稱作最大合併延遲(MMD)。

MMD有助於確保日誌伺服器在合理的時間段內將證書添加到日誌中，並且不會阻塞證書的發布和使用，同時允許日誌為了彈性和可用性運行分散式服務。SCT伴隨證書的整個生命周期。特別是，TLS伺服器必須在TLS握手期間將SCT和證書一起交付。

證書透明支援三種交付帶有證書的SCT方法，每種的描述如下：

X.509v3擴展

證書機構（CA）使用X.509v3擴展將SCT附加到證書上。圖一展示了工作流程。證書機構向日誌中提交預認證，並且日誌返回SCT。CA然後將SCT作為X.509v3擴展附加到預認證中，對證書籤名，然後將證書交付給運營商。

該方法不需要任何伺服器更改，使運營商可以像以往一樣繼續管理其SSL證書。

TLS擴展

運營商可以使用特殊的TLS擴展交付SCT（圖2）。這種情況下，CA將證書頒發給伺服器運營商，然後伺服器運營商將證書提交到日誌中。日誌將SCT返回給運營商，然後在TLS握手期間，運營商使用帶有簽名證書時間戳（signed_certificate_timestamp）將SCT交付給客戶端。

這種方法沒有改變CA頒發SSL證書的方式。然而仍然需要伺服器以適應TLS擴展做出改變。

OCSP裝訂

運營商也可使用在線證書狀態協議（OCSP:
Online Certificate Status Protocol）裝訂來交付SCT（圖2）。這種情況下，CA同時向日誌伺服器和運營商頒布證書，然後運營商向CA進行OCSP查詢，CA返回SCT，在TLS握手期間伺服器將SCT包含在OCSP擴展中。

這種方法允許CA對SCT擔責，但是不能延遲頒布證書，這是因為CA能非同步地收到SCT。但是，確實需要修改伺服器才能進行OCSP裝訂。

監視器和審計的基本操作

監視器監控日誌中可疑的證書，像非法或未授權的證書，不正常的證書擴展，或者奇怪許可權的證書（舉例，CA證書）。監視器也驗證所有已記錄的證書在日誌中可見。通過周期性地獲取已被添加到日誌中的所有新條目來做到這一點。因此，大多數的監視器能完全複製監控到的日誌。如果一條日誌長時間地處於離線狀態，且監視器有該條日誌的副本，監視器就能作為只讀的備份日誌，向查詢該日誌的其他監視器和審計提供日誌數據。

審計驗證日誌的整體完整性。有些審計也驗證日誌中是否有特定的證書。通過周期地獲取和驗證日誌證明來做到這一點。日誌證明是被加密哈希簽名過的，以證明日誌的良好性。每條日誌必須按需提供他們的日誌證明。

審計可以用日誌證明來驗證日誌的新條目已被添加到日誌舊條目中，並且無人能通過追溯地插入，刪除，或更改證書來損壞日誌。審計也使用日誌證明來驗證日誌中的特定證書。這尤其重要，因為證書透明框架需要所有的SSL證書被登記到日誌中。
如果TLS客戶端確定（通過審計）日誌中沒有證書，可以使用日誌中的SCT作為日誌未正確運行的證據。關於日誌證明的更多資訊看證書透明化日誌工作原理。

儘管日誌證明允許審計或監視器驗證特定日誌的視圖和之前視圖的一致性，他們也需要和其他監視器和審計驗證特定日誌的視圖的一致性。為了方便證明，審計和監視器通過小道消息協議來交換日誌資訊。非同步通訊路徑幫助審計和監視器發現分叉的日誌。

典型系統配置

證書透明性框架沒有規定現有SSL證書系統中監視器和審核器的任何特定配置或位置。也就是說，一些配置比其他配置更常見。在典型的配置中，CA運行監視器，客戶端（瀏覽器）運行審計（圖3）。這種配置簡化了監控和審計間必要的消息，且讓證書機構和客戶端開發監控和審計系統，以滿足客戶和使用者的特殊需求。下面介紹一些驅動該配置的過程。

證書頒布

CA獲得日誌中的SCT，通過X.509v3擴展將SCT合併到SSL證書中（詳細過程看圖1）。然後CA向伺服器運營商頒布證書（附有SCT）。該方式需要沒有伺服器更新（所有的當前伺服器支援X.509v3擴展），且讓伺服器運營商像管理SSL證書的同樣方式來管理他們的證書。

TLS握手

TLS握手期間，TLS客戶端接收SSL證書和證書的SCT。通常，TLS客戶端驗證證書和簽名鏈。另外，TLS客戶端驗證SCT上的日誌簽名，以驗證SCT是由有效的日誌發布的，且SCT實際上是為該證書（非其他證書）頒布的。如果有異樣，TLS客戶端可能會拒絕證書。舉例，TLS客戶端通常會拒絕SCT時間戳還未生效的證書。

證書監控

大部分的監視器由證書機構操作。通過配置，證書機構構建根據自身的特定監視標準和要求進行訂製的有效的監視器。

證書審計

大部分的審計可能內置於瀏覽器中。在此配置中，瀏覽器會定期批量地發送SCT到其集成的認證組件，並且詢問這些SCT（和相應的證書）是否被正確的添加到日誌中。之後審計非同步地拿到日誌並執行驗證。

其他系統配置

除了上述典型的配置以為，監視器和審計與現存的TLS/SSL組件緊密集成，證書透明支援多種其他的配置。例如，審計可作為獨立實體運行，向證書機構和伺服器運營商提供有償或無償的服務（圖4）。監視器也可以通過伺服器運營商運行，像大型的互聯網公司Google，微軟，或雅虎。同樣地，設計也可作為獨立服務運行，也可是監視器的第二功能。