幹壞事是進步最大的原動力
看到 CloudFlare 請求加入 Chromium (Google Chrome) 的伺服器列表：「Certificate Transparency - Cloudflare "nimbus2017" Log Server Inclusion Request」。
對照之前的「Chromium 內提案移除 HPKP (HTTP Public Key Pinning)」以及「Let's Encrypt 的 Embed SCT 支援」，這樣看起來是瀏覽器內會有一份白名單，只有在這白名單上的 Embed SCT 才會被信任...
但弄到這樣的話，log server 是不是也要有稽核機制？
好像哪邊搞錯了方向啊...
翻到 Let's Encrypt 的 Upcoming 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 不是嗎？後來有另外規定一定要用第三方的嗎？這樣又很怪...
Twitter 上看到這則 tweet，提到要移除 HPKP (HTTP Public Key Pinning)：
Intent To Deprecate And Remove: Public Key Pinning (in Chromium) https://t.co/agS3fll7eR
— Adam Langley (@agl__) October 27, 2017
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 吧...
歐盟在 2014 年做了關於盜版與銷量的研究，結果一直被壓到最近才發表出來 (於是就大概可以猜到結論了...)：「EU Piracy Report Suppression Raises Questions Over Transparency」。
“In general, the results do not show robust statistical evidence of displacement of sales by online copyright infringements,” the study notes.
甚至：
The study found that piracy had a slightly positive effect on the videogames industry, suggesting that those who play pirate games eventually become buyers of official content.
另外也描述了現有電影與 TV-series 定價策略偏高：
“Overall, the analysis indicates that for films and TV-series current prices are higher than 80 per cent of the illegal downloaders and streamers are willing to pay,” the study notes.
難怪被壓著...
由於 Firefox 要支援 Certificate Transparency 的緣故，在「Mozilla CT Policy」這邊 Mozilla 在討論要建立自己的 CT policy 以及自己的架構：
CT is coming to Firefox. As part of that, Mozilla needs to have a set of CT policies surrounding how that will work. Like our root inclusion program, we intend to run our CT log inclusion program in an open and transparent fashion, such that the Internet community can see how it works and how decisions are made.
這樣就有個開頭了...
Google Chrome 也公開了對 WoSign + StartCom 的計畫：「Distrusting WoSign and StartCom Certificates」。
由於大家遇到的技術問題都一樣 (之前發出的量太大，無法窮舉表列出來)，所以處理的方法也類似於 Mozilla 的作法，只信任 2016/10/21 前發出的 certificate：
Beginning with Chrome 56, certificates issued by WoSign and StartCom after October 21, 2016 00:00:00 UTC will not be trusted.
Google Chrome 目前是 54，所以這表示會在兩個版本後生效。另外特別提出來必須有 CT flag (Certificate Transparency)，或是在白名單的網站：
Certificates issued before this date may continue to be trusted, for a time, if they comply with the Certificate Transparency in Chrome policy or are issued to a limited set of domains known to be customers of WoSign and StartCom.
而因為安全考量，會有某些 certificate 是沒救的情況：(就上面的描述，看起來是指不在白名單內又沒標 CT flag 的)
Due to a number of technical limitations and concerns, Google Chrome is unable to trust all pre-existing certificates while ensuring our users are sufficiently protected from further misissuance.
話說 www.kernel.org 從本來的 StartCom 換掉了 (之前都要打 badidea 進去看)，剛剛看是 2016/10/11 簽的憑證...
這樣除了 Microsoft 還是沒動作外，其他比較大的瀏覽器都到齊了...
在 mozilla.dev.security.policy 上看到有人行動了：「Apple's response to the WoSign incidents」。這使得 Apple 成為 WoSign 事件中第一個行動的單位。
Apple 這次先把 WoSign 放入 iOS 憑證清單的黑名單公告在這邊：「Blocking Trust for WoSign CA Free SSL Certificate G2」。
WoSign 在 iOS 產品線中是靠 StartCom 與 Comodo 的交叉簽章，所以如果 Apple 只想擋 WoSign 憑證的話，必須以阻擋 Intermediate CA 的方式避開：
Although no WoSign root is in the list of Apple trusted roots, this intermediate CA used cross-signed certificate relationships with StartCom and Comodo to establish trust on Apple products.
不過為了降低對 user 的影響，這次的阻擋會有例外。當 CT log server 在 2016-09-19 前收到的 SSL certificate 還是會信任 (要注意的重點是，這邊的日期不是簽發，是送到 CT log server 上)：
To avoid disruption to existing WoSign certificate holders and to allow their transition to trusted roots, Apple products will trust individual existing certificates issued from this intermediate CA and published to public Certificate Transparency log servers by 2016-09-19.
接下來會開始更深入的調查 WoSign 與 StartCom：
As the investigation progresses, we will take further action on WoSign/StartCom trust anchors in Apple products as needed to protect users.
另外本來的棚子裡，Qihoo 360 與 StartCom 正式提出要求在 2016/10/04 與 Mozilla 的人面對面討論 (在英國)：「WoSign and StartCom: next steps」：
Following the publication of the recent investigative report, representatives of Qihoo 360 and StartCom have requested a face-to-face meeting with Mozilla. We have accepted, and that meeting will take place next Tuesday in London.
繼續來看進度... 下個禮拜應該會有更多的資料出來。
Google 宣佈他們開始收 Untrusted CA 的 Certificate Transparency 記錄：「Certificate Transparency for Untrusted CAs」，主要是這兩種 CA：
也就是被幹掉的，以及申請中的... 這樣可以後續追蹤很多東西。
雖然才 Beta 1，但 OpenSSL 先放出 1.1.0 的 Release Notes 了：「OpenSSL 1.1.0 Series Release Notes」。
有幾個新的功能以及重大的改變，包括了對 ChaCha20 與 Poly1305 的支援，並且把 SSLv2、RC4、所有 40bits 與 56bits 的 cipher 拔掉，然後支援 Certificate Transparency。
讓人頗期待... 不知道來不來得及跟上 Ubuntu 16.04？
Let's Encrypt 的人試著從多個資料來源分析 Let's Encrypt 對整個網路上安全性的影響力：「Early Impacts of Let's Encrypt」。
資料來源包括 Certificate Transparency (CT) 記錄與 censys (這個網站用 StartSSL，被我屏蔽掉了 XD)。
But I do have access to Certificate Transparency logs, as well as other data sources like Censys.io.
前者 CT 的部份會有嚴重的偏差，因為 CA/Browser Forum 只規定 EV certificate 要送 CT log，一般的 SSL certificate 可以不送 (幾乎都沒送)，而 Let's Encrypt 發的是一般的 SSL certificate，還是有送 CT log。
把資料送上 CT 是好事，但這使得 CT log 內的資料會有嚴重偏差，拿這個判斷影響力是很有問題的。
所以這份資料就是看看就好...