Certificate Transparency 那些事

最近本站 HTTPS 方面有兩個變化：一是本站域名（imququ.com）加入了 Chrome 的 HSTS Preload List，從 Chrome 49 開始生效；二是我給本站 HTTPS 證書啟用了 Certificate Transparency 策略。HSTS Preload List 在我之前的文章中寫過，更多介紹及申請如何加入請點這里。本文主要介紹 Certificate Transparency。

Certificate Transparency 是什么？

HTTPS 網站的身份認證是通過證書信任鏈完成的，瀏覽器從站點證書開始遞歸校驗父證書，直至出現信任的根證書（根證書列表一般內置于操作系統，Firefox 則自己維護）。然而，受信任的 CA（證書頒發機構）有好幾百個，他們成為整個網站身份認證過程中一個較大的攻擊面。實際上，目前由于 CA 失誤導致錯誤簽發證書；以及個別 CA 出于某些目的（如監控加密流量）故意向第三方隨意簽發證書這兩種情況時有發生。

無論是 CA 無意或有意簽發出來的「非法證書」，都能通過目前的證書鏈校驗機制的驗證。這些 CA 簽發的「非法證書」相比自簽名的「無效證書」，更難被發現，即使被發現依靠現有機制也很難快速消除影響。

另外，域名所有者的管理不善也可能導致域名配置被第三方控制，從而第三方能夠向 CA 申請你網站的證書（特別是 DV 類型的證書）。這種情況，發現和處理同樣很麻煩。

而 Certificate Transparency 就是為了解決這些問題誕生的，它可以直譯為證書透明度，由 Google 主導，并由 IETF 標準化為 RFC6962 。Certificate Transparency 的目標是提供一個開放的審計和監控系統，可以讓任何域名所有者或者 CA 確定證書是否被錯誤簽發或者被惡意使用，從而提高 HTTPS 網站的安全性。

Certificate Transparency 整套系統由三部分組成：1）Certificate Logs；2）Certificate Monitors；3）Certificate Auditors。完整的工作原理可以看官方文檔： How Certificate Transparency Works 。

簡單說來，證書所有者或者 CA 都可以主動向 Certificate Logs 服務器提交證書，所有證書記錄都會接受審計和監控。支持 CT 的瀏覽器（目前只有 Chrome）會根據 Certificate Logs 中證書狀態，作出不同的反應。CT 不是要替換現有的 CA 設施，而是做為補充，使之更透明、更實時。

Certificate Logs 服務器由 Google 或 CA 部署， 這個頁面 列舉了目前已知的服務器。合法的證書提交到 CT Logs 服務器之后，服務器會返回 signed certificate timestamp（SCT），要啟用 CT 就必須用到 SCT 信息。

如何啟用 Certificate Transparency

根據官方文檔，啟用 CT 有三種方案，分別介紹如下：

1）通過 X.509v3 擴展

CA 先預簽證書，并將證書提交到 CT Logs 服務器得到 SCT 信息，然后 CA 將 SCT 做為預簽證書的擴展再次簽名，這樣就得到了一個含有 SCT 擴展的證書。通過查看 TLS 握手階段中的 Certificate 響應可以看到 SCT 信息（OID 1.3.6.1.4.1.11129.2.4.3）：

2）通過 TLS 擴展

我們也可以自己提交證書給 CT Logs 服務器，得到 SCT 并存起來。然后通過配置 Web Server，使其能在 TLS 握手階段的 Server Hello 響應中啟用 signed_certificate_timestamp 擴展，傳遞 SCT 信息。具體配置方法后面再介紹，這里先來看下這個擴展長什么樣：

當然，只有客戶端在 Client Hello 請求中包含了 signed_certificate_timestamp 擴展時，服務端才需要給出對應的 SCT 回應。

3）通過 OCSP Stapling

還有一種做法是，CA 按照普通流程完成證書簽發后，再將證書提交到 CT Logs 服務器得到 SCT，然后改造 OCSP（Online Certificate Status Protocol，在線證書狀態協議）服務，將 SCT 信息包含到 OCSP 響應中。服務端啟用 OCSP Stapling（OCSP 封套）后，就可以在證書鏈中包含證書的 OCSP 查詢結果，其中就包含 SCT 信息。

簡單對比一下三種方案：

	CA 成本	開發者成本	備注
X.509v3 擴展	高（需要實時提交證書并等待返回 SCT、簽署兩次證書）	無	DigiCert 支持這種方案（ via ）
TLS 擴展	無	高（需要自己提交證書、編譯 Web Server 加入 CT 模塊、修改配置等）	任何證書都可以使用這種方案
OCSP Stapling	中（需要異步提交證書取回 SCT、改造 OCSP 服務）	中（需要啟用 Web Server 的 OCSP Stapling）	Let's Encrypt 計劃支持這種方案（ via ）

通過 TLS 擴展啟用 CT 是最普適的方案，接下來簡單介紹下在 Nginx 中如何操作：

1）獲取 SCT 文件

通過 ct-submit 這個模塊，可以方便地將證書提交給 CT Logs 服務器并得到 SCT 響應。這個模塊需要 go 語言的支持：

apt-get install golang

wget -O ct-submit.zip -c https://github.com/grahamedgecombe/ct-submit/archive/v1.0.0.zip
unzip ct-submit.zip
cd ct-submit-1.0.0
go build

編譯成功后，當前目錄會出現名為 ct-submit-1.0.0 的可執行文件。接著就可以提交了：

./ct-submit-1.0.0 ct.googleapis.com/aviator <~/www/ssl/chained.pem >~/www/scts/aviator.sct
./ct-submit-1.0.0 ct1.digicert-ct.com/log <~/www/ssl/chained.pem >~/www/scts/digicert.sct

以上代碼分別向 Google 和 Digicert 的服務器提交了證書，更多可用的服務器可以在 這個頁面 找到。

chained.pem 是我的站點證書和中間證書，最開始是站點證書，之后是中間證書。

2）編譯 Nginx，加入 CT 模塊

要讓 Nginx 支持發送 signed_certificate_timestamp 這個 TLS 擴展，需要加入 nginx-ct 這個模塊。nginx-ct 需要與 OpenSSL 1.0.2+ 或者 BoringSSL 4fac72e+ 一起編譯，不支持 LibreSSL。推薦使用 CloudFlare Patch 過的 OpenSSL（ via ）：

git clone https://github.com/cloudflare/sslconfig
wget -O openssl.zip -c https://github.com/openssl/openssl/archive/OpenSSL_1_0_2-stable.zip
unzip openssl.zip
mv openssl-OpenSSL_1_0_2-stable/ openssl
cd openssl && patch -p1 < ../sslconfig/patches/openssl__chacha20_poly1305_cf.patch 

cd ../

wget -c http://nginx.org/download/nginx-1.9.10.tar.gz
tar zxf nginx-1.9.10.tar.gz

wget -O nginx-ct.zip -c https://github.com/grahamedgecombe/nginx-ct/archive/v1.0.0.zip
unzip nginx-ct.zip

./configure --add-module=../nginx-ct-1.0.0 --with-openssl=../openssl --with-http_v2_module --with-http_ssl_module

然后 make 并 make install 就搞定了。 make install 之前記得先停掉 nginx 服務，不然很可能需要手動殺死之前的 nginx 進程。

3）修改配置

最后，修改 Nginx 配置，加入以下兩行并重啟服務即可：

ssl_ct               on;
ssl_ct_static_scts   /your/path/to/scts;

Certificate Transparency 與 Chrome

最后，說了這么多，如何不啟用 CT 會有什么后果呢？實際上，對大部分網站影響都不大。首先 CT 策略目前只有 Chrome 支持；其次 Chrome 也知道現在支持 CT 的網站并不多，所以對于沒有提供 SCT 信息的 HTTPS 網站也沒有太大的影響。

對于使用 EV 證書的網站，如果沒有按要求提供 SCT 信息，從 2015 年 1 月 1 日開始，Chrome 不會顯示小綠條（詳細要求可以看 這個頁面 ）。一般 EV 證書提供商都會把 SCT 信息嵌入到證書之中，大家如果有 EV 證書可以檢查一下。萬一證書里沒有嵌入 SCT 信息，那最好通過 TLS 擴展的方式啟用 CT，不然買了 EV 證書，Chrome 不給顯示小綠條還是挺虧的。

對于其它類型的證書（OV、DV 等），如果沒有提供 SCT 信息，最新的 Chrome 只是會在點擊地址欄小綠鎖時給出說明，內容如下：

The server did not supply any Certificate Transparency information.服務器未提供任何 Certificate Transparency 信息。

Chrome 的這個提示內容有過調整，之前是這樣的：

The identity of this website has been verified by XXX but does not have public audit records.該網站的身份已通過 XXX 的認證，但沒有公開審核記錄。

而提供 SCT 信息之后，Chrome 的提示是這樣的：

The server supplied valid Certificate Transparency information.服務器提供了有效的 Certificate Transparency 信息。

本站截圖如下：

本文先寫到這里。明天我就要回家過年了，祝大家新春快樂，吉祥如意~

本文鏈接： https://imququ.com/post/certificate-transparency.html ， 參與評論 。

-- EOF --

發表于 2016-02-03 21:59:06 ，并被添加「HTTPS、Nginx」標簽，最后修改于 2016-02-03 21:59:06 。

本站部署于「 阿里云 ECS 」。如果你也要購買阿里云服務，可以使用我的九折推薦碼  NY1Z0E （限新用戶），多謝支持！

 

來自： https://imququ.com/post/certificate-transparency.html