證書透明化的工做原理

[TOC] 譯：How Certificate Transparency Works

證書透明爲當前的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）。監視器也能夠經過服務器運營商運行，像大型的互聯網公司谷歌，微軟，或雅虎。一樣地，設計也可做爲獨立服務運行，也但是監視器的第二功能。