寫在前面

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

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

背景故事

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

發(fā)展階段

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

整體框架

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

CT logs

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

三大特性：

• Append-only
• Cryptographically
• Publicly auditable

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

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

Merkle Tree

Merkle tree看起來非常像二叉樹，中文是默克爾樹，其葉子節(jié)點上的值通常為數(shù)據(jù)的哈希值。非葉子節(jié)點上的值是對該節(jié)點的兩個孩子節(jié)點串接起來進行哈希。不僅可以快速進行完整性驗證，而且還能進行快速數(shù)據(jù)對比，找出不一致地數(shù)據(jù)。在證書透明度框架中的CT logs使用Merkel Hash Tree存儲證書，每個葉子節(jié)點都是一個證書的散列值。同時也可以進行有效的審計。使用的哈希算法是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的節(jié)點l,n，最終我們計算得到H’，同時也可以計算H，這兩個版本的樹頭我們叫做Signed Tree Head，如果我們計算得到的樹頭H’和H與logs發(fā)布的STHs相同，則證明了新版本與舊版本的一致性。

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

Auditors—Merkle Audit Proof

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

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

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

---

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

Precertificate

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

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

Publishing Certificates into CT logs

有關(guān)提交到logs證書的類型有兩種：certificate和precertificate。

有關(guān)提交的方式有三種：

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

所以對應(yīng)的有三種SCT傳遞方式：

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

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

Link between framework node

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

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

gossip

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

提出了三種機制：

• SCT Feedback
• STH Pollination
• Trusted Auditor Relationship

總結(jié)

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

創(chuàng)作不易，隨緣打賞！！！

參考

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。