TLS 憑證的最長時效將從 825 天降到 398 天

在「Reducing TLS Certificate Lifespans to 398 Days」這邊看到才想起來沒寫這篇,這邊發生了一些有趣的事情...

提案是降低 TLS 憑證的有效時效,這件事情一開始是在 CA/B Forum 討論,但經過投票後沒有通過:「Ballot SC22 - Reduce Certificate Lifetimes (v2)」。

從投票記錄可以看到所有的憑證使用方 (包括了許多瀏覽器的廠商) 都贊同,但有大約 2/3 的憑證發行方都反對:

7 votes total including abstentions:

  • 7 Yes votes: Apple, Cisco, Google, Microsoft, Mozilla, Opera, 360
  • 0 No votes:
  • 0 Abstain:

33 votes total including abstentions

  • 11 Yes votes: Amazon, Buypass, Certigna (DHIMYOTIS), certSIGN, Sectigo (former Comodo CA), eMudhra, Kamu SM, Let’s Encrypt, Logius PKIoverheid, SHECA, SSL.com
  • 20 No votes: Camerfirma, Certum (Asseco), CFCA, Chunghwa Telecom, Comsign, D-TRUST, DarkMatter, Entrust Datacard, Firmaprofesional, GDCA, GlobalSign, GoDaddy, Izenpe, Network Solutions, OATI, SECOM, SwissSign, TWCA, TrustCor, SecureTrust (former Trustwave)
  • 2 Abstain: HARICA, TurkTrust

然後幾個比較大的憑證使用方 (AppleGoogleMozilla) 在提案被否決後就決定放到自家的規則了:「Apple strong-arms entire CA industry into one-year certificate lifespans」。

從 2020/09/01 開始,如果發出來的憑證超過 398 天就當作是無效憑證,也就是 2020/08/31 是最後一天可以發有效期限為 825 天的憑證,會落在 2022/12/05 失效:

$ date --date='Sep 1 2020 GMT+0000 +825days'
Mon Dec  5 08:00:00 CST 2022

這三家搞下去,就等於是強制性讓這些 CA 到九月就不能賣兩年的憑證了 (雖然還沒看到 Microsoft),這些 CA 一定是在心裡幹爆... XD

回頭來看一下 Limelight Networks

是因為看到「How Limelight Networks speeds up sales deals with Slack Connect」這篇,才想到 Limelight Networks 這家 CDN 之前也是這個產業很大的 vendor,在很多大型網站可以看到 llnw 的蹤跡 (當時 Microsoft 的 Windows Updates 與 Apple 的軟體下載還會用他的服務),但這十年看起來就被 CloudflareCloudFront 以及 Fastly 這些後起之秀超越過去了... (至少在聲量上面是這樣)

翻到 Global Private Network 這頁,意外發現現在有把節點列出來了,記得以前是不公開的...

在裡面可以看到台灣也有節點,不過拿 HiNet 與 APOL (家裡的 cable) 實際測官網 www.limelight.com,發現都是導去香港的點,可能是有需要的客戶才會導過去,之後有機會也許問問看...

微軟透過 Windows Update 強制安裝新版 Edge

前幾天在虛擬機內的 Windows 突然被裝了新版的 Edge,發現國外也有報導出來了:「With Edge, Microsoft’s forced Windows updates just sank to a new low」。

這次是 Windows Update 推進來的,即使在 Windows 7 上已經 EoL (2020/01/14),不會有任何安全性更新,微軟也是濫用透過這個方式推進來:

這種方式也都讓大家想到與 antitrust 的關係:

It all immediately made me think: what would the antitrust enforcers of the ‘90s, who punished Microsoft for bundling Internet Explorer with Windows, think about this modern abuse of Microsoft’s platform?

到底會不會觸發呢...

Userscript 內對於 SPA 類的頁面的修改

目前的 userscript 支援這四種啟動時機 (用 @run-at 參數指定):

  • document-start (一開始就跑)
  • document-body (出現 body 後跑)
  • document-end (DOMContentLoaded 時,或是之後跑)
  • document-idle (DOMContentLoaded 後跑)

但對於 SPA 類的頁面來說,即使用到 document-idle,也不保證執行時頁面已經渲染完成,這時候可能是 framework 才正要開始處理頁面的時候。

如果我們的 userscript 想要「等」這些 framework 處理完後再開始跑,其中一種 workaround 是用 setTimeout() 等,但這樣很容易被 side effect 影響,像是電腦慢一點的時候還是會失敗,而如果 setTimeout() 時間拉太長體驗又不好:

setTimeout(() => {
    // ...
}, 1000);

比較好的方式是用 MutationObserver() 聽事件,在每次有新元素插入時判斷是否達成條件,處理完成後再停止聽事件 (避免持續影響效能):

let observer = new MutationObserver(() => {
    // ...
    // observer.disconnect();
});

observer.observe(document.documentElement, {
    attributes: false,
    childList: true,
    subtree: true,
});

有些 library 有把這段包起來,但看了使用方式覺得很複雜 (因為要支援比較多的情境),反而是自己把 MutationObserver() 的概念搞清楚後,用這幾行包起來還比較簡單...

Onion Service 第二版的退場計畫

Tor 這邊給出了 Onion Service v2 的退場計畫:「Onion Service version 2 deprecation timeline」,關於 v2 與 v3 的差異,可以參考之前寫的「下一代的 Tor Hidden Service」,裡面有提到 v3 的 spec。

v2 與 v3 最大的差異就是本來 v2 的 hostname 是 16 個英數字 (大約是 80-bit security),現在 v3 變成是 56 個英數字 (大約是 280-bit security),大幅降低 collision 的機會。

目前公佈的時間表是在 2020 年九月先拋警告出來,2021 年七月拔掉 server 支援,2021 年十月拔掉 client 支援:

1. September 15th, 2020
0.4.4.x: Tor will start warning onion service operators and clients that v2 is deprecated and will be obsolete in version 0.4.6.

2. July 15th, 2021
0.4.6.x: Tor will no longer support v2 and support will be removed from the code base.

3. October 15th, 2021
We will release new Tor client stable versions for all supported series that will disable v2.

差不多是十五個月的計畫...

Amazon SES 開東京區與新加坡區了...

Amazon SES 是 2011 年年初發表的服務,過了九年總算想起來這幾區也是需要 SES 的服務了...:「Amazon Simple Email Service is now available in the US East (Ohio), Asia Pacific (Singapore), Asia Pacific (Tokyo), and Asia Pacific (Seoul) Regions」。

這些年來大家應該都是用 us-west-2 或是 us-east-1 workaround 很久了,現在開這些區域主要還是讓 API 的整合會比較方便,如果本來就是透過 IAM user + username + password 的方式寄信的話就沒什麼差...

另外一種是寄比較大的信件 (產生的流量很大),這次這樣可以避免降低跨區而被收兩次流量費用,不過這應該是比較少見的情況...

AWS 宣佈提昇 Amazon EFS 的最低效率

AWS 宣佈提昇 Amazon EFS 的最低效率:「Amazon Elastic File System increases file system minimum throughput」。

第一段裡的幾個數字差不多就是重點了:

Amazon Elastic File System (Amazon EFS) file systems using the default bursting throughput mode now have a minimum throughput of 1 MiB/s. All EFS bursting mode file systems (regardless of size) can drive 100 MiB/s of throughput, and file systems with more than 1TiB of Standard class storage can drive 100 MiB/s per TB when burst credits are available. This change increases the minimum throughput from 50KiB/s per GiB of Standard class storage to a fixed minimum of 1 MiB/s for file systems with less than 20 GiB of Standard class storage, when burst credits are exhausted.

本來最低保證效率是每 GB 提供 50KB/sec,也就是要使用到 20GB 才會提供 1MB/sec,現在對於不到 20GB 的使用者,直接拉高到固定 1MB/sec。

這對於剛開始用的使用者會方便一些,不過 EFS 主要還是方便在不同機器上共享,效率上還是本機掛 EBS 好很多 (因為 OS 可以 cache)。

先前在 AWS 上把 /home 丟到 EFS 上面,結果因為 i/o 都需要透過網路的關係,編 pyenv 超慢,後來找一天把東西都丟回 EBS 上,速度快多了...

雞肋功能:AWS 推出 Managed Prefix Lists 管理 IP 列表

AWS 總算推出可以管理 IP 列表的功能 Managed Prefix Lists,就不需要自己在 security group 裡面針對一堆 IP 設重複的設定:「Amazon Virtual Private Cloud (VPC) customers can now use their own Prefix Lists to simplify the configuration of security groups and route tables」。

目前這個功能在大多數的區域都開放使用了:

There is no additional charge to use the Prefix Lists. Support for Prefix Lists is available in all public regions with support in Africa (Cape Town), Europe (Milan), China (Beijing), and China (Ningxia) coming soon. For more information on prefix lists, visit our public documentation.

但實際測試後發現在 web console 的操作上不算好用,主要是因為這個功能還是會受到「How do I increase my security group limits in Amazon VPC?」這邊提到的限制影響,如果沒有開 support ticket 調高限制,預設值是:

  • 每個 network interface 可以設定 5 個 security group。
  • 每個 security group 可以設定 60 條規則。

在建立 prefix list 時,需要設定「裡面會包含的最大數量」(可以到 1000),是一個你不知道為什麼要設定的東西,然後我就很開心設了 1000...

接下來開了一個純測試用的 security group (裡面是空的),結果這個 prefix list 掛不上去...

後來測了幾次後發現 prefix list 在 security 內不是吃一條 rule,而是直接照剛剛設定的「最大數量」去展開。

所以重新砍掉建一個新的 prefix list,改成 15 條後,就可以在 security group 上面掛四次 prefix list (不同的 port),剛好吃完 60 條規則,第五個設定就完全掛不上去... (無論是用 prefix list,或是設定 CIDR)

所以這些限制讓 prefix list 在 web console 上變得很不怎麼好用:

  • 一開始就要設計好 prefix list 內的最大筆數,如果不幸用完是沒辦法修改的。
  • 在 security group 裡不是吃一條規則,而是以最大筆數佔用,prefix list 內沒有射到最大筆數也還是得佔用。

但如果變成 Terraform 之類的工具用的話就還馬馬虎虎,因為你可以設計機制,改 prefix list 時可以開新的 prefix list (最大上限設成實際的數量,不會有浪費),然後再把 security group 裡面的 prefix list reference 換掉。

不過又想到,都已經用 Terraform 這種工具了,加上你又不是只佔一條規則,我就自己展開就好了啊... 不需要這個功能就能處理了。

「雞肋」XD

WebP 的檔案大小未必比 JPEG 小...

在「Is WebP really better than JPEG?」這邊發現在差不多的條件需求下,WebP 壓出來的檔案大小未必會比 JPEG 小。

先講結論:提供服務的人可以先確認自家的 JPEG 壓縮是不是有先用 MozJPEG (壓縮率更好),然後再考慮要不要支援 WebP。

Google 在推 WebP 這個格式的時候,宣稱失真壓縮的部份可以比 JPEG 小 25%~34%:(出自「A new image format for the Web」)

WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.

但作者發現 Google 之所以可以達到 25%~34% 這個數字,是因為比較的對象是 Independent JPEG Group 所釋出的 cjpeg,而如果拿 MozJPEG 相比的話應該得不到這個結果,另外也把 AV1 的 AVIF 拉進來一起測試了:

I think Google’s result of 25-34% smaller files is mostly caused by the fact that they compared their WebP encoder to the JPEG reference implementation, Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG encoder. I decided to run some tests to see how cjpeg, MozJPEG and WebP compare. I also tested the new AVIF format, based on the open AV1 video codec. AVIF support is already in Firefox behind a flag and should be coming soon to Chrome if this ticket is to be believed.

這邊作者測試用的圖集是 Kodak Lossless True Color Image Suite,測試的結果發現 WebP 的確比 libjpeg (cjpeg) 好一些,但沒有像 Google 講的那麼多 (這邊就不知道是不是現在的 libjpeg 又有改善),而 WebP 與 MozJPEG 相比的話就沒有明顯優勢了:

WebP seems to have about 10% better compression compared to libjpeg in most cases, except with 1500px images where the compression is about equal.

However, when compared to MozJPEG, WebP only performs better with small 500px images. With other image sizes the compression is equal or worse.

I think MozJPEG is the clear winner here with consistently about 10% better compression than libjpeg.

另外也提到了 AVIF 的壓縮率很好,不過要注意演算法會把非重點部位的細節吃掉:

I think AVIF is a really exciting development and compared to WebP it seems like a true next-generation codec with about 30% better compression ratio compared to libjpeg. Only concern I have is the excessive blurring of low detail areas. It remains to be seen if this can be improved when more advanced tooling becomes available.

對網頁的應用來說,WebP 另外一個痛點是在 Safari 上的支援度,在 caniuse.com 的「WebP image format」這邊可以看到目前各瀏覽器都支援了,就剩下 Safari 還不支援,所以目前在 iOS 上得降回 JPEG:

不過這點之後也改變了,在 iOS 14 beta 裡的 Safari 可以看到支援 WebP 了:「Safari 14 Beta Release Notes」。

Media
New Features
Added WebP image support.

所以這個狀況變得有點微妙了...

阻擋網站透過瀏覽器掃 localhost

五月的時候,DuckDuckGoCharlie Belmer 發了一篇關於網站透過瀏覽器掃 localhost 的文章,引起了不少重視:「Why is This Website Port Scanning me?」。

這個月陸陸續續看到一些反制方式了,比較簡單的是透過像 uBlock Origin 這類可以擋特定 url 的方式,像是 EasyPrivacy 裡面把一些大站台的 javascript script 擋下來:「uBlock Origin ad blocker now blocks port scans on most sites」。

在同一篇文章的 comment 處也有人提到 uBlock Origin 可以做的更廣泛:「Block access to 127.0.0.1/localhost and LAN address from the internet #4318」,裡面有人已經整理好丟出來了:「lan-block.txt」,看起來也可以擋一些...

要擋得比較完整的還得考慮 scan.example.com IN A 127.0.0.1 這種方式繞過去的情況?這可能需要用 extension 了...