寫在前面

最近在整理有關證書透明度的知識，現將其記錄下來。我將從以下幾個方面去介紹CT：

• 背景故事
• 發展階段
• 整體框架
  • CT log
  • Merkle Tree
  • Monitors—Merkle Consistency Proof
  • Auditors—Merkle Audit Proof
  • Precertificate
  • Publishing Certificates into CT logs
• 總結
• 參考

背景故事

我想先從TLS談起，其前身是SSL由Netscape公司提出，是一種加密協議，提供端到端通信的數據保護功能，我們常見的https協議，就是在http基礎上增加TLS繼而提供Web瀏覽器和服務器之間的安全通信。TLS經歷了很多版本更替，目前最新的TLS1.3在2018年8月頒布（標準化，rfc8446）。谷歌透明度報告稱，在所有谷歌產品和服務中已有超過95%的流量被加密（透明度報告）。
在端到端的通信加密中最薄弱的環節是如何確定通信一方的身份，也就是他是不是他的問題。在TLS中采用證書(certificate)來彌補這個漏洞。但是，也存在一些問題，比如：頒發某個域的證書，并不會通知該域的所有者；同時，令人信服的CA（certificate authority）可能會被攻破或者與攻擊者合謀。于是，精明的壞蛋們又對證書下手做了許多壞事情。2011年八月，荷蘭CA安全證書提供商DigiNotar的服務器被發現遭到黑客入侵。黑客為包括谷歌在內的超過530個網站頒發了偽造證書。證書是有效的，因此可以實施MITM攻擊。DigiNotar 因為這次攻擊而失去信任并宣告破產。除此之外，土耳其和法國都曾報道過由可信CA頒發未經授權證書的案例。
所以，當前的數字證書管理系統中缺陷使得欺詐證書導致安全問題和隱私泄露風險變得日益明顯。因此，證書透明度被提及出來，作為證書生態系統的輔助工具，緩解證書錯誤頒發；減少安全問題以及隱私泄露的發生。

發展階段

• 在2013年被提及出來（rfc6962）
• 在2016年提出CT 2.0（draft-ietf-trans-rfc6962-bis-22）

整體框架

證書透明度我們可以理解成一個用于公開審查證書的框架，里面包含一個公開審計、只能添加證書和防篡改特性的數據庫CT logs，證書頒發機構CA，website可以說是domain owner，客戶端即browser，還有用于審查CT logs的Monitor和Auditor。我將該框架整理成一張圖，下面逐個介紹。

CT logs

• logs可以接受已過期、尚未生效、已被吊銷或在其它方面并非完全有效的證書。但是，必須拒絕發布沒有到已知根CA的有效驗證鏈證書。
• logs一般會指定接受的根CA列表。

三大特性：

• Append-only
• Cryptographically
• Publicly auditable

并且logs會定期將新添加的證書合并到logs中；

logs承若將在最大合并延遲（MMD）的固定時間范圍內，將證書合并到Merkle Tree中去。

Merkle Tree

Merkle tree看起來非常像二叉樹，中文是默克爾樹，其葉子節點上的值通常為數據的哈希值。非葉子節點上的值是對該節點的兩個孩子節點串接起來進行哈希。不僅可以快速進行完整性驗證，而且還能進行快速數據對比，找出不一致地數據。在證書透明度框架中的CT logs使用Merkel Hash Tree存儲證書，每個葉子節點都是一個證書的散列值。同時也可以進行有效的審計。使用的哈希算法是sha-256。

Monitors—Merkle Consistency Proof

Merkle Tree 的一致性證明，是為了驗證CT logs的只添加特性（append-only）。意味著只能添加證書進去，而不能修改或者刪除里面的證書。CT logs會每隔一段時間自動將新添加的證書更新到Merkle Tree中，為了驗證該特性，就需要驗證變化前的樹是否是變化后的樹的子集，并且新添加的條目都位于舊樹的后面。也可以理解為是否對新添加的樹完成了Merkel Tree的計算。如下圖所示：

CT log p是舊版本，q為新版本，新添加了g，h兩個證書，則重新計算該Merkle Tree的節點l,n，最終我們計算得到H’，同時也可以計算H，這兩個版本的樹頭我們叫做Signed Tree Head，如果我們計算得到的樹頭H’和H與logs發布的STHs相同，則證明了新版本與舊版本的一致性。

• Monitor
  它會監視所有logs，并且檢查是否存在異常行為和可疑證書。檢查每個日志中的每個新條目。它可能想要保存整個logs的副本，以便檢查。同時，它還進行一致性檢查。為了完成以上工作，它會向logs索取STHs，以便進行驗證。

Auditors—Merkle Audit Proof

該證明主要是為了驗證某一個證書在不在logs中，一般由Auditor完成。在這一驗證過程中，auditor需要知道logs中Merkle Tree的節點列表，以及要驗證證書在Merkle Tree中的路徑，這樣我們才可以計算相應的散列值。

如上圖中，要驗證證書c2在該Merkle Tree中：

• 首先計算該證書的散列值c
• 其次，將其與其兄弟節點的散列值d串接，計算得到父節點的散列值j
• 然后，同第二步原理，計算得到m和H
• 最后，比較H和log發布的STH比較，如果一致，則證明該證書c2存在于該樹中

---

• Auditor
  可以看作是Monitor的第二功能，或者是TLS 客戶端的組成部分。因為，在框架中我們可以看到，browser可以通過Auditor來查詢從server獲得的SCT（Signed Certificate Timestamp），進行Merkle Audit Proof，證明該證書是否在logs中，從而做出判斷。它首先向logs請求該證書在樹中的索引和audit path（base64編碼的Merkle Tree節點數組，證明包含該證書），然后再計算并判斷。

Precertificate

為了提供一種在證書正式頒發之前就放進logs中的手段，CA先將Precertificate提交到logs，獲得對應的SCT。該證書與普通證書的區別在于其存在一個poison extension(OID 1.3.6.1.4.1.11129.2.4.3)從而使其無效。預證書提交必須隨附預證書簽名證書（如果使用），以及所有必要的附加證書，以驗證鏈，直至達到可接受的根證書，即預證書的錯誤簽發等同于最終證書的錯誤簽發。

按我的理解，CT logs中存放的證書有兩種：Precertificate和certificate。前者是證書頒發前提交到logs，后者是已經頒發的證書提交到logs。

Publishing Certificates into CT logs

有關提交到logs證書的類型有兩種：certificate和precertificate。

有關提交的方式有三種：

• CA還未正式頒發證書之前，將precertificate提交到logs，logs返回SCT，CA將其嵌入最終的證書中。
• 證書已經頒發給server，server將其提交到logs，logs返回SCT，server在與client做TLS連接時，將其發送給client，以便client去檢查。
• CA頒發證書給server并且也將證書提交到logs，logs返回SCT，并加入OCSP（在線證書狀態協議），在TLS握手過程中，由client查詢ocsp，server返回SCT。

所以對應的有三種SCT傳遞方式：

• X.509證書
• TLS擴展—signed_certificate_timestamp
• OCSP

其中通過證書擴展是最簡單的方式，TLS擴展最快因為在clienthello發送的最早，OCSP是最麻煩的方式了。

Link between framework node

我想總結一下，在整個CT 框架中，部分節點之間的連接是常規的TLS連接，所以會存在一些問題。但是，大部分連接是基于CT logs中對STH和SCT簽名的公私鑰對。這種的安全性要比TLS連接高一些。

• logserver-Auditor-Browser：客戶端收到server發送過來的SCT，會交給Auditor進行審查，此時的SCT已經被log server用私鑰簽名。所以該路徑的安全性較高。
• logserver-Monitor-Auditor：來確定log server不出問題，Monitor和Auditor之間會交換從logs索取的STHs（其也被log server簽名），來確定兩者看到的視圖是一致的。這就是gossip的主要功能，后面還會補充有關gossip的知識。
• Monitor-Domain owner：domain owner依靠第三方的Monitor去觀察可疑的證書時，Monitor提供搜索查詢服務，客戶可以查詢可疑證書，他們之間也是常規的TLS連接，所以有人就這方面做了一些調查。
• website-browser：這兩者之間我們大家都熟知，是常規的TLS連接。

gossip

提出的主要目的是檢查CT logs是否存在不當行為，比如：惡意的CT logs可以重寫歷史數據通過“split view”，顧名思義，給不同的client提供不同的視圖，使得每個client都可以完成“consistency proof”以及“inclusion proof”。從而證明其“append-only”特征。所以需要一種機制來防止這種情況的發生。

提出了三種機制：

• SCT Feedback
• STH Pollination
• Trusted Auditor Relationship

總結

其還包括gossip協議，后續會補充。目前已經有很多學者對其進行了研究，一個新事物的出現肯定會出現很多漏洞，有人提出其龐大的公開的證書數據會暴漏一些隱私、也有人提出在Monitor---Domain owner之間的TLS連接安全性有待提高。

創作不易，隨緣打賞！！！

參考

https://transparency.dev/verifiable-data-structures/
https://theno.github.io/presi-ct-deployment/#/
https://tools.ietf.org/html/rfc6962#page-18

總結

以上是生活随笔為你收集整理的证书透明度（Certificate Transparency）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。