幹壞事是進步最大的原動力
Hacker News 上看到 ACM 宣佈停止發行紙本：「Ceasing print publication of ACM journals and transactions (acm.org)」，原公告在「Ceasing Print Publication of ACM Journals and Transactions」。
從 2024 年一月開始停止紙本版本的發行，除了列出來的例外：
ACM has made the decision to cease print publication for ACM’s journals and transactions as of January 2024. The magazines Communications of the ACM, ACM InRoads, interactions, and XRDS: Crossroads will continue in print.
一方面降低成本，而替代方案就是有需要的人可以自己印，挑自己習慣的方式閱讀...
上個月 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 做就就行了...
AWS 宣佈 AWS KMS 與 AWS ACM 支援 post-quantum TLS ciphers：「AWS KMS and ACM now support the latest hybrid post-quantum TLS ciphers」。
全區支援 Kyber、BIKE 與 SIKE 這三個演算法：
The three PQC key encapsulation mechanisms (KEMs) offered are Kyber, BIKE, and SIKE. Hybrid post-quantum TLS combines a classical key agreement, such as ECDHE, with one of these KEMs. The result is that your TLS connections inherit the security properties of both the classical and post-quantum key exchanges.
Hybrid post-quantum TLS for AWS KMS and ACM is available in all public AWS Regions.
不過這是 NIST Post-Quantum Cryptography Standardization 裡 Round 3 裡面其中幾個演算法而已：
AWS Key Management Service (KMS) and AWS Certificate Manager (ACM) now support hybrid post-quantum key establishment for transport layer security (SSL/TLS) connections using the latest post-quantum ciphers from Round 3 of the NIST Post-Quantum Cryptography (PQC) selection process.
順便補一下隔壁棚 Cloudflare 的研究：「Making protocols post-quantum」。
今年的 AWS Summit Taiwan 2021 是線上的形式，早在前一個月前就先預錄好，但開始的時候就忘記要宣傳一下了... 結果是在找資料的時候發現其他人有提到：「AWS實作紀錄 #2：高可用性保管服務 (2021 AWS Summit Taiwan)」。
投影片與影片如果有興趣的人可以去 AWS 活動頁面上看，或者上面提到的那篇。
這次講的主題是想要在雲端上面搭建 Vault，但又不希望自己搞一堆 High Availability 的架構，最好是雲端服務本身就有提供... 而既然是在 AWS 的場子，主要都還是以 AWS 的服務來搭建。
在這次的設計裡，Vault 的資料是放在 DynamoDB 上，然後透過 KMS 管理加密用的，這兩個服務本身都有 High Availability，所以直接用就可以了。
接下來是跑 Vault 程式的部份，這部份得自己處理 High Availability 的架構，我是用兩台很小台的 EC2 instance (t4g.nano) 在跑，這邊也可以換成 ECS 或是 EKS 的 container。
接下來把這兩台 EC2 instance 掛起來的也都是 High Availability 服務：在 EC2 instance 前面用 ELB 擋住提供 HTTP API 服務，另外這邊即使是內部用，也可以上 HTTPS (透過 ACM 掛上 HTTPS 的憑證)。
在 ELB 上看到只有一台機器活著是正常的，因為兩台機器之間是 active-standby 架構，同時間只會有一台機器在運作，而 lock 的機制是 Vault 透過 DynamoDB 實做的，不需要另外處理。
其實裡面大多數的元件都可以抽換，像是 DynamoDB 也可以用其他的服務來當儲存層，馬上可以想到的是 RDS 的 MySQL 或是 PostgreSQL。
概念上不算困難，所以投影片上主要就是給設定檔，這樣方便大家抄，不用在自己摸指令摸半天...
AWS ACM 推出了 Private CA 服務：「How to host and manage an entire private certificate infrastructure in AWS」。
以前需要 Private CA 的話，會找個地方丟 Root CA 的 key，然後有權限的人可以連到那台機器上跑 OpenSSL 指令生出對應的 SSL certificate，現在 AWS 則是利用 HSM 架構提供服務：
主要是因為 HSM 的關係，安全性會比較好... 另外也因為是 AWS 服務的關係，上面可以看到相關的記錄，相較於以前的作法安全不少。
大概猜得到原因，總算是把這塊做下去了...
AWS 宣佈 CloudFront 增加自訂網域名稱需要先過認證才能啟用：「Amazon CloudFront enhances the security for adding alternate domain names to a distribution」，也就是把自己的 domain name 掛到 CloudFront 上需要先認證過。
這邊的認證需要用公開被信任的 SSL Certificate，而大多數人應該會直接拿 AWS 提供的 ACM 來用：
With this change, when you add an alternate domain name using the AWS Management Console or the CloudFront API, you will now need to attach a certificate to the distribution to confirm that you have authorized rights to use the alternate domain name. The certificate must be valid and come from a publicly trusted Certificate Authority like AWS Certificate Manager which provides public SSL/TLS certificates for free.
申請 ACM 也需要確認身分，印象中沒記錯的話是透過 DNS 或是 e-mail 認證。
會有這個改變是因為有一個 DDoS 的攻擊手法可以「造成困擾」。在沒有認證就可以增加網域名稱的情況下 (假設是 assets.gslin.com)，AWS 需要把不同帳號設定同一組 domain name (assets.gslin.com) 的 IP address 分開，這樣才能確保安全性。而 IPv4 address 是有限的，用很多帳號申請就有機會讓真正的 assets.gslin.com 擁有人想要用的時候沒有資源可以用。
其實在 Route53 也有類似的問題，但因為是個雞生蛋蛋生雞的問題，就更不好解決了，在 DNS 還沒設定好之前要怎麼確認身分是一個更頭痛的問題... e-mail 認證可能是一個方法，但流程上就多了不少步驟。
AWS Certificate Manager 推出了 Private CA，讓使用者可以在不接觸到 CA 的 Private Key 就可以操作 CA 行為：「AWS Certificate Manager Launches Private Certificate Authority」。
支援的演算法除了標準的 RSA 外，還包括了 ECC 的 (雖然是 NIST 的 P-256 與 P-384)：
然後直接內建了 CRL 服務，透過 Amazon S3 做：
要注意的是價錢有點奇怪：
Private CAs cost $400 per month (prorated) for each private CA. You are not charged for certificates created and maintained in ACM but you are charged for certificates where you have access to the private key (exported or created outside of ACM). The pricing per certificate is tiered starting at $0.75 per certificate for the first 1000 certificates and going down to $0.001 per certificate after 10,000 certificates.
中間省掉 1k 到 10k 是 USD$0.35/cert (可以在 pricing 頁面看到)。
不管如何，這計價模式有點怪怪的... 收了固定的費用，每個 certificate 的費用要到 USD$0.75，這看不太懂。另外是 10k 後的單價明顯與前面比例不太合。
看起來像是跟某個 partner 合作談出來奇怪的 pricing model，但也不知道是哪家... :o
Amazon Lightsail 推出了 Block Storage (11/14) 與 Load Balancer (11/29)：「Introducing additional block storage for Amazon Lightsail」、「Amazon Lightsail adds load balancers with integrated certificate management」。
兩個是不同時間點發表的，當時懶的寫所以這次一起寫...
Block Storage 有不少 VPS 都有提供了，像是 Linode 的「Linode Block Storage (Fremont beta)」(雖然還在 beta)、DigitalOcean 的「Storage on DigitalOcean | Highly available Block Storage」以及 Vultr 的「High Performance and Cheap Block Storage - Vultr.com」。
AWS 算是很早就有這個服務 (Amazon EBS)，這邊應該只是把系統整合進來...
另外一個是這幾天推出的 Load Balancer，目前應該只有 Linode 的「Ensure High-Availability with NodeBalancers - Linode」比較知名。AWS 上的 ELB 有不少選擇可以用 (ELB Classic、ALB 以及 NLB)，不過公告裡沒特別提到... 比較特別的是提供免費的 SSL Certificate 吧？這在其他家主要得靠 Let's Encrypt 來做，在 AWS 上應該是整合了 ACM？
AWS Certificate Manager (ACM) 可以用 DNS 的方式認證了：「Easier Certificate Validation Using DNS with AWS Certificate Manager」。
不過這不同於 Let's Encrypt 在推的 dns-01，而是 AWS 自己定義的方式：
然後文章後面又再次提醒了一次，如果要用在 Amazon CloudFront，必須使用 us-east-1 的 ACM：
Note that your certificate must be in the US East (N. Virginia) Region to use the certificate with CloudFront.
這個方式讓自動化更容易做... 以前需要收信確認，雖然也是可以寫程式硬幹，但就得冒著 AWS 改版造成程式失效的風險。
今年的 Turing Award 頒給了 Tim Berners-Lee：
For inventing the World Wide Web, the first web browser, and the fundamental protocols and algorithms allowing the Web to scale.
終於啊...