作者 | Karthiek Maralla

譯者 | 平川

我們構(gòu)建的互聯(lián)網(wǎng)安全體系其基礎(chǔ)是我們無(wú)法真正驗(yàn)證的信任。

證書頒發(fā)機(jī)構(gòu)是互聯(lián)網(wǎng)安全的守門人，但歷史表明，即使是最受信任的 CA 機(jī)構(gòu)也可能變得不可靠。本文探討了引入了證書透明度（Certificate Transparency，簡(jiǎn)稱 CT）的原因，它的工作原理，以及它對(duì)數(shù)字信任的未來(lái)意味著什么。我們將揭示現(xiàn)實(shí)世界的違規(guī)行為，深入了解 CT 的架構(gòu)（日志、監(jiān)控器和審計(jì)器），并探討它如何重塑了 TLS 生態(tài)系統(tǒng)。

為什么我們不再信任安全鎖

幾十年來(lái)，瀏覽器地址欄中的綠色安全鎖一直是事實(shí)上的在線安全信號(hào)。但在后臺(tái)，那個(gè)熟悉的圖標(biāo)依賴于一個(gè)脆弱的證書頒發(fā)機(jī)構(gòu)網(wǎng)絡(luò)，這些私人公司受托驗(yàn)證網(wǎng)站的身份并頒發(fā)數(shù)字證書。

遺憾的是，事實(shí)證明，這種模式非常容易被濫用。

從國(guó)家干預(yù)到草率的操作規(guī)范，證書生態(tài)系統(tǒng)經(jīng)歷了多次信任危機(jī)。問(wèn)題不在于加密本身——而在于誰(shuí)來(lái)驗(yàn)證所有權(quán)和身份我們才信任。

事實(shí)證明，綠色安全鎖可能被偽造。

這就是引入 CT 的原因——一個(gè)僅支持追加的、公開可審計(jì)的日志，其中記錄了所有已頒發(fā)的證書。通過(guò)實(shí)現(xiàn)信任的可驗(yàn)證性與透明度，CT 為 TLS 協(xié)議提供了有力補(bǔ)充。

在本文中，我們將深入剖析 CT 的工作原理和重要性，以及基礎(chǔ)設(shè)施工程師和安全架構(gòu)師在當(dāng)今愈加透明的 Web 環(huán)境中構(gòu)建和運(yùn)營(yíng)服務(wù)時(shí)應(yīng)該掌握的知識(shí)。

理解問(wèn)題：當(dāng) CA 變得不可靠時(shí)

想象一下，你正在運(yùn)行一個(gè)安全的 Web 應(yīng)用程序（正確配置了 TLS 證書）。一切看起來(lái)都很好……直到你意識(shí)到，在你不知情的情況下，一家遭到入侵的 CA 機(jī)構(gòu)為你的域名頒發(fā)了一個(gè)惡意證書。

這并非假設(shè)。以下是 臭名昭著的 CA 故障簡(jiǎn)史：

DigiNotar（2011 年）

黑客入侵了這家位于荷蘭的 CA 機(jī)構(gòu)，并頒發(fā)了 500 多個(gè)欺詐性證書，其中有一個(gè)是針對(duì)谷歌的。荷蘭政府撤銷了對(duì) DigiNotar 的信任，但在此之前已經(jīng)發(fā)生了廣泛的中間人（MITM）攻擊。

賽門鐵克（2015-2017 年）

這家機(jī)構(gòu)被發(fā)現(xiàn)為真實(shí)域名（如“google.com”）頒發(fā)了測(cè)試證書。最終，所有賽門鐵克根證書都不再被 Chrome 和 Firefox 所信任。

Trustwave、CNNIC 等

每家機(jī)構(gòu)都被發(fā)現(xiàn)簽發(fā)了可疑或未經(jīng)授權(quán)的證書，通常以內(nèi)部測(cè)試或國(guó)家利益為由。

這些事件揭示了 CA 模型的一個(gè)核心缺陷：它是一個(gè)多對(duì)多的信任系統(tǒng)，其中任何一個(gè)故障點(diǎn)（任何 CA）都可能破壞任何一個(gè)網(wǎng)站。瀏覽器平等地信任所有根 CA。

為什么這種情況會(huì)持續(xù)存在？在 CT 出現(xiàn)之前，關(guān)于頒發(fā)了哪些證書，沒(méi)有一個(gè)公開的記錄。除非網(wǎng)站所有者通過(guò)緩慢且很少使用的撤銷檢查來(lái)發(fā)現(xiàn)欺詐性證書，否則濫用行為可能長(zhǎng)期存在而不被察覺(jué)。

證書透明度的工作原理

證書透明度引入了一個(gè)僅支持追加的、可驗(yàn)證的加密日志，記錄所有合規(guī) CA 機(jī)構(gòu)頒發(fā)的所有證書。這些日志使得每個(gè)已頒發(fā)的證書都變得可觀察、可審計(jì)。

下圖說(shuō)明了這個(gè)過(guò)程：

圖 1：證書簽名和頒發(fā)過(guò)程

以下是更詳細(xì)的步驟：

• 在 CSR 生成期間，網(wǎng)站所有者生成 CSR 請(qǐng)求 CA 機(jī)構(gòu)頒發(fā) TLS 證書。

• 在證書頒發(fā)期間，CA 機(jī)構(gòu)驗(yàn)證請(qǐng)求并頒發(fā) TLS 證書。

• 在日志提交期間，CA 機(jī)構(gòu)將證書（或預(yù)證書）提交給一個(gè)或多個(gè) CT 日志，都是公開的、僅限追加的數(shù)據(jù)結(jié)構(gòu)（通常是 Merkle 樹），其中存儲(chǔ)了證書，可供任何人查詢。Merkle 樹是一種加密數(shù)據(jù)結(jié)構(gòu)，可確保日志只能追加且不可篡改。

• SCT 是 CT 日志以加密方式簽署的承諾，聲明其已經(jīng)接收證書并將該其納入了日志。

• 提交后，CT 日志將 SCT 返回給 CA 機(jī)構(gòu)。

• SCT 被發(fā)送，嵌入到最終的證書中或在 TLS 握手期間提供。

• 像 Chrome、Firefox 和 Safari 這樣的瀏覽器會(huì)拒絕或標(biāo)記沒(méi)有有效 SCT 的證書，它們是信任所必需的。

• 域名所有者使用工具主動(dòng)檢測(cè) CT 日志中的惡意證書或錯(cuò)誤頒發(fā)的證書。

這種方法為什么有效

通過(guò)加密保障機(jī)制（Merkle 樹與公共日志（CT 日志））和瀏覽器強(qiáng)制執(zhí)行相結(jié)合，該生態(tài)系統(tǒng)使得 CA 機(jī)構(gòu)幾乎不可能秘密頒發(fā)欺詐性證書而不被發(fā)現(xiàn)。

構(gòu)建一個(gè)安全的 CT 生態(tài)系統(tǒng)

在實(shí)踐中，要使 CT 發(fā)揮作用需要的不僅僅是日志，還需要一個(gè)由監(jiān)控器、審計(jì)器和客戶端組成的系統(tǒng)。

• CT 日志必須遵循嚴(yán)格的要求：僅限追加、加密包含證明、高可用性和日志輪換機(jī)制。

• 監(jiān)控器不間斷地監(jiān)視日志中的新證書，如果出現(xiàn)流氓證書，就會(huì)提醒域名所有者。

• 審計(jì)器驗(yàn)證日志的完整性（即日志條目既沒(méi)有被刪除也沒(méi)有被篡改）。

• Gossip 協(xié)議檢測(cè)日志不當(dāng)行為。例如，不誠(chéng)實(shí)的日志可能向不同的客戶端提供不同的視圖。Gossip 協(xié)議可以對(duì)這些視圖進(jìn)行交叉驗(yàn)證。

例如，谷歌運(yùn)營(yíng)著多個(gè)生產(chǎn)級(jí)的 CT 日志。任何現(xiàn)代瀏覽器，如 Chrome，都需要至少兩到三個(gè)來(lái)自獨(dú)立日志的 SCT，才會(huì)認(rèn)為 EV 和 DV 證書是有效的。

注：擴(kuò)展驗(yàn)證（EV）證書提供增強(qiáng)的身份驗(yàn)證，而域名驗(yàn)證（DV）證書只驗(yàn)證域名所有權(quán)。

以谷歌 Chrome 的策略為例，它要求所有公開可信的 CA 機(jī)構(gòu)都必須提交 CT 日志，并在 CT 截止日期（例如 2018 年 4 月強(qiáng)制執(zhí)行）后拒絕沒(méi)有有效 SCT 的證書。

CT 實(shí)踐

證書透明度不再只是一種理論，而是一個(gè)運(yùn)營(yíng)基礎(chǔ)設(shè)施，為工程師們提供了以下工具：

• crt.sh 是一個(gè)搜索界面，可以搜索多個(gè) CT 日志。輸入域名就可以查看所有曾經(jīng)頒發(fā)的證書。

• 谷歌的證書透明度日志列表列出了所有受信任的日志、它們的運(yùn)營(yíng)商和狀態(tài)。

• 開源庫(kù)項(xiàng)目，如 certstream、go-ct等，幫助用戶構(gòu)建自定義監(jiān)控器和審計(jì)器。

• 大型組織并未采用自動(dòng)化手段將證書監(jiān)控整合到其持續(xù)集成 / 持續(xù)交付（CI/CD）安全管道中（例如在新證書出現(xiàn)時(shí)觸發(fā)警報(bào)）。

現(xiàn)實(shí)世界的 CT 應(yīng)用包括：Facebook 運(yùn)行著自己的監(jiān)控器；Cloudflare 將 CT 檢查集成到其 TLS 接入過(guò)程中；Let’s Encrypt 要求將所有已頒發(fā)的證書提交到 CT 日志。

證書透明度入門：給工程師的實(shí)用小技巧

• 在公共 CT 日志中監(jiān)控你的域名：使用 crt.sh 或 Certstream 等工具發(fā)現(xiàn)為你的域名頒發(fā)的證書，并及早發(fā)現(xiàn)未經(jīng)授權(quán)的頒發(fā)行為。

• 將 CT 監(jiān)控集成到你的 CI/CD 管道中：當(dāng)域名出現(xiàn)新證書時(shí)自動(dòng)觸發(fā)警報(bào)，實(shí)現(xiàn)對(duì)潛在錯(cuò)誤頒發(fā)或影子 IT 風(fēng)險(xiǎn)的快速響應(yīng)。

• 利用開源庫(kù)：使用certstream或ct-tools等項(xiàng)目構(gòu)建自定義監(jiān)控器或?qū)?CT 檢查集成到你的安全工具中。

• 了解瀏覽器策略：確保頒發(fā)的證書符合主要瀏覽器的 CT 要求（如 Chrome、Safari），避免出現(xiàn)意想不到的信任問(wèn)題。

圖 2：端到端證書透明度工作流程說(shuō)

通過(guò) GitHub Actions 實(shí)現(xiàn) CT 監(jiān)控

自動(dòng)化 CT 在 DevOps 管道中的可見性

為了在生產(chǎn)中實(shí)現(xiàn) CT 審計(jì)，團(tuán)隊(duì)可以使用 GitHub Actions 自動(dòng)化證書監(jiān)控。以下是一個(gè)針對(duì)你的域名檢測(cè)可疑證書的工作流示例：

yaml # .github/workflows/ct-monitor.yml
name: Monitor CT Logs
on:
  schedule:
    - cron: '0 */6 * * *' # 每 6 小時(shí)
  workflow_dispatch:
jobs:
  check-certificates:
    runs-on: ubuntu-latest
    steps:
    - name: Check issued certs from crt.sh
      run: |
        DOMAIN="example.com"
        curl -s "https://crt.sh/?q=${DOMAIN}&output=json" | jq -r '.[].common_name' | sort -u > certs.txt
    - name: Compare with known cert list
      run: |
        comm -13 known-good-certs.txt certs.txt > suspicious.txt
        if [ -s suspicious.txt ]; then
          echo "::error ::Potential unknown certs detected!"
          cat suspicious.txt
          exit 1
        fi

在 CI/CD 或事件響應(yīng)中驗(yàn)證 SCT

在審計(jì)期間手動(dòng)驗(yàn)證 SCT：DevOps 團(tuán)隊(duì)可以在事件分級(jí)處理或證書部署的過(guò)程中，通過(guò)檢查 PEM 證書中嵌入的 SCT 來(lái)驗(yàn)證 SCT 的存在。

代碼片段：

#!/bin/bash
CERT_FILE="your_cert.pem"
openssl x509 -in "$CERT_FILE" -noout -text | grep -A 10 "Signed Certificate Timestamp"

未來(lái)之路：不斷演變的互聯(lián)網(wǎng)信任機(jī)制

CT 不是萬(wàn)能的，它只是一個(gè)基礎(chǔ)。未來(lái)的創(chuàng)新將旨在彌合現(xiàn)有的信任缺口：

雖然在將開放性帶入 Web PKI 方面，CT 是一個(gè)里程碑，但該生態(tài)系統(tǒng)仍在發(fā)展。有一些新的提議和實(shí)驗(yàn)工具旨在解決 CT 的盲點(diǎn)，并將其擴(kuò)展到新的信任域，以下是未來(lái)展望。

Static Sunlight API：將 CT 引入靜態(tài)環(huán)境

有一項(xiàng)新的創(chuàng)新是 Static Sunlight API，旨在使 CT 日志包含數(shù)據(jù)在無(wú)法查詢實(shí)時(shí)日志的環(huán)境中也能被訪問(wèn)，例如移動(dòng)設(shè)備、物聯(lián)網(wǎng)系統(tǒng)以及連接受限的邊緣基礎(chǔ)設(shè)施。

其思想是生成 CT 日志快照或離線創(chuàng)建 Merkle 樹證明，然后嵌入到客戶端或?yàn)g覽器中并進(jìn)行靜態(tài)驗(yàn)證。這種方法在證書驗(yàn)證期間不依賴于實(shí)時(shí) CT 日志服務(wù)器，實(shí)現(xiàn)了更多保護(hù)隱私的審計(jì)跟蹤。

例如，瀏覽器可以每隔幾天獲取一次陽(yáng)光快照（Sunlight Snapshot ），并緩存證書包含證明，從而實(shí)現(xiàn)離線 SCT 驗(yàn)證而又不犧牲透明度。

委托憑據(jù)：最小化密鑰暴露

長(zhǎng)期存在的 TLS 證書帶來(lái)了運(yùn)營(yíng)風(fēng)險(xiǎn)：如果私鑰泄露，攻擊者就可以冒充服務(wù)器達(dá)數(shù)月之久。委托憑證（DC）允許證書持有者生成由主證書簽名的短效一次性憑證，有效緩解了此類風(fēng)險(xiǎn)。

這些委托憑證的壽命只有幾個(gè)小時(shí)或幾天，并通過(guò) TLS 握手分發(fā)。這種方法：

• 最大限度地降低了長(zhǎng)期密鑰泄露的風(fēng)險(xiǎn)

• 與臨時(shí)密鑰和內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）配合良好

• 已經(jīng)得到 Cloudflare 和 Mozilla 的支持

當(dāng)搭配證書透明度（CT）時(shí)，這些憑證仍然可以被記錄和監(jiān)控，保持了透明性。

后量子證書：CT 遇見 PQC

隨著量子計(jì)算的臨近，傳統(tǒng)加密算法如 RSA 和 ECDSA 面臨著風(fēng)險(xiǎn)。后量子密碼學(xué)（PQC）引入了新的簽名方案，如 Dilithium 或 Falcon，CT 需要跟上這種發(fā)展。

在不斷演變的密碼學(xué)領(lǐng)域中，當(dāng)前正在進(jìn)行的研究聚焦于增強(qiáng) SCT 的安全性和彈性。人們正努力將 SCT 嵌入到 結(jié)合量子抗性和傳統(tǒng)密碼學(xué)算法 的混合證書中。此外，還有一項(xiàng)正在進(jìn)行的工作是提高日志服務(wù)器對(duì)量子偽造證明的魯棒性，確保在出現(xiàn)高級(jí)量子攻擊的情況下證書透明度日志的完整性。最后，為了有效監(jiān)控和跟蹤已為 PQC 做好準(zhǔn)備的部署，推動(dòng)向量子安全基礎(chǔ)設(shè)施的平穩(wěn)過(guò)渡，混合日志的審計(jì)方法也在開發(fā)當(dāng)中。

谷歌已經(jīng)在特定域中使用 CT 兼容性擴(kuò)展實(shí)驗(yàn)了后量子 X.509 證書。

Gossip 協(xié)議和審計(jì)

當(dāng)前部署的 CT 機(jī)制依賴于“信任但驗(yàn)證”原則：審計(jì)器和監(jiān)視器自動(dòng)檢查日志一致性。但若日志存在選擇性造假呢？Gossip 協(xié)議應(yīng)運(yùn)而生。

像 CT-over-DNS 或全網(wǎng) Gossip 協(xié)議（如谷歌的 Trillian Gossip）這樣的工作旨在：

• 在瀏覽器、監(jiān)控器和日志服務(wù)器之間交叉驗(yàn)證 SCT

• 檢測(cè)分視圖攻擊或日志回溯

• 信任機(jī)制進(jìn)一步去中心化

對(duì)生態(tài)系統(tǒng)的健康而言，這個(gè)領(lǐng)域至關(guān)重要，最終可能會(huì)被瀏覽器和 CA 機(jī)構(gòu)強(qiáng)制要求。

重新構(gòu)想 CA 治理：ARPKI 及其它

也有一些正在進(jìn)行的研究工作旨在徹底重新思考如何選擇和治理 CA，特別是：

• ARPKI（攻擊彈性 PKI）提議，要求多個(gè) CA 機(jī)構(gòu)共同簽署每個(gè)證書

• Namecoin 和其他基于區(qū)塊鏈的想法嘗試去中心化的名稱 / 證書綁定

• 基于安全飛地（Enclave-based）的 CT 日志記錄（如 SGX）增強(qiáng)了日志的不可變性

雖然它們還不是主流，但表明了一個(gè)愿望，即分散信任，使其不受單點(diǎn)故障所影響，特別是在地緣政治或經(jīng)濟(jì)事件可能影響 CA 機(jī)構(gòu)獨(dú)立性的世界中。

圖 3：CA 世界的未來(lái)發(fā)展

參考資料與延伸閱讀

• 證書透明度項(xiàng)目（谷歌） 是 CT 生態(tài)系統(tǒng)的官方網(wǎng)站，包括日志列表、CT 政策和開發(fā)者文檔。

• RFC 6962 - 證書透明度（IETF）：定義 CT 日志、簽名證書時(shí)間戳（SCT）和包含證明的基礎(chǔ)規(guī)范。

• RFC 9162 - 證書透明度（IETF） 取代了 RFC 6962。它還指定了一個(gè)新的 TLS 擴(kuò)展，用于發(fā)送各種 CT 日志工件。但是，所有主要的瀏覽器，如 Chrome、Firefox，都尚未采用它。

• crt.sh 是 Sectigo 提供的一個(gè)證書搜索工具，它提供一個(gè)可搜索多個(gè) CT 日志的界面，適用于發(fā)現(xiàn)錯(cuò)誤頒發(fā)和域名證書歷史。

• 谷歌 Chrome 證書透明度政策 包括要求 CA 機(jī)構(gòu)遵守 CT 合規(guī)性以獲得 Chromium 瀏覽器的信任。

• Let's Encrypt CT 文檔 描述了最大的 CA 機(jī)構(gòu)如何實(shí)現(xiàn)和支持 CT 日志記錄。

• Facebook 的 CT 監(jiān)控基礎(chǔ)設(shè)施（以及其它進(jìn)一步的 文檔）描述了如何構(gòu)建可擴(kuò)展的內(nèi)部 CT 監(jiān)控。

• Static Sunlight API（下一代 CT 監(jiān)控）提供了一種新穎的方法，使用預(yù)計(jì)算的日志數(shù)據(jù)快照進(jìn)行可擴(kuò)展的 CT 聚合和審計(jì)（另見 github 項(xiàng)目）。

• ZLint - X.509 證書的證書 Linter 是一個(gè)開源工具，用于檢查和驗(yàn)證證書字段和合規(guī)性。

• 谷歌的審計(jì)工具 Monologue 驗(yàn)證 CT 日志的一致性和可靠性。

• Certstream 提供實(shí)時(shí)的 CT 日志流。

https://www.infoq.com/articles/tls-certificate-transparency/

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。