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

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 + 六碼動態數字)。

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

Let's Encrypt 在檢查 CAA 時出包

Let's Encrypt 發現在檢查 CAA 的程式碼有問題,發了說明:「2020.02.29 CAA Rechecking Bug」,以及預定的處理方式:「Revoking certain certificates on March 4」。

問題是當一個 certificate request 包含了 N 個 domain 時,本來的 CAA 檢查應該要對這 N 個檢查,但程式寫成只會抓一個,然後檢查了 N 次:

The bug: when a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.

2020/02/29 發現的,就程式碼的部屬時間,發現應該從去年 2019/07/25 開始就有這個 bug:

We confirmed the bug at 2020-02-29 03:08 UTC, and halted issuance at 03:10. We deployed a fix at 05:22 UTC and then re-enabled issuance.

Our preliminary investigation suggests the bug was introduced on 2019-07-25. We will conduct a more detailed investigation and provide a postmortem when it is complete.

然後決定要 revoke 這些可能會有問題的 SSL certificate,大約佔現有還有效的 SSL certificate 的 2.6%,大約三百萬筆:

Q: How many certificates are affected?
A: 2.6%. That is 3,048,289 currently-valid certificates are affected, out of ~116 million overall active Let’s Encrypt certificates. Of the affected certificates, about 1 million are duplicates of other affected certificates, in the sense of covering the same set of domain names.

在「Check whether a host's certificate needs replacement」這邊可以偵測線上使用的 SSL certificate 是否受到影響。

另外在「Download affected certificate serials for 2020.02.29 CAA Rechecking Incident」這邊可以抓到所有受到影響,預定要 revoke 的 SSL certificate 的序號。關於取得序號的方式,官方也有提供 CLI 的指令可以操作確認,對於有很多網域名稱需要確認的人可以用這組指令編寫程式判斷:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial\ Number | tr -d :

照目前的描述,如果申請時只有一個 domain 應該是不會中這個問題,再來是最壞的情況大概會維持三個月 (網站主人沒管他,等到時間到了自動 renew)。

Safari 將會禁止長效憑證 (超過 398 天,大約十三個月)

在「Apple drops a bomb on long-life HTTPS certificates: Safari to snub new security certs valid for more than 13 months」這邊看到的,這次是 Safari 直接發難要幹掉長效憑證。

今年九月前發的憑證是照既有的協議,最長長度是 825 天 (大約 27 個月),但九月開始發的憑證,如果有效長度超過 398 天就會直接被 Safari 視為無效,所以大約是砍半,其他家瀏覽器不知道會不會跟進...

最早的時候可以直接買五年 (有印像是因為當年的 group.nctu.edu.tw 是我自己買的),後來好像降到三年,最近是兩年,看起來要變成一年了...

AWS 提供程式,可以掃出有哪些 RDS 的憑證需要更新

先前在「AWS 的 CA 更新 (CA-2019),將會影響與資料庫相關的服務」這邊提到了 AWSRDS 因為 Root Certificate 快要過期,需要更新到 CA-2019。

剛剛在 Twitter 上看到 Jeff Barr 提到了一個可以直接列出有哪些機器需要更新的工具:

程式放在 GitHub 上的 aws-samples/rds-ssl-update,另外看到一個有趣的授權條款,叫做 MIT-0 License,是 AWS 自己改的一個授權版本,拿掉了 MIT License 裡面的這段:

subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

也就是要求要引用授權條款的部份被拿掉,不過我還是比較喜歡 BSD license,尤其是 3-clause 的版本...

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 的網域...

省頻寬的方法:終極版本...

看到「Three ways to reduce the costs of your HTTP(S) API on AWS」這邊介紹在 AWS 上省頻寬費用的方法,看了只能一直笑 XD

第一個是降低 HTTP response 裡沒有用到的 header,因為每天有五十億個 HTTP request,所以只要省 1byte 就是省下 USD$0.25/day:

Since we would send this five billion times per day, every byte we could shave off would save five gigabytes of outgoing data, for a saving of 25 cents per day per byte removed.

然後調了一些參數後省下 USD$1,500/month:

Sending 109 bytes instead of 333 means saving $56 per day, or a bit over $1,500 per month.

第二個是想辦法在 TLS 這邊下手,一開始其中一個方向是利用 TLS session resumption 降低第二次連線的成本,但他們發現沒有什麼參數可以調整:

One thing that reduces handshake transfer size is TLS session resumption. Basically, when a client connects to the service for the second time, it can ask the server to resume the previous TLS session instead of starting a new one, meaning that it doesn’t have to send the certificate again. By looking at access logs, we found that 11% of requests were using a reused TLS session. However, we have a very diverse set of clients that we don’t have much control over, and we also couldn’t find any settings for the AWS Application Load Balancer for session cache size or similar, so there isn’t really anything we can do to affect this.

所以改成把 idle 時間拉長 (避免重新連線):

That leaves reducing the number of handshakes required by reducing the number of connections that the clients need to establish. The default setting for AWS load balancers is to close idle connections after 60 seconds, but it seems to be beneficial to raise this to 10 minutes. This reduced data transfer costs by an additional 8%.

再來是 AWS 本身發的 SSL certification 太肥,所以他們換成 DigiCert 發的,大幅降低憑證本身的大小,反而省下 USD$200/day:

So given that the clients establish approximately two billion connections per day, we’d expect to save four terabytes of outgoing data every day. The actual savings were closer to three terabytes, but this still reduced data transfer costs for a typical day by almost $200.

這些方法真的是頗有趣的 XDDD

不過這些方法也是在想辦法壓榨降低與 client 之間的傳輸量啦,比起成本來說反而是提昇網路反應速度...

讓 pfSense 的管理界面接上 Let's Encrypt

其實網路上有一些教學,但大多數的作法都是把 port 80 空出來跑認證用的 HTTP 伺服器,而我這邊的作法是希望維持 nginx,用 webroot local folder 的方式認證。

pfSense 上先安裝 acme 套件,然後先用 Create new account key 產生出自己的金鑰:

然後選擇申請 Let's Encrypt Production ACME V2 的帳號:

接著填一下 Name 的部份,按下 Register ACME account key 註冊後就可以按下 Save 存進系統。

然後就是拿這個帳號申請網域名稱,重點在於,如果選擇 webroot local folder 時,需要填寫對應的 RootFolder 參數 (這塊做得很怪,沒有預設值 XD):

然後按下 Save 後存起來,回到頁面上就可以按 Issue/Renew 申請了,申請成功以後就可以到最上方 tab 的 System,在裡面的 Advanced 就可以改 HTTPS 管理界面使用的憑證,改好後把瀏覽器關掉重開就可以確認是不是有設定好...

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」。

AWS ACM 支援 Private CA

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 服務的關係,上面可以看到相關的記錄,相較於以前的作法安全不少。