Let's Encrypt 更新了 ToS

在「Let's Encrypt’s subscriber agreement changes on Sept 21 (letsencrypt.org)」這邊看到的,Let's Encrypt 有提供 diff 的內容,在「LE-SA-v1.2-v1.3-diff.docx」這邊,你也可以用 Google Docs Viewer 看:「LE-SA-v1.2-v1.3-diff.docx」。

看起來主要是用語上的改變 (可能是律師的建議?),除了 revoke 的章節外看起來沒什麼大變化。而 revoke 的章節部份增加了這兩段文字:

You warrant to ISRG and the public-at-large, and You agree, that before providing a reason for revoking Your Certificate, you will have reviewed the revocation guidelines found in the “Revoking Certificates” section of the Let’s Encrypt documentation available at https://letsencrypt.org/docs/ , and that you will provide Your corresponding revocation reason code with awareness of such guidelines.

You acknowledge and accept that ISRG may modify any revocation reason code provided by You if ISRG determines, in its sole discretion, that a different reason code for revocation is more appropriate or is required by industry standards.

不確定自動化的 client 需不需要重新再 accept 一次?

Let's Encrypt 撤銷了兩百萬個以 tls-alpn-01 驗證的憑證

前幾天 Let's Encrypt 決定撤銷大約兩百萬個以 tls-alpn-01 簽發的憑證:「2022.01.25 Issue with TLS-ALPN-01 Validation Method」,在 Hacker News 上的討論「Issue with TLS-ALPN-01 Validation Method (letsencrypt.org)」也可以翻一下。

這次主要是有兩個修改,第一個是要 TLSv1.2 以上,不支援舊版的 TLS 驗證:

First, we now guarantee that our client which reaches out to conduct the “acme-tls/1” handshake will negotiate TLS version 1.2 or higher. If your ACME client or integration only supports a maximum TLS version of 1.1 when conducting the TLS-ALPN-01 challenge, it will break. We are not aware of any ACME clients with this limitation.

另外一個是淘汰掉 legacy OID:

Second, we no longer support the legacy 1.3.6.1.5.5.7.1.30.1 OID which was used to identify the acmeIdentifier extension in earlier drafts of RFC 8737. We now only accept the standardized OID 1.3.6.1.5.5.7.1.31. If your client uses the wrong OID when constructing the certificate used for the TLS-ALPN-01 handshake, it will break. Please either update your client, or switch to using a different validation method.

目前還是以 http-01 與 dns-01 為主,暫時不用管,但如果有人用 tls-alpn-01 的稍微注意一下吧...

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

Firefox 支援 OCSP Must-Staple

Firefox 宣佈支援 OCSP Must-Staple:「Improving Revocation: OCSP Must-Staple and Short-lived Certificates」。

先前的 SSL certificate 的 revoke 技術目前是透過 CRLOCSP 兩個技術在支撐,前者是列出所有被 revoke 的清單,後者則是瀏覽器主動去指定的 server 確認這個 SSL certificate 是否有效。但這兩個方法都有嚴重的問題。

CRL 的問題是 revoke 清單會愈來愈多。這完全沒辦法 scale。

OCSP 的問題有幾個,一個是熱門網站的 SSL certificate 會讓 OCSP server 的負擔非常重 (不過還是有些辦法打散)。第二個問題是 OCSP server 會知道哪些 IP 造訪了哪些網站,使得隱私權受到嚴重侵害。第三個問題則是 client 需要再連線確認花掉很多時間,而且失敗機率超高:

However, these checks can be slow and unreliable. They time out about 15% of the time, and take about 350ms even when they succeed.

也因為極度不穩定,對於一般的 SSL certificate 在連不到 OCSP server 時,沒有瀏覽器敢直接 hard-fail (EV SSL certificate 是強制要求 OCSP 要過),於是反而給了攻擊者一個很簡單的方法:取得 private key 攻擊時順便擋掉對 OCSP server 的連線。

後來 OCSP 技術改善而推出 OCSP stapling,由 server 定時去 OCSP server 取得「這個 SSL certificate 未被 revoke」的簽名認證後,一起在 TLS connection 裡傳輸給 client 端,這樣有許多好處:

  • 隱私問題直接解決了,因為 server 是固定時間去抓,OCSP server 完全不知道使用者端的資訊 (甚至連「有沒有來連線」都不知道)。
  • 穩定性提昇了,因為 OCSP server 的負荷量變低,可以預期 OCSP server 會變得比較容易 scale。
  • 用戶端的速度增加了,因為 client 不需要額外的連線確認。

而這次 Firefox 更進一步支援讓 SSL certificate 上標注 OCSP Must-Staple,表示這個 certificate 必須有 OCSP stapling 才行,這使得這類 SSL certificate 在 revoke 後無法被利用,真正的完全失效。

不知道其他家會不會跟進...

D-Link 的 open source package 內包含了拿來簽名用的 Private Key

D-LinkDCS-5020L 的 open source package (因 GPL 要求) 裡放了簽名用的 private key:「D-Link spilled its private key onto the web – letting malware dress up as Windows apps」。

而這把 key 由 Verisign 所簽,因此被 Windows 所信任,所以這把 key 可以用來簽 malware:

而不幸的是,這把 key 已經洩漏出來超過半年了:

The D-Link key was leaked in late February, and expired on September 3, it appears.

又是一連串的 revoke 過程... orz

GitHub 保護自家的 OAuth Access Token 不會進入 GitHub 上公開的 Repository

GitHub 的公告:「Keeping GitHub OAuth Tokens Safe」。

當你不小心把 GitHub 的 OAuth Access Token 推到 GitHub 的 public repository 時,站方會自動 revoke 掉:

Starting today you can commit more confidently, knowing that we will email you if you push one of your OAuth Access Tokens to any public repository with a git push command. As an extra bonus, we'll also revoke your token so it can't be used to perform any unauthorized actions on your behalf.

保護使用者在使用 GitHub 自家的產品。

GoDaddy 將 Lavabit 的 SSL Certificate 撤銷了...

在「美國法院可以強制公司交出 SSL Private Key...」這篇提到法院文件顯示 Lavabit 的 SSL Certificate 已經被 FBI 拿走。

消息公開後幾天,GoDaddy 終於記得要依照程序,主動把 Lavabit 的 SSL Certificate 撤銷:「GoDaddy Pulls Lavabit's Security Creds Because The FBI Got Ahold Of Its Encryption Keys」。

巡迴庭的消息好像還沒出來...