Security

Let's Encrypt 想要停掉 OCSP 服務

看到 Let's Encrypt 貼出來的文章，想要停掉 OCSP 服務：「Intent to End OCSP Service」，而打算以 CRLs 為主。

OCSP 是拿來驗證 certificate 是否有效的機制，由 CA 提供服務讓瀏覽器查詢，但這會有效能與 privacy issue。

前者比較容易理解，因為熱門網站所使用的 HTTPS certificate 會導致很多瀏覽器跑去 OCSP 服務查詢；後者則是因為 OCSP 服務就會知道哪個 IP 存取哪個網站。

不過這兩個應該都可以用 OCSP stapling 解決才對，也就是 web server 去 OCSP 服務拿有效的簽名 (證明你手上的是有效的)，然後在瀏覽器連上來的時候一起送出去，這樣瀏覽器就不用跑去煩 OCSP 服務，而且 OCSP 服務也不知道誰看了什麼網站。

不過跟 CRLs 相比還是不小的負擔就是了，尤其像是 Let's Encrypt 這種等級的量，光是 web server 固定時間去要 OCSP stapling 的簽名 (這又是個數位簽章的動作) 不容易 cache；反過來 CRLs 容易 cache 多了？

另外一方面，CA/Browser 在 2023 年的時候已經投票通過，將 OCSP 列為選擇性項目，而 CRLs 則變成必要項目：「Ballot SC-063 v4: Make OCSP Optional, Require CRLs, and Incentivize Automation」

看文章的語氣，應該是先放個風向？尤其故意不提到 OCSP stapling 這點...

Android 的 Linux Kernel 將會有四年的維護期

去年 Linux Kernel 決定將 LTS 從六年縮短為兩年 (參考先前寫到的「Linux Kernel 後續的 LTS 版本將縮短成兩年」)，而 Android 這邊決定後來的 LTS 版本將額外提供兩年支援，變成四年：「Google extends Linux kernel support to keep Android devices secure for longer」，引用的報導在「Google extends Linux kernel support to keep Android devices secure for longer」。

在 Android 的說明文件「Android common kernels」這邊有提到這個時間：

Beginning with kernel 6.6, the support lifetime for the stable kernels is 4 years.

應該是 Android 本身的 support policy 需要這個長度...

透過 eBPF 攔 TLS 連線的明文

在「Capturing Linux SSL/TLS plaintext without a CA certificate using eBPF (github.com/gojue)」這邊看到的工具，可以透過 eBPF 直接攔 TLS 連線的明文，專案在 gojue/ecapture 這邊可以看到。

除了支援 OpenSSL，還支援了 GnuTLS 與 NSS，看起來常見的 library 都有支援。

算是 reverse engineering 的工具，看起來會適合用在應用程式有 pinning 的情況下 (像是 CA pinning，或是 certificate pinning)，有機會省下改 binary 的麻煩。

官方說明中有提到支援 Android + arm64 這點應該也算清楚。

dotenvx

清一清 tab... 兩個禮拜前還在日本時在 Hacker News 的「Show HN: From dotenv to dotenvx – better config management (dotenvx.com)」看到的東西，原文在推廣 dotenvx：「From dotenv to dotenvx: Next Generation Config Management」。

從 GitHub 的文件上可以看到幾個用法，一種是直接用，像是一般的 dotenv 的用法：

// index.js
require('@dotenvx/dotenvx').config()
console.log(`Hello ${process.env.HELLO}`)

另外一個是當 wrapper 用，像是這樣：

$ dotenvx run -- node index.js
Hello World # with dotenvx
> :-D

然後後者可以指定不同的 .env 多環境使用：

$ dotenvx run -f .env.production -- node index.js
[dotenvx][info] loading env (1) from .env.production
Hello production

另外還支援了 encrypt/decrypt 的能力降低 secret 的風險？不過這應該已經不是目前比較安全的方法了，這十年下來已經知道把 secret 放在環境變數裡太容易洩漏。

環境變數在呼叫外部程式時會被繼承，算是常見的 leaking 管道，另外就算不考慮外部程式，也會遇到環境變數算是一種全域變數，在寫測試時也很頭痛。

目前被提出來比較好的方法是把 secret 都放到 vault service 裡面，由 vault service 給一把讀取用的 API key，放進 dotenv 或是其他地方 (被稱為 secret zero)。

這樣這把 API key 去 vault service 抓取真正的 secret 放到程式內的物件取用 (像是資料庫的帳號密碼)，而不是環境變數。

這樣做的 threat model 在 Hacker News 上有對應的討論，另外 AWS 的服務其實也做了類似的事情：「Amazon EC2 的 IMDSv2 計畫」。

所以 dotenvx 大概就看看，有個印象就好？

regreSSHion：OpenSSH RCE

人在機場準備要回台灣，在 Hacker News 上看到「RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems (qualys.com)」這個整個被抽醒，Qualys 的 security advisory 在這：「regreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems (CVE-2024-6387)」。

剛剛看 Ubuntu 套件已經更新了，請儘快更新...

OpenSSH 官方的「release-9.8」內有提到這是 race condition 造成的問題，在 32-bit 的 lab 環境上面大約六到八小時可以打進去，64-bit 環境理論上應該也是可行的，但時間還沒有被驗證：

Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon.

在 security advisory 裡面有提到更細節的部分，解釋了 race condition 的攻擊對象，以及為什麼 OpenBSD 沒中獎：

This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an unauthenticated remote code execution as root, because it affects sshd's privileged code, which is not sandboxed and runs with full privileges. We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.

這幾天應該會有更多測試出來，另外 Hacker News 上有人提到上個月 OpenSSH 打算內建阻擋系統的事情，有在猜測跟這個 security advisory 有關？(參考「OpenSSH 要內建阻擋系統了」)...

Anyway，後續可以再研究看看，但現在先趕緊把手上機器更新一輪比較要緊...

polyfill.io 被放 malicious code 的事件

台灣的圈子蠻多人是從「請儘速遠離 cdn.polyfill.io 之惡意程式碼淺析」這邊看到的，一些 code 相關的分析部分可以移駕過去看。裡面提到的 GitHub 上面 alitonium 所寫的 comment 蠻值得讀一下 (第一次點的時候會出現 GitHub 的警告，再點一次應該就會跳到正確的 comment 上)。

polyfill.js 算是老專案了，從 https://github.com/polyfillpolyfill/polyfill-service/graphs/contributors 這邊可以看到是 2013 年開始有記錄，主要是針對舊的瀏覽器 (像是 IE11)，透過 javascript 的方式補上對應的功能。

現在的瀏覽器都是一直在更新，大多數的情況不太需要 polyfill 了，但畢竟很多舊的案子還在用，在這次 domain 被中國公司拿走後，Cloudflare 在今年 2024/2/29 就有先寫一篇算是預警的文章了：「polyfill.io now available on cdnjs: reduce your supply chain risk」，不過這種事情都是還沒發生前大家不會有太多重視，接下來就是 GitHub 上面的討論，然後是真的被動手加 malicious code 進去後，有人發現的討論。

後續大家都被迫要開始處理這件事情，GitHub 的作法看起來沒什麼問題：先標注 malicious repository 但是還是讓人可以進去翻歷史資料與討論。

不過 Cloudflare 這邊動作有點大，直接主動幫 CDN 客戶過濾了：「Automatically replacing polyfill.io links with Cloudflare’s mirror for a safer Internet」，這篇在 Hacker News 上也有討論：「Cloudflare automatically fixes Polyfill.io for free sites (cloudflare.com)」。

這個「越界」有點多，這應該也是直接讓 CEO Matthew Prince 出來掛文章作者的原因。這次 Cloudflare 主動做的事情包括了將免費的客戶預設開啟過濾，而付費的客戶則不會主動開啟，但提供一鍵開關：

Any website on the free plan has this feature automatically activated now. Websites on any paid plan can turn on this feature with a single click.

另外也允許所有客戶關掉這個保護：

All customers can turn off the feature at any time.

所以後續就會有另外一條大支線討論：在使用者沒有事前同意的情況下，以「安全」為名主動更改使用者頁面上的東西，這件事情是不是可以接受？如果以「安全」為名可以接受，為什麼是免費的先動，付費的卻不動？雖然我猜 Cloudflare 會裝死到底就是了...

Chrome 停止信任 Entrust 憑證的計畫

Hacker News 上看到「Entrust Certificate Distrust (googleblog.com)」這個討論，Google 決定要停止信任 Entrust 頒發的憑證：「Sustaining Digital Certificate Security - Entrust Certificate Distrust」。

快速翻了一下 Google 列出來在 Mozilla Bug List 上面的記錄 (在這裡)，應該是出太多包，而且有些包給的解釋又不能說明出包的理由？

我拉了一下 Let's Encrypt 的情況，可以看到是兩種不同的情境：「這邊」，或是 GlobalSign：「這邊」。

目前的計畫是在下個 stable 版開始設限 (現在 stable 是 126，目前公告 127 開始擋)，但給了四個月的期限，仍然會認 Entrust 在 2024/10/31 前發的憑證：

TLS server authentication certificates validating to the following Entrust roots whose earliest Signed Certificate Timestamp (SCT) is dated after October 31, 2024, will no longer be trusted by default.

因為有 Certificate Transparency (CT) 的關係，所有的簽署資料都會是公開可以查的，所以 Hacker News 上面有人整理出來有受到影響的網站... 看起來是把抓回來的資料丟到 ClickHouse 上分析：「SELECT rank, domain, certificate_issuer FROM minicrawl_processed WHERE startsWith(certificate_issuer, 'Entrust') AND date = today() ORDER BY rank::UInt32」。

裡面可以看到許多知名的網站 (畢竟還是 Entrust)，這點從「Market share trends for SSL certificate authorities」這邊可以看得出來，雖然跟前面幾家比起來算小，但至少還是在榜上。

來等看看 Mozilla 與 Apple 的動作，會不會有更嚴格的 distrust 的行為 (提前？)，畢竟讓他再做四個月的生意也是很危險？

美國正在立法禁用大疆的產品

在「DJI ban passes the House and moves on to the Senate (dronedj.com)」這邊看到的，原文在「DJI ban passes the House and moves on to the Senate」這邊。

目前眾議院已經過過了，裡面提到 H.R.2864 (Countering CCP Drones Act)：

One of these sections, H.R. 2864, or the Countering CCP Drones Act, was added to the bill and can be found under Section 1722. For those who are just hearing about this for the first time, it would remove DJI’s ability to get approval from the FCC, banning any future drones from being imported and possibly grounding current drones.

在官方的官面上則是直接列出大疆 (DJI)：

Countering CCP Drones Act

This bill requires the inclusion of telecommunications and video surveillance equipment or services produced or provided by Shenzhen Da-Jiang Innovations Sciences and Technologies Company Limited (a Chinese drone maker commonly known as DJI Technologies) on a list of communications equipment or services determined by the Federal Communications Commission (FCC) to pose an unacceptable risk to U.S. national security. Current law prohibits the use of federal funding available through specified FCC programs for purchasing or maintaining listed equipment or services.

現在是在聯邦禁用，看起來打算提升警戒列為國安等級，打算全國禁用？

OpenSSH 要內建阻擋系統了

在「OpenSSH introduces options to penalize undesirable behavior」這邊看到 OpenSSH 要內建阻擋系統了，算是取代了 fail2ban 的一些功能？

還蠻... 特別的？不知道為什麼現在這個時間點會想要實作這個功能？

這個功能在 OpenBSD 7.6 上面預設會開啟，這點不確定其他 distribution 會怎麼安排：

So now we know: starting with OpenBSD 7.6, PerSourcePenalties will be enabled by default, and admins who do not themselves run PF or other network translation mechanisms will need to keep the consequences of inconsiderate NAT use in mind.

超長網域名稱會遇到的 TLS certificate 問題

在「L(O*62).ONG: Make your URL longer (looooooooooooooooooooooooooooooooooooooo...)」這邊看到的有趣東西，網站是「L(o*62).ong - Make your URL longer」，網站的主人還在搞事就被貼到 Hacker News 上，所以他就上來說明一下發生了什麼事情...

在 id=40543697 這邊提到網域名稱過長導致撞到 TLS certificate 中 commonName (CN) 欄位長度限制的問題：

The longest segment of a domain name is 63 characters. The maximum length of an HTTPS certificate commonName is 64 characters.

This caused Cloudflare, Vercel, and Netlify to be unable to use Let's Encrypt to sign HTTPS certificates (because they used the domain name as the commonName), but Zeabur can use Let's Encrypt to sign HTTPS certificates.

Finally, the Cloudflare certificate was switched to Google Trust Services LLC to successfully sign.

不過後面有人提到 commonName 在網頁用的 TLS certificate 已經 deprecated 很久了，而 Let's Encrypt 在 2023 年的時候已經支援 commonName 留空，改用 Subject Alternative Name，可以到 255 chars。

留言裡面所連結的 Let's Encrypt 公告上面也提到了類似的事情：「Simplifying Issuance for Very Long Domain Names」。

Additionally, the CN is limited to at most 64 characters, while SANs can be significantly longer. This means that the CN is not only redundant, but actively restrictive: a certificate which has a Common Name cannot contain only very long domain names, because none of them would fit in the CN. For these reasons, the BRs state that for Domain Validated certificates, the Common Name field is "not recommended".

所以看起來是各家系統還沒有跟著改 (因為 Let's Encrypt 先前需要 CN 有值)，但如果是自己申請的應該是可以自己避開了 (生 csr 的時候就改用 SAN)？