Let's Encrypt 的 Embed SCT 支援

翻到 Let's EncryptUpcoming Features 時看到:

Embed SCT receipts in certificates
ETA: February, 2018

對 Embed SCT 不熟,所以查了查這個功能。

這指的是在簽發 SSL certficiate 後,把資料丟給 Certificate Transparency (CT) 伺服器後,伺服器會提供 signed certificate timestamp (SCT);而這個資料放到 SSL certificate 內叫做 Embed SCT:(出自 CT 的 FAQ)

What is an SCT?
An SCT is a signed certificate timestamp. When a certificate authority or a server operator submits a certificate to a log, the log responds with an SCT. An SCT is essentially a promise that the log server will add the certificate to the log in a specific time. The time, known as the maximum merge delay (MMD), helps ensure that certificates are added to logs in a reasonable time. The SCT accompanies the certificate until the certificate is revoked. A TLS server must present the SCT to a TLS client (along with the SSL certificate) during the TLS handshake.

當使用 ECC 時會小於 100 bytes:

How big is an SCT?
SCTs are less than 100 bytes, assuming elliptic curve signatures are used.

這樣才能試著解釋前幾天提到要拔掉 HPKP 的事情:「Chromium 內提案移除 HPKP (HTTP Public Key Pinning)」,也就是為什麼他們是提 CT 解,而不是 DNS CAA 解...

不過我記得 CT server 可以自己架自己 submit 不是嗎?後來有另外規定一定要用第三方的嗎?這樣又很怪...

Chromium 內提案移除 HPKP (HTTP Public Key Pinning)

Twitter 上看到這則 tweet,提到要移除 HPKP (HTTP Public Key Pinning):

blink-dev 上的討論可以參考「Intent To Deprecate And Remove: Public Key Pinning」(就是上面那個連結,只是拉出來)。

這個提案大概可以推敲出理由... 目前的作法必須寫進瀏覽器內,這樣明顯會有 scale 問題,而且這個作法本身就很 workaround,只能保護所謂「高價值」的 domain,而且因為是綁在 Public Key 上,如果 CA 換了 Intermediate Certificate 就有可能會導致檢查過不了。

另外一方面,scale 而且合理的替代方案已經發展出來了。如果瀏覽器會檢查 DNS CAA 資訊 (這個規格可以在 DNS 裡設定有哪些 CA 可以簽這個 domain),就能解這個問題 (加上 DNSSEC 會更加確保驗證過程)。像是這樣:

example.com.    IN      CAA     0 issue "letsencrypt.org"
example.com.    IN      CAA     0 issuewild ";"

不過這個提案本身提到 CT (Certificate Transparency) 怪怪的,因為 CT 無法避免惡意的簽發 (發了以後故意不送 CT):

Finally, remove support for built-in PKP (“static pins”) at a point in the future when Chrome requires Certificate Transparency for all publicly-trusted certificates (not just newly-issued publicly-trusted certificates). (We don’t yet know when this will be.)

但在瀏覽器支援 DNS CAA 可以避免,結果在討論時都沒到 DNS CAA...

另外在 Hacker News 上也有討論:「Public Key Pinning Being Removed from Chrome (groups.google.com)」可以看一下,有個人有提到用 DNS CAA 的方法...

不過印象中這群人對 DNS-based 的方案都不太喜歡,所以也有可能是這樣不考慮在瀏覽器端實作 DNS CAA 吧...

HPKP 遇到的阻礙

關於 HPKP,可以參考「HTTP Public Key Pinning 介绍」這篇介紹,寫得很清楚。

HPKP 是解決 CA 架構錯發憑證的方案 (無論是無意或是故意),像是最近吵的比較熱的 WoSign 發出 GitHub 的憑證的問題就可以用 HPKP 解。

原理上來說,就是在 HTTP header 裡面指出這個站台所允許的 Root CA 有哪些。所以跟 HSTS 一樣是走 Trust On First Use 架構,當 client 第一次連上的時候會記下資訊,之後就可以使用這個資訊來驗證。

但 HPKP 與 HSTS 不同的地方在於,HSTS 只是個 Yes/No 問題 (i.e. 是否強迫使用 HTTPS),而且通常 migrate 上去後就不會拔掉。

但 HPKP 則是要指定 Root CA,這代表不能隨便換一家簽。當你用的那家 Root CA 出包時就苦了... (就像 WoSign 免費憑證的問題)

這使得 HPKP 的實作成本過高,而且得到效益太低,另外也因為替代的方案有不少 (像是 Certificate Transparency),導致 HPKP 根本沒什麼人用:「Is HTTP Public Key Pinning Dead?」。

在 comment 有人直接拉出來統計,使用的比率反而在下降:

From my stats looking to the Alexa 1K top websites from 2015-07-26 to 2016-07-31 the number of websites NOT using HPKP increase from 99.47% to 99.58% which means almost nothing.

不過我覺得算是平行發展吧,這些驗證的技術都不怎麼衝突... HPKP 解決問題的方法非常的技術面,而 Certificate Transparency 還是走稽核路線讓 Root CA 回報每一個發出的 Certificate...

HPKP (HTTP Public Key Pinning) 常見的錯誤

Netcraft 因為有一套系統在觀察整個 internet 的架構,有時後會整理出一些有趣的東西,像是這次整理出來的 HPKP,就找出很多設定上的錯誤:「HTTP Public Key Pinning: You’re doing it wrong!」。

抓了一下列出來哪些:

  • Zero max-age:這個 XDDD
  • Wrong pin directives:沒寫 pin-sha256,包括寫成 pin-sha512 (RFC 不支援)、pin-sha1 (RFC 也是不支援)、pin-sha (RFC 還是不支援)、pin-sha245 (按歪了 XDDD)、ping-sha256 (XDDD)。
  • Only one pinned public key:HPKP 規定要有兩個 pinned public key。
  • No pins at all:因為 typo 而導致失效,像是忘記用雙引號包起來 (double quote,也就是「"」)。
  • At least two pins, but no backup pins:應該要是兩個完全獨立的 CA。
  • Setting HPKP policies over HTTP:這個會被直接忽略。
  • Not quite got round to it yet...:看到「Public-Key-Pins: TODO」也頗不賴 XDDD
  • Using HPKP headers to broadcast skepticism:跟上面那個有異曲同工的感覺 XDDD Public-Key-Pins: This is like the most useless header I have ever seen. Preventing MITM, c'mon, whoever can't trust his own network shouldn't enter sensitive data anywhere.
  • Violation reports that will never be received:有問題時的 report 送到有問題的 domain 上,於是就送不出去了 XD

Firefox 也要支援 Public Key Pinning Extension for HTTP

在「Mozilla to Support Key Pinning in Firefox 32」看到的新聞,目前的標準還是 draft:「Public Key Pinning Extension for HTTP」。

被簡稱 PKP 與 HPKP:(一般比較常用前者)

We call this "public key pinning" (PKP); in particular, this document describes HTTP-based public key pinning (HPKP).

可以看到 Google Chrome 程式碼裡面是怎麼使用 PKP 技術預載的:「/trunk/src/net/http/transport_security_state_static.json」。

目前 Google Chrome 使用的方式是限制 Google 的網域只能由某些特定的 CA 才能簽,這樣可以降低其他 CA 簽出高經濟價值的 SSL certificate 的效益。

Mozilla 的 wiki 上面可以看到對應的條目:「SecurityEngineering/Public Key Pinning」,目前 Firefox 的版本是 31,也就是從下一個版本就支援了。

第一波的 32 版會支援 Mozilla 自己的某些站台,以及一些 Twitter 的網域。

第二波的 33 版會把 Twitter 的部份擴充到 *.twitter.com,另外還會支援 Google 所擁有的網域。

第三波的 34 版會支援 Firefox account (*.accounts.firefox.com)、Tor 以及 Dropbox