Tag: root

Amazon EC2 AMI 的 root volume 可以直接抽換了

這個功能等了十年以上總算是出現了，Amazon EC2 的 AMI 總算是能直接抽換 root volume，不用先停掉機器：「Amazon EC2 enables easier patching of guest operating system and applications with Replace Root Volume」。

Starting today, Amazon EC2 supports the replacement of instance root volume using an updated AMI without requiring customers to stop their instance. This allows customers to easily update their applications and guest operating system, while retaining the instance store data, networking and IAM configuration.

算是 pre-container 時代會遇到的問題，後來大家都把 workaround 變成 practice 了：每次需要時候都是直接整包重新打包 (像是 Packer 這類的工具)，然後用工具更新 AMI id 改開新的機器，這樣就能夠避開需要先停掉現有機器的問題...

怎麼會突然想到要回來支援這個功能 XD

Amazon CA 在 renew 時將引入動態的 Intermediate CA

上個月 AWS 發的公告，其實已經生效了，但整理的時候才發現還沒寫：「Amazon introduces dynamic intermediate certificate authorities」。

先介紹一下 Amazon CA，這是 Amazon 自己維護的 Root CA，有走過 CA/Browser Forum 的規範與稽核，以及各家瀏覽器額外的要求，所以是個用戶端預設都有信任的 CA。

這個服務後來也被用在 AWS Certificate Manager (ACM) 上，由 ACM 申請到的憑證也都可以掛到 AWS 的各種服務上。

通常 root CA 的憑證不會直接拿來簽最終使用者使用的憑證 (leaf certificate)，而是 root CA 的憑證先簽 intermediate CA 的憑證，然後 intermediate CA 可能有好幾層一路簽下來，到最後面再用 intermediate CA 的憑證簽最終使用者使用的憑證。

這次公告的內容就題到了，之前的 intermediate CA 是一個固定範圍的量，而且會確保 renew 時用的 intermediate CA 跟先前的是相同的：

Before this change, Amazon maintained a limited number of intermediate CAs and issued and renewed certificates from the same intermediate CAs.

這次則是會變成動態：

With this change, leaf certificates issued to you will be signed by different intermediate CAs.

生效日期是這個月十一日，其實已經生效了：

Starting October 11, 2022 at 9:00 AM Pacific Time, public certificates obtained through ACM will be issued from one of the multiple intermediate CAs that Amazon manages.

一般的用戶端 (像是瀏覽器) 基本上應該是不會有問題，因為大多數預設都是信任 root CA，而非 intermediate CA，而這次的改變還是可以從 root CA 產生出對應的 trust chain。

官方有提到一個有可能的情況：如果你的應用程式有設定 certificate pinning 的話，應該是對 root CA 設定，而非對 intermediate CA 或是 leaf 做：

If you use intermediate CA information through certificate pinning, you will need to make changes and pin to an Amazon Trust Services root CA instead of an intermediate CA or leaf certificate.

這個也算通則，因為就 certificate pinning 想要做到的效果，對 root CA 做就就行了...

不使用 Google 服務的 Android 手機

一樣是在 Lobsters Daily 上翻到的，去 Google 服務的 Android 系統搞法：「Lineage with microG on a Sony XA2」。

主要是看關鍵字的部份，TWRP 換掉 recovery image，然後 LineageOS 是系統底，microG 是 open source 版本的 Google 專屬 API 的相容層，Magisk 則是負責 root 相關的事情，F-Droid 是 open source 軟體的 app store，可以用他來裝 Aurora Store，就可以裝 Play Store 裡的 app。

會這樣搞的人主要還是考慮到 privacy，可以預期有不少應用程式是不會動的...

FreeBSD 把 root 預設的 shell 改成 /bin/sh

在 Hacker News 首頁上看到 FreeBSD 把 root 的 shell 從 /bin/csh 換成 /bin/sh 了：「sh(1): make it the default shell for the root user」，Hacker News 上的討論也可以看一看：「FreeBSD switches the default root shell from csh to sh (freebsd.org)」。

依照說明是把 FreeBSD 的 /bin/sh 加上了不少東西，所以算是堪用了：

In the recent history sh(1) has gain the missing features for it to
become a usable interractive shell:
- command completion
- persistent history support
- improvements on the default bindings in emacs mode
- improvements in the vi mode (repect $EDITOR)
- print a newline when exiting via ^D
- default prompt and improvements on how PS1 can be configured
- and more.

This changes also simplifies making tiny freebsd images with only sh(1)
as a shell

以前也是用 csh 系列的 (像是 tcsh)，後來開始用 Linux 就往 Bash 與 Zsh 定居了...

DST Root CA X3 將在今天 22:01:15 過期

先前提到 Let's Encrypt 發出的憑證在 9/30 會產生問題，主因是 IdenTrust 的 DST Root CA X3 會在 9/30 過期，交叉簽名加上 OpenSSL 1.0.2 的判斷條件太嚴格導致的：「OpenSSL 1.0.2 與 Let's Encrypt 在這個月月底的相容性問題」。

本來以為是 UTC 的 2021/09/30 23:59:59 之類的時間，結果因為要面對這個問題，需要確認正確的時間，結果發現不是 UTC 的 2021/09/30 23:59:59，而是一個奇怪的時間：

Validity
    Not Before: Sep 30 21:12:19 2000 GMT
    Not After : Sep 30 14:01:15 2021 GMT

所以是 2021/09/30 22:01:15 (台灣時間) 會過期，今天晚上可以看一下情況...

OpenSSL 1.0.2 與 Let's Encrypt 在這個月月底的相容性問題

看到 OpenSSL 的官方居然特地寫一篇與 Let's Encrypt 的相容性問題：「Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2」。

這邊提到的 OpenSSL 1.0.2 很舊了 (在 Ubuntu 16.04 內是 1.0.2g)，理論上大多數的機器應該不太會遇到這個問題。

問題出自 Let's Encrypt 舊的 DST Root CA X3 將在這個月月底過期，這在 Let's Encrypt 的「DST Root CA X3 Expiration (September 2021)」這邊也有提到。

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30.

理想上只有要任何一條 trust chain 成立，就應該會把這個憑證認為是合法的憑證，但這在 OpenSSL 1.0.2 (以及之前的版本) 不是這樣設計。

舊版的設計是只要有任何一條過期的憑證，就會把憑證認為過期而失效：

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

OpenSSL 官方給了三個 workaround 可以做，另外我還有想到一個惡搞方式，是可以用其他家免費的憑證... 不過也是得測看看在 OpenSSL 1.0.2 下會不會動。

EC2 總算支援透過 Serial Console 操作了...

以往 Amazon EC2 的機器爛到開不起來時只能「看」到 Console 的輸出，然後要把 root volume 掛到其他機器上修正，接著再掛回來 (然後沒修好就要再重複...)，現在總算可以透過 EC2 Serial Console 來操作了：「Troubleshoot Boot and Networking Issues with New EC2 Serial Console」。

不過裡面有一些限制，首先機器必須是基於 AWS Nitro System，這個部份在「Amazon EC2 Instance Types」這邊可以翻到是不是 Nitro，比較新的 family type 應該都是 (像是 t3/t3a/t4g 都是 Nitro，但 t2 不是)：

EC2 Serial Console access is available for EC2 instances based on the AWS Nitro System. It supports all major Linux distributions, FreeBSD, NetBSD, Microsoft Windows, and VMWare.

另外是支援的區域目前只有幾個主力區域，不過公司在用的主力區 (新加坡) 也進去了，之後遇到問題的時候可以測試看看：

  • US East (N. Virginia), US West (Oregon), US East (Ohio)
  • Europe (Ireland), Europe (Frankfurt)
  • Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Singapore)

Twitter 上看到有些人有提到「總算啊...」之類的感想...

Chromium (Google Chrome) 修正 DNS 查詢問題後對 Root name servers 的壓力減輕不少

先前在「Chromium (Google Chrome) 實做對 Root DNS 的影響」這邊有提過 Chromium (以及 Google Chrome) 判斷所在的網路是不是有 NXDOMAIN hijack 的程式碼反而對 Root name servers 產生了巨大的 NXDOMAIN 流量。

因為上新聞所以才動了起來 (本來都沒什麼在動)，後來提供的方法是變成可以設定的選項，但預設是關閉的，這樣一來就可以改善 Root name servers 的壓力：「Add multi-state DNS interception policy - functionality piece.」。

而後在 Google Chrome 87 版進入 stable channel 後開始大幅緩解 (各平台分別在 2020/11/17 與 2020/11/18 釋出)，在繼續觀察幾個月後，上個禮拜 Verisign 的人在 APNIC 這邊更新了消息：「How Chromium reduced Root DNS traffic」。

這是去年八月時丟出來的資料，可以看到趨勢往上：

這是後續的資料，從 87 版釋出後開始往下：

另外我覺得比較好玩的是這個，在「Issue 1090985: Disable Intranet Redirect Detector by default」這邊看到這樣的說明：

看起來沒什麼問題，先 merge 再說... 是這樣玩嗎 XDDD

IdenTrust 願意再幫 Let's Encrypt 交叉簽三年

先前在「Let's Encrypt 在 Android 平台上遇到的問題」這邊提到了 IdenTrust 幫 Let's Encrypt 交叉簽名的有效日會在 2021 年的八月底左右到期，而這會導致比較舊的 Android 平台因為沒有內建 ISRG Root X1 這個憑證，造成 Let's Encrypt 簽出來的憑證在這些舊的 Android 裝置上都認不出來。

文章出來過了一個多月後，剛剛看到 Let's Encrypt 發佈消息，IdenTrust 願意再交叉簽名三年：「Extending Android Device Compatibility for Let's Encrypt Certificates」，當時猜測發文是要讓 IdenTrust 表態，看起來目的達成了...

話說中間跑出來的「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」不知道後續會怎麼樣，之後可以看看 Certificate Transparency 的資料來看看到底有多少人用...

ZeroSSL 也提供免費的 SSL Certificate (DV) 了

在 Facebook 上被朋友敲可以測 ZeroSSL，另外一個透過 ACME 協定提供免費的 SSL Certificate，不過目前只有支援單一網域名稱 (DV)：「Another free CA as an alternative to Let's Encrypt (scotthelme.co.uk)」。

我先前就有在測 ZeroSSL，不過驗證一直過不去，當時有在 Twitter 上找 ZeroSSL 帳號問，但 ZeroSSL 的人說 ACME 的部份不在客服範圍，就先丟著...

剛剛發現是自己耍笨了，原因是 nginx 沒設好造成驗證卡住，一改好後就正常了。

用 SSL Labs 的 SSL Server Test 翻了一下，他的 Root CA 看起來歷史更久，應該是有機會解決 Let's Encrypt 明年會產生的 Root CA 憑證信任問題，也就是先前在「Let's Encrypt 在 Android 平台上遇到的問題」提到的問題，在 Hacker News 上的討論也可以看到有人提到這點：

Good to know, and I'm glad there's an alternative to Let's Encrypt, just in case. Is ZeroSSL trusted by old Android devices? If so, that might be a work-around for Let's Encrypt's cross-signing from IdenTrust expiring.

不過也有些人有疑慮，畢竟提供這個服務後面的公司幹過不少壞事：

If zerossl is reselling/a subsidiary of sectigo, that’s enough reason to never use this.
Sectigo is the new name for Comodo. The same bunch of pricks who tried to trademark “Let’s Encrypt”.

Other players in the acme cert “business” is great. Renaming a slime ball name and carrying on like nothing happened is not ok.

但看起來至少是多了一個選擇...