Let』s Encrypt證書支持CT，讓你的網站更安全

2018 年四月份 Let』s Encrypt 宣布其發布的證書將直接嵌入 SCT 信息，作為全球最大的免費 CA 機構，他的一舉一動對於 HTTPS 網站部署者來說非常關鍵，我們不禁要問，SCT 作用是什麼？總結來說，證書透明度（Certificate Transparency，CT）特性（注意 CT 和 SCT 的區別，CT 是證書特性，而 SCT 是 CT 特性的一種表現形式）是證書的有效補充，它能夠讓你的網站更安全。

這篇文章全面回顧 CT，如果你的網站還不支持該特性，那麼應該快速行動起來了。

證書

CT 是證書的一個特性，正因為證書存在一些缺點，CT 才被創造出來，在理解 CT 之前，我們有必要理解什麼是證書、證書的作用、證書的缺陷。

如果想部署 HTTPS 網站，首先向 CA 機構申請一張證書，CA 機構在審核申請者的身份後，會簽發一張證書，證書中包含了申請者網站的主機名、主機公鑰，同時 CA 機構會用自己的私鑰對整個證書進行簽名，並將簽名添加到證書文件中，然後發送給證書申請者。

證書是 TLS 協議中非常關鍵的一環，其主要作用：

向網站訪問者確認伺服器的真實身份，確保客戶端（瀏覽器）是和真正的網站提供者在通信，避免遇到中間人攻擊，實現密碼學中的身份認證特性。

客戶端和伺服器使用證書中的公鑰（依賴於不同的密碼協商演算法，功能有所不同）協商出主密鑰（Master Secret），有了主密鑰，客戶端和伺服器端就可以保證通信數據是加密且沒有被篡改。

證書的細節信息比較多，可以參考其他書籍和文章，本文主要描述證書在 PKI（public key infrastructure，公鑰基礎設施）體系中的一些缺陷。

對於一個 HTTPS 網站來說，PKI 體系並不是孤立的技術解決方案，它由很多機構組成，比如 CA 機構、網站部署者、用戶、瀏覽器，證書是 PKI 最核心最重要的內容，通過下圖可以了解 PKI 的構成。

證書最大的問題就是偽造證書的存在，一旦出現偽造證書，PKI 安全體系將會非常脆弱，出現偽造證書的原因如下：

CA 機構有意無意會簽發一些錯誤的證書，比如 CA 機構沒有正確校驗申請者的身份。

CA 機構是一個追求盈利的機構，在利益的驅動下，可能會無節制的簽發證書，如果簽發一個惡意的二級 CA 證書，帶來的危害更大。

攻擊者會通過各種技術攻擊手段，冒充或者偽造某個域名的擁有者，從而成功申請到一張證書，然後通過證書進行危害操作。

在 PKI 基礎設施中，瀏覽器校驗證書的時候，只能判斷證書是否是合法 CA 機構簽發的，沒有技術手段校驗證書是否是非法的。即使未來發現證書是非法的，證書吊銷更新機制（CRL 和 OCSP）也是非常滯後的。

非法證書帶來的危害是非常大的，如果非法證書校驗成功，對於用戶來說，他認為在和真正的伺服器在通信，實際上是和潛在的攻擊者在通信，用戶的隱私和安全性將得不到保障。

在 PKI 基礎設施中，可能會出現以下一些困惑：

域名擁有者無法知曉那些 CA 機構給他簽發了證書，也不知道是否有人冒充他的身份申請證書並提供服務。

CA 機構並不清楚它到底簽發了多少證書，也不確定是否簽發了偽造證書，二級 CA 簽發機制不可控。

對於瀏覽器來說，它沒有技術手段校驗證書是否是合法的。

證書透明度

為了解決證書潛在的問題，谷歌提出了一個解決方案，這就是證書透明度（CT），目前這個技術解決方案已經非常成熟了，了解 CT，以下兩個網站必須了解：

www.certificate-transparency.org

rfc6962

CT 是一組技術解決方案，它能夠審計、監控證書的簽發、使用，從而讓證書在 PKI 體系中更透明，它不是證書的替代解決方案，而是證書的有效補充，它也沒有改變 PKI 體系，這幾點務必要記住。

通過 CT，能夠達成以下的幾個目標：

CA 機構能夠知曉其簽發了那些證書，並快速檢測到是否簽發惡意證書了。

網站擁有者能夠知曉域名對應證書籤發的全過程，一旦發現有攻擊者偽造了域名對應的證書，可以快速聯繫 CA 機構，吊銷該證書。

瀏覽器廠商能夠審計證書的使用情況，如果發現有惡意證書，可以快速關閉 HTTPS 連接，保障用戶的安全。

CT 是一個公開的技術解決方案，並不是封閉的，也不是谷歌專有的，PKI 體系中任何一個組織都可以參與，從而有效保障網站的安全性。

CT 由三部分組成：

Certificate logs

Certificate monitors

Certificate auditors

這三部分的結構如下圖，詳細細節會逐步描述。

（1）Certificate logs

Certificate logs 是一個網路服務（需要部署，也要提供查詢服務），是 CT 最核心的組成部分，Certificate logs 記錄了證書所有簽發記錄，相當於一個證書中心資料庫，任何人都可以新增、查詢證書籤發記錄。

Certificate logs 有幾個特性：

只讀，只能新增記錄，不能更新或者刪除記錄

通過一種稱為 Merkle Tree Hash 的機制進行密碼學保護，保證數據沒有篡改。

任何人都可以向 Certificate logs 提交證書，並且查詢證書是否合法存在於 Certificate logs 中。

向 Certificate logs 提交證書新增請求後，Certificate logs 會返回 SCT 信息（Signed Certificate Timestamp），SCT 非常重要，相當於證書籤發的票據。

在 HTTPS 協議握手過程中，瀏覽器就是通過 SCT 信息（可以通過三種途徑獲取）確認網站是否支持 CT，如果發現網站不支持，可以中止握手過程。現在大家應該明白 CT 和 SCT 的區別了。

任何人都可以構建 Certificate logs 服務，一般情況下，CA 機構給證書申請 SCT 的時候，會向多個 Certificate logs 服務發送請求。

下列表格列舉了部分符合 Chrome CT 策略的 Certificate Logs 服務：

（2）Certificate monitors

有了 Certificate Logs 服務的中心數據，Monitors 服務就可以基於 Certificate Logs 服務進行監控操作，任何人（主要是 CA 機構）都可以構建 Certificate monitors 服務。

通過 Certificate monitors 服務，能夠查詢證書是否是未授權或者非法的，也能檢測證書包含的擴展是否合法，也能檢測證書信息是否存在於 Certificate Logs 服務中，總之通過 monitors 服務，證書的簽發和使用納入了 PKI 監控體系，證書的使用更加透明了。

下表列舉幾個常見的 CT Monitors 服務。

重點推薦 crt.sh，輸入域名就可以查看所有的證書籤發記錄了，如下圖：

Facebook 的監控服務也非常好，你可以在該服務上登記你擁有的域名，一旦該域名有相應的證書籤發了，Facebook 就會立刻發送消息通知你，這樣你就可以更好的監控證書的使用了。

潛在的一個問題，任何人可以查詢任意域名的 CT 信息，潛在帶來一定的隱私問題，當然證書和域名一樣，使用過程確實應該處於監控之下，這樣才能保障安全。

（3）Certificate auditors

Certificate auditors 服務主要由瀏覽器來完成，主要有二個步驟：

HTTPS 握手階段校驗證書是否包含 SCT 信息，如果沒有說明證書不符合 CT 機制，可能存在潛在的危險。

非同步校驗證書是否存在錯誤簽發，惡意使用的情況，相當於完成 Certificate monitors 服務的功能，整個過程是非同步的，避免影響 HTTPS 握手。

如何獲取 SCT

前面描述了基礎性的知識，對於網站部署者來說，其更關心如何讓網站支持 CT，確切的說，如何獲取 SCT 信息，網站支持 CT 有三種途徑，分別是證書擴展、OCSP 協議、TLS/SSL 協議擴展。這三種方式有不同的應用場景，有些需要 CA 機構處理，有些需要網站部署者處理，接下去分別描述。

（1）通過證書擴展獲取 SCT

目前 Let』s Encrypt 證書直接包含了 SCT 信息，這種方式無需網站部署者做任何的操作就能讓網站支持 CT，從效率上和可管理性看，這種方式是最好的，CA 機構提供的證書直接包含 SCT。

對於 CA 機構（以 Let』s Encrypt 為例）來說，需要注意在簽發證書的時候，先要獲取 SCT 信息，然後再將 SCT 信息嵌入到證書中，但是由於沒有證書就無法獲取 SCT，為了解決這個問題，Let』s Encrypt 先生成一張 precertificate 證書，然後向兩個 Certificate Logs 提交 precertificate 證書（一個是谷歌的 Certificate Log 服務，另外一個是非谷歌的 Certificate Log 服務），獲取到 SCTs 後，再修改 precertificate 證書，添加 SCTs 擴展。

從 2018 年 4 月 30 號以後，所有在 Let』s Encrypt 簽發或更新的證書將自動包含 SCTs。

可以使用 OpenSSL 命令行工具獲取證書 SCTs 信息，比如運行下列命令：

該命令和 SCTs 有關的輸出如下：

從輸出可以看出，由兩個 Certificate Logs 提供 SCTs 信息。

（2）OCSP 封套的方式

CA 機構可以使用 OCSP 協議的方式提供 SCT 信息，這屬於一種非同步提供 SCT 信息的方式，OCSP 協議主要提供證書吊銷信息，相比 CRL 來說，OCSP 擴展性更好，也就是說 CA 機構的 OCSP 服務也可以包含 SCTs 信息。

從操作性上看，網站部署者如果想支持 CT，需要部署 OCSP 封套服務（原生 OCSP 服務有很多的缺點），當然現在 OCSP 封套服務已經很普及了。

可以尋找一個支持 OCSP 封套的網站（且包含 SCTs 信息），檢查 OCSP 響應中的 SCT 信息，運行以下命令：

關鍵輸出如下：

（3）TLS 擴展方式獲取 SCT

如果前兩種獲取 SCT 的方式都不能用，可以採用 signed_certificate_timestamp TLS/SSL 協議擴展獲取 SCT。

這種方式需要網站部署者自行向 Certificate Log 服務申請 SCTs 信息（如果 CA 機構不能支持 SCT，那麼只能採取這種方式），大概的步驟如下：

伺服器實體向 Certificate Logs 服務申請 SCT 信息。

配置 TLS/SSL 協議擴展支持 SCT 信息，比如 Nginx nginx-ct 模塊就能支持 signed_certificate_timestamp TLS/SSL 協議擴展 。

那麼客戶端如何通過 TLS 擴展的方式獲取 SCT 信息呢，步驟如下：

客戶端向伺服器發送 HTTPS 協議請求。

客戶端請求的 Client Hello 消息包含 signed_certificate_timestamp TLS/SSL 協議擴展，請求伺服器返回 SCT 信息。

伺服器接收到 Client Hello 消息後，在 Server Hello 消息中返回 SCT 信息。

客戶端接收到 SCT 信息後，代表該證書是一個有效的證書，是經過審計的。

使用 Wireshark 工具抓取 HTTPS 協議消息，在 Client Hello 消息中可以看到 signed_certificate_timestamp TLS/SSL 協議擴展，消息如下：

伺服器 Server Hello 消息會響應 signed_certificate_timestamp TLS/SSL 協議擴展，響應信息如下：

該響應包含了兩個 SCT 信息，分別是 Pilot 和 Symantec 提供的 Certificate Logs 服務。至於 Nginx 如何配置，此處就不進行描述了。

這種方式需要網站部署者做很多工作，沒有特殊情況，建議不要採用。

CT 普及度

CT 是谷歌提出來的解決方案，在 Chrome 瀏覽器上做了很多的嘗試，截止到今日，其普及程度越來越高了，Firefox 也準備開始校驗 SCT，但目前還沒有實施完。

如果想了解 Chrome 瀏覽器支持 CT 的情況，可以訪問 chromium 的 ct-policy 倉庫，其中講解了在 Chrome 中校驗 CT 的策略。

從 2015 年 1 月份開始，Chrome 要求所有的 EV 證書開始支持 CT。

從 2018 年 4 月 30 號開始，Chrome 要求所有的證書支持 CT（2018 年 4 月 30 號以後簽發的證書，老的證書沒有該限制），如果訪問的網站包含 SCT，則在 TLS/SSL 協議握手階段就會失敗。

對於 CT 來說，是否生效，取決於瀏覽器的處理策略，但從本質上來說，CA 機構應該提交證書籤發信息，讓證書籤發行為透明化。而且目前已經證明，CT 是具備可行性的一種技術解決方案。

那麼在 Chrome 上如何讓用戶感知 CT 的存在呢？在老的 Chrome 版本開發者工具上可以看到 CT 信息（較新版本的 Chrome 已經去除，可見 CT 可以進入生產階段了）。下圖描述 Chrome 42 版本處理 CT 的相關情況。

如果你不了解網站用戶使用的瀏覽器（針對 CT，目前其實就是 Chrome），但又想了解客戶端處理 CT 是否遇到問題（應對 Chrome 硬性要求網站支持 CT 的期限）; 或者從安全的角度考慮，強制希望客戶端瀏覽器校驗 SCTs，那麼可以提前了解一個新的 HTTP 消息頭 Expect-CT。

如果你想了解網站 CT 支持情況，可以使用報告模式，比如：

如果瀏覽器在處理 SCTs 的時候遇到問題，會向 report-uri 屬性對應的地址發送報告，以便讓管理員了解詳細的信息。max-age=0，表示每次訪問都處理 SCTs 信息。

如果你向讓瀏覽器強制校驗 SCTs，可以使用 enforce 模式，比如：

enforce 屬性表示強制讓瀏覽器校驗 SCTs，max-age=30 表示在 30 秒內緩存校驗結果。

這個消息頭的詳細定義可以參考 Expect-CT Extension for HTTP draft-ietf-httpbis-expect-ct-02，目前 Chrome 61 開始的版本已經支持該特性，可以進行相關測試。

作為全球最大的瀏覽器廠商，Chrome 在推進 CT 普及上做了很多工作，主流的收費 CA 機構也逐漸支持 CT，對於開發者來說，應該校驗下自己的證書或者網站是否支持 CT，如果沒有，應該快速行動起來。

贈書福利

本文作者虞衛東的新書《深入淺出 HTTPS：從原理到實戰》現已上市，這本書全面介紹了 HTTPS 領域的相關知識，內容包括密碼學、OpenSSL 命令行、證書、TLS 協議、HTTPS 網站性能優化、HTTPS 網站最佳實踐、大型網站 HTTPS 架構設計等等。

截至本周日 24 點之前，本文留言獲贊最多的 5 位用戶，每人可獲得一本《深入淺出 HTTPS：從原理到實戰》，歡迎大家留言。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！