Let's Encrypt 生了新的 Root 與 Intermediate Certificate

Let's Encrypt 弄了新的 Root Certificate 與 Intermediate Certificate:「Let's Encrypt's New Root and Intermediate Certificates」。

一方面是本來的 Intermediate Certificate 也快要要過期了,另外一方面是要利用 ECDSA 降低傳輸時的頻寬成本:

On Thursday, September 3rd, 2020, Let’s Encrypt issued six new certificates: one root, four intermediates, and one cross-sign. These new certificates are part of our larger plan to improve privacy on the web, by making ECDSA end-entity certificates widely available, and by making certificates smaller.

本來有 Let's Encrypt Authority {X1,X2,X3,X4} 四組 Intermediate Certificate,都是 RSA 2048 bits。

其中 X1 與 X2 差不多都到期了 (cross-signed 的已經過了,自家 ISRG Root X1 簽的剩不到一個月),不過這兩組已經沒在用了,這次就不管他了。

而 X3 與 X4 這兩組則是明年到期,會產生出新的 Intermediate Certificate,會叫做 R3 與 R4,跟之前一樣會被自家 ISRG Root X1 簽,以及 IdenTrust DST Root CA X3 簽:

For starters, we’ve issued two new 2048-bit RSA intermediates which we’re calling R3 and R4. These are both issued by ISRG Root X1, and have 5-year lifetimes. They will also be cross-signed by IdenTrust. They’re basically direct replacements for our current X3 and X4, which are expiring in a year. We expect to switch our primary issuance pipeline to use R3 later this year, which won’t have any real effect on issuance or renewal.

然後是本次的重頭戲,會弄出一個新的 Root Certificate,叫做 ISRG Root X2,以及兩個 Intermediate Certificate,叫做 E1 與 E2:

The other new certificates are more interesting. First up, we have the new ISRG Root X2, which has an ECDSA P-384 key instead of RSA, and is valid until 2040. Issued from that, we have two new intermediates, E1 and E2, which are both also ECDSA and are valid for 5 years.

主要的目的就是降低 TLS 連線時的 bandwidth,這次的設計預期可以降低將近 400 bytes:

While a 2048-bit RSA public key is about 256 bytes long, an ECDSA P-384 public key is only about 48 bytes. Similarly, the RSA signature will be another 256 bytes, while the ECDSA signature will only be 96 bytes. Factoring in some additional overhead, that’s a savings of nearly 400 bytes per certificate. Multiply that by how many certificates are in your chain, and how many connections you get in a day, and the bandwidth savings add up fast.

另外一個特別的修改是把名字改短 (把「Let's Encrypt Authority」拿掉),也是為了省傳輸的成本:

As an aside: since we’re concerned about certificate sizes, we’ve also taken a few other measures to save bytes in our new certificates. We’ve shortened their Subject Common Names from “Let’s Encrypt Authority X3” to just “R3”, relying on the previously-redundant Organization Name field to supply the words “Let’s Encrypt”. We’ve shortened their Authority Information Access Issuer and CRL Distribution Point URLs, and we’ve dropped their CPS and OCSP urls entirely. All of this adds up to another approximately 120 bytes of savings without making any substantive change to the useful information in the certificate.

這個部份讓我想到之前寫的「省頻寬的方法:終極版本...」這篇,裡面提到 AWS 自家的 SSL Certificate 太胖,改用 DigiCert 的反而可以省下不少錢 XDDD

另外也提到了這次 cross-sign 的部份是對 ECDSA Root Certificate 簽 (ISRG Root X2),而不是對 ECDSA Intermediate Certificate 簽 (E1 與 E2),主因是不希望多一次切換的轉移期:

In the end, we decided that providing the option of all-ECDSA chains was more important, and so opted to go with the first option, and cross-sign the ISRG Root X2 itself.

這算是蠻重要的進展,看起來各家 client 最近應該都會推出新版支援。

OpenSSH 的三個進階用法:CA 架構、透過 Jump Server 連線、2FA

在「How to SSH Properly」這篇裡面講了三個 OpenSSH 的進階用法:CA 架構、透過 Jump Server 連線,以及 2FA 的設定。

之前蠻常看到使用 -o StrictHostKeyChecking=off 關閉檢查,但 OpenSSH 有支援 CA 架構,可以先產生出 Root CA,然後對 Host 的 Public Key 簽名,在連線的時候就可以確保連線沒有被調包 (通常是 MITM),但得設計一套機制,自動化機器生出來後的步驟。

另外一個可能的方式是 SSHFP,搭配 DNSSEC 也可以確認連線沒有被調包,不過這又牽扯到 DNS 的部份...

第二個提到的是 Jump Server (Bastion host),之前的作法是用 -A 把 authentication agent 帶過去再連進去,這邊則是教你怎麼下指令直接連線,而不需要先連到 Jump Server (但實際上底層是透過 Jump Server)。

第三個是 2FA,對於還是使用密碼登入的系統可以多一層保護。文章裡面講的是 TOTP 的方式 (就是現在還蠻常見的 app + 六碼動態數字)。

先知道有這些東西,之後真的有用到的場景時再回來看...

AWS 的 CA 更新 (CA-2019),將會影響與資料庫相關的服務

AWS 要開始使用新的 CA 發各種資料庫相關服務的 SSL endpoint (包括 RDSAuroraDocumentDB),看一下差不多是十多天前的消息,不知道為什麼突然發個緊急通告:「Urgent & Important – Rotate Your Amazon RDS, Aurora, and Amazon DocumentDB (with MongoDB compatibility) Certificates」。

本來的 CA 是 CA-2015,將在 2020 年到期:

March 5, 2020 – The CA-2015 certificates will expire. Applications that use certificate validation but have not been updated will lose connectivity.

所以會有裡面提到的事項要處理,其中前幾天讓新的 CA-2019 變成新機器的預設值,但如果有需要,還是可以選舊的:

January 14, 2020 – Instances created on or after this date will have the new (CA-2019) certificates. You can temporarily revert to the old certificates if necessary.

可以把 https://s3.amazonaws.com/rds-downloads/rds-ca-2019-root.pem 拉下來用 openssl x509 -text -in rds-ca-2019-root.pem 看,另外把網址裡的 2019 改成 2015 也可以拉到舊版的。

不過看起來沒有用 X.509 Name Constraints 限制在只有自家 RDS 的網域...

Cloudflare 提供 Certificate Transparency 的通知服務

Cloudflare 推出了 Certificate Transparency 的通知服務,當有任何新的 SSL certificate 發出時就會通知:「Introducing Certificate Transparency Monitoring」。

基本上就是一組 crawler 去各家記錄挖資料回來:

Business 與 Enterprise 版本的可以設定要通知誰,Free 與 Pro 版本則是固定會通知網域的擁有人 (這邊指的是 Cloudflare 上的):

If you’re on a Business or Enterprise plan, you can tell us who to notify. Instead of emailing the zone owner (which we do for Free and Pro customers), we accept up to 10 email addresses as alert recipients. We do this to avoid overwhelming large teams.

剛剛把掛在上面的 domain 都開起來了,這樣在 Let's Encrypt 自動 renew 的時候應該會收到通知...

另外一個同名的工具則是 2016 年底時 Facebook 推出的 (需要登入才能使用),可以搜尋有哪些 domain:「Certificate Transparency Monitoring」。

Let's Encrypt 從七月開始將會改用自己的 Root 簽發憑證

Let's Encrypt 宣佈了以後的憑證的簽發計畫:「Transitioning to ISRG's Root」。

主要的改變是 2019/07/08 之後提供的 intermediate CA 會改變,從現在的 cross-sign 變成只有自己的 Root CA:

On July 8, 2019, we will change the default intermediate certificate we provide via ACME. Most subscribers don’t need to do anything. Subscribers who support very old TLS/SSL clients may want to manually configure the older intermediate to increase backwards compatibility.

目前的簽發用的兩個中介憑證 (Let's Encrypt Authority X3Let's Encrypt Authority X4) 是由 Let's Encrypt 自己的 ISRG Root X1IdenTrustDST Root CA X3 所 共同簽署的:

這是因為 IdenTrust 的 DST Root CA X3 憑證很久前就被各家瀏覽器信任 (像是 Mozilla 的「Request to add two additional IdenTrust root CA certificates」這篇,可以看到 2007 年就被放進去了),而 Let's Encrypt 當時為了更快把可用的產品推出,所以跟 IdenTrust 合作,採用 cross sign 的方式讓 Let's Encrypt 簽出來的憑證被一般瀏覽器與函式庫所信任。

現在差不多過了三年半,Let's Encrypt 成為目前世界上最大的 SSL Certificate 發放單位,加上自己的 Root CA (ISRG Root X1) 也都差不多被整合進各家系統內了,所以打算要獨立自己簽了。

不過系統上可以設定,使用者如果有遇到相容性問題 (太舊的系統可能還是不包含 Let's Encrypt 自家的 ISRG Root X1),還是可以設定使用有 cross-sign 的版本 (維持現狀)。與 IdenTrust 的 cross-sign 會維持到 2021 年九月,大約再兩年多一些:

Our current cross-signature from IdenTrust expires on March 17, 2021. The IdenTrust root that we are cross-signed from expires on September 30, 2021. Within the next year we will obtain a new cross-signature that is valid until September 29, 2021. This means that our subscribers will have the option to manually configure a certificate chain that uses IdenTrust until September 29, 2021.

對於自用來說應該沒什麼大影響,主要是企業用戶要注意相容性...

CA/Browser Forum 上的會議記錄:關於密碼與 2FA 的強制要求

CA/Browser Forum 會定時將會議記錄與最後的結論公開放在網站上,有時候有些資訊還蠻有趣的。像是前幾天在「Ballot 221 - Two-Factor Authentication and Password Improvements - CAB Forum」這邊看到 CA/Browser Forum 的成員對密碼與 2FA 提出了修正提案,其中瀏覽器端只有 Microsoft 參與投票,但是被否決了...

不知道否決的原因,但是大概可以猜到幾個點。

第一個是提案提到了 NSANIST 800-63B Appendix A,這個單位不太受歡迎啊...

第二個則是「For accounts that are accessible only within Secure Zones or High Security Zones, require that passwords have at least twelve (12) characters;」這段強迫使用密碼,而現在有比密碼更安全的方案存在 (以 public key cryptography 為認證基礎的方案),像是早期的 U2F 以及今年定案的 WebAuthn

應該是這些原因吧...

TWCA 不在 Java Trust Store 裡...

SSL Labs 上翻資料的時候發現看到台灣有些網站的 SSL 憑證在 Java Trust Store 內是不會取得信任授權的,但其他的都支援,像是這樣:

翻了幾個後發現都是 TWCA 的,在其他家都是這樣授權出來的 (Mozilla/Apple/Android/Windows):(TWCA Root Certification Authority -> ) TWCA Global Root CA -> TWCA Secure SSL Certification Authority -> Final,也就是 TWCA 的兩個 Root CA 都在 trust store 內,走任何一條授權都可以拉出來。

印象中之前應該都是支援的... 先前是 cross sign 嗎?@_@

StartCom 決定關門

Hacker News 上看到 StartCom 決定關門的消息:「Termination of the certificates business of Startcom」。

2018 停發新的憑證,然後維護兩年 CRLOCSP 服務:

We´ll set January 1st 2018 as the termination date and will stop issuing certificates therefrom. We will maintain our CRL and OCSP service for two more years from January 1st 2018. The three pairs of StartCom key Roots will be eliminated after that time.

在不斷的抵制下總算關了...

IE 與 Edge 推出更新,阻擋 SHA-1 憑證

微軟這幾天推出更新,IEEdge 將不會接受 SHA-1 憑證:「Microsoft Makes it Official, Cuts off SHA-1 Support in IE, Edge」。微軟的公告則是在「Deprecation of SHA-1 for SSL/TLS Certificates in Microsoft Edge and Internet Explorer 11」這邊。

根憑證不受影響 (所以企業自己產生的 Root CA 也不受影響):

Beginning May 9, 2017, Microsoft released updates to Microsoft Edge and Internet Explorer 11 to block sites that are protected with a SHA-1 certificate from loading and to display an invalid certificate warning. This change will only impact SHA-1 certificates that chain to a root in the Microsoft Trusted Root Program where the end-entity certificate or the issuing intermediate uses SHA-1. Enterprise or self-signed SHA-1 certificates will not be impacted, although we recommend that all customers quickly migrate to SHA-2 based certificates.

Google Chrome 也宣佈不信任 WoSign + StartCom 的計畫

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 還是沒動作外,其他比較大的瀏覽器都到齊了...