preload

Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率？

在「Preloading Intermediate CA Certificates into Firefox」這邊看到 Mozilla 的人打算在 Firefox 上預載所有的 Intermediate CA，以降低 HTTPS 連線發生錯誤的作法。這點在 Mozilla 的 Wiki 上也有記錄：「Security/CryptoEngineering/Intermediate Preloading」。

的確如文章裡說的，沒有正確放入 Intermediate CA 是個 server 設定上很常見的錯誤。像是前幾天看到「【茶包射手日記】網站憑證無效案例分析」這篇講的摩斯 https://www.mos.com.tw/ 其實就是這個案例，用 SSL Labs 的工具就可以掃出來問題：「SSL Report: www.mos.com.tw (210.59.225.242)」。

問題出在於沒有送出正確的 Intermediate CA(s)，所以在 Android 上找不到一條完整的 trust chain：

不過在 Windows 系統內的 CA store 是可以建立出一條完整的 trust chain，所以 Windows 上的 Microsoft Edge 與 Google Chrome 是不會有問題的 (這兩個都吃系統的 CA store)：

而 Linux 上的 Google Chrome 就會出問題 (這邊會吃 Google 自家的 CA store 資料，就是 Android 那包)。

交叉比對中華電信自家的網站，像是「SSL Report: www.cht.com.tw (2001:b000:1a4:d000:203:75:129:111)」這組，可以看到同樣都叫做「Chunghwa Telecom Co., Ltd. / Public Certification Authority - G2」的 Intermediate CA，但有兩種不同的 SHA256，可以翻到是：「609930eb807ad420afda2a8aa61b67483039168cd766e09942a48bfe7f3bdc10」與「f5fb67c8453eda34dbec8a766574f07a03548c084af2f5e6455ea769608d9ad5」，點入裡面的「Trust」tab 中可以看到中華自己的 CA 與 ePKI 的 CA 都有交叉簽，但卻不是每一個 CA 都有被所有瀏覽器認可，所以在設定的時候就得注意...

話說回來，現在因為 CA/B Forum 的標準有強制要送 CT (Certificate Transparency)，的確是有辦法抓出所有的 Intermediate CA 沒錯，但瀏覽器幫使用者預載感覺好像怪怪的？

In essence, Firefox pre-downloads all trusted Web Public Key Infrastructure (PKI) intermediate CA certificates into Firefox via Mozilla’s Remote Settings infrastructure. This way, Firefox users avoid seeing an error page for one of the most common server configuration problems: not specifying proper intermediate CA certificates.

目前大約有 2000 筆資料：

Given this information, we periodically synthesize a list of these intermediate CA certificates and place them into Remote Settings. Currently the list contains over two thousand entries.

這個比較像是 client 端的 hack？

用 link="preload" 提高下載的優先度

除了讓 browser 自己決定優先權外，在「Preload Scripts」這邊看到的技巧，可以跟 browser 說明哪些資源比較重要，請儘快先下載：

<link rel="preload" href="main.js" as="script">

Link rel=preload is useful for downloading any important resource more quickly, such as stylesheets that contain critical CSS, fonts that are used in important design elements, and hero images. It's especially important for scripts because they block page content from rendering and consume the most CPU during page load.

以作者的想法，這個技巧應該用在會卡住頁面呈現的部分，確保這些資源可以優先下載。

另外作者也提到了可以直接把這個資訊放到 HTTP header 裡面，理論上會更快：

Link: <main.js>; rel="preload"; as="script"

尤其是 sync script 應該會有幫助，建議可以跑 A/B test 看看效果：

We know that synchronous scripts block rendering, which makes the user experience feel slow. And we know that most scripts today are downloaded synchronously (rather than async). And yet only 1% of sites are using link rel=preload to download their scripts. If your site has any synchronous scripts, do an A/B test adding link rel=preload for them. It's likely this will be a win and help you create a more joyous experience for your users.

Google 開放 .app 註冊，是個 HSTS Preload TLD

Google 宣佈了 .app 的網域將開放註冊：「Introducing .app, a more secure home for apps on the web」。

整個 .app 網域都已經被 Google 設定 HSTS Preload 了：

A key benefit of the .app domain is that security is built in—for you and your users. The big difference is that HTTPS is required to connect to all .app websites, helping protect against ad malware and tracking injection by ISPs, in addition to safeguarding against spying on open WiFi networks. Because .app will be the first TLD with enforced security made available for general registration, it’s helping move the web to an HTTPS-everywhere future in a big way.

如果要註冊下來，開發的時候得注意...

Google 打算更廣泛的預設使用 HSTS

Google 宣佈了更廣泛開啟 HSTS 的計畫：「Broadening HSTS to secure more of the Web」。

然後先提到 .foo 與 .dev 的「Google Chrome 將 .dev 設為 HSTS Preload 名單」這件事情：

In 2015 we created the first secure TLD when we added .google to the HSTS preload list, and we are now rolling out HSTS for a larger number of our TLDs, starting with .foo and .dev.

接下來希望拋磚可以引玉：

We hope to make some of these secure TLDs available for registration soon, and would like to see TLD-wide HSTS become the security standard for new TLDs.

Google Chrome 將 .dev 設為 HSTS Preload 名單

其實是兩件事情... 第一件是 Google Chrome 把 .dev 結尾的網域設為 HSTS Preload 名單：「Chrome to force .dev domains to HTTPS via preloaded HSTS」。

第二件事情是隨著第一件來的，HSTS Preload 必須由 domain 擁有人提出啊... 所以 .dev 是合法的 TLD (gTLD)？

文章作者給了答案，是的，而且就是 Google 擁有的：

Wait, there's a legit .dev gTLD?
Yes, unfortunately.

(翻白眼)

這對開發者來說有種無奈感...

不過你可以用這招避開：「在 Google Chrome 連上因 HSTS 而無法連線的網站」，也就是輸入 badidea。

另外測試了一下，應該是所有的 A record 都會指到 127.0.53.53，如果有人懶得設定的話也可以用這個位置啦...

InnoDB 的 buffer pool preload 功能

Percona 的人討論了 InnoDB 提供的 buffer pool preload 功能：「Using the InnoDB Buffer Pool Pre-Load Feature in MySQL 5.7」。

就如同他所講的，因為硬體設備的進步 (主要是 SSD 的興起)，而導致 preload 的需求已經沒以前重要了：

Frankly, time has reduced the need for this feature. Five years ago, we would typically store databases on spinning disks. These disks often took quite a long time to warm up with normal database workloads, which could lead to many hours of poor performance after a restart. With the rise of SSDs, warm up happens faster and reduces the penalty from not having data in the buffer pool.

由於 SSD 的 random read 很快，反而可以直接推上線讓他邊跑服務邊 warm up。不過相對的，傳統硬碟的 InnoDB database 還是可以規劃需求，畢竟 random read 還是痛點...