幹壞事是進步最大的原動力
先前在「測試 Zen Browser」這邊提到 Zen，但遇到中文字型用了文泉驛正黑而沒有用 Noto Sans CJK TC 的問題，當時先一直放著，後來想到應該是 Flatpak 的 sandbox 造成的，用關鍵字找了一下資料可以在 GitHub 上看到這則說明：「[feature] Expose xdg-config/fontconfig to sandbox by default #3947」。
透過 cli 或是 Flatseal 在 Filesystem 的部分將 xdg-config/fontconfig:ro 設進去就可以了。
其中這邊的 magic word xdg-config 是出自「Sandbox Permissions」這邊，裡面也有提到 :ro 的部分，所以上面提到的 xdg-config/fontconfig:ro 就會是 ~/.config/fontconfig 的 readonly 權限了。
接著就可以在 ~/.config/fontconfig 裡面設定自己要的字型了。
Go 也搞了 Telemetry：「Telemetry in Go 1.23 and beyond」。
不過這邊是 opt-in design，預設不會送出去，需要下指令開：
Starting with Go 1.23, you can enable uploading of your local telemetry data with the following command[.]
這種侵入性低一些...
在 Hacker News Daily 上看到的「EUCLEAK Side-Channel Attack on the YubiKey 5 Series (ninjalab.io)」，原文在「EUCLEAK」這邊。
對 YubiKey 5 的攻擊，攻擊需要能夠碰到實體的 key，透過 side-channel 取得 ECDSA secret key 進而複製：
The attack requires physical access to the secure element (few local electromagnetic side-channel acquisitions, i.e. few minutes, are enough) in order to extract the ECDSA secret key. In the case of the FIDO protocol, this allows to create a clone of the FIDO device.
新版的 firmware 解掉了這個問題：
The new YubiKey firmware 5.7 update (May 6th, 2024) switches the YubiKeys from Infineon cryptographic library to Yubico new cryptographic library. To our knowledge, this new cryptographic library is not impacted by our work.
但是官方文件上面也有提到 YubiKey 不支援 firmware 升級：「YubiKey Firmware is Not Upgradable」，對於安全性有高要求的人可能要聯絡 Yubico 看能不能換了...
另外手上的 YubiKey 從外觀不太好認，我是用 USB 的 Device ID 認的，發現官方有列出來，在 Linux 下可以用 lsusb 看到，Windows 應該是裝置管理員之類的地方可以看：「YubiKey USB ID Values」。
在「Ask HN: How to store and share passwords in a company?」這邊看到的討論串，翻了討論後發現算是在 Hacker News 上面有共識的。
能夠掛上 SSO 管理的儘量用 SSO，不能的就用雲端提供的服務來管理密碼，甚至把 MFA (2FA) 也包進去。這邊常見的選擇有 1Password 或是 LastPass 可以用。
我記得 Okta 也有類似的方案，但以前接觸的時候因為有 minimal order 的問題 (因為是透過業務)，不適合小單位，不確定現在有沒有改變...
把服務分成兩種，第一種是程式碼在自己手上的 (自己開發的，或是手上有 source code 類的軟體)，這種可以修改程式碼配合的，花時間接到公司的認證系統上面 (最好是 SSO，避免經手密碼，次好是 LDAP/AD)。
另外一種是程式碼不在自己手上的，像是套裝軟體或是雲端服務的，這邊又分成幾種方法處理，一種是 OAuth2 Proxy 這樣的 reverse proxy 軟體，可以在前面擋各家的 SSO (像是常見的 Google 的企業版服務 Google Workspace)，然後在兩邊都用 access log 記錄 (記得把 username 一起記起來)，算是比較基本的方式。
另外一種情境是雲端服務，像是有些服務不支援多帳號管理，就用上面提到的 Enterprise Password Manager 統一管理密碼，然後搭配 HR 的離職流程在離職時換密碼，另外定時也換密碼。
我記得七八年前在 104 的時候有廠商推銷過可以自動幫你換密碼的方案 (有支援 password changing protocol 的可以直接換，沒有支援的就是模擬瀏覽器用 web scraping 的方法換)，但一時間忘記產品名稱了...
另外一種跟密碼管理比較無關，但還是可以提的是，遇到開 SSO 會變得很貴的服務 (也被稱為 SSO tax，像是「The SSO Wall of Shame」這邊列出來的服務)，而且不需要分別帳號時，這時候可以拿 Enterprise Password Manager 出來對付...
看到「Announcing AWS KMS Elliptic Curve Diffie-Hellman (ECDH) support」這篇的介紹，AWS KMS 支援 ECDH 了。
從 AWS 的文件「DeriveSharedSecret」這邊可以看到就是在不將 private key 暴露出來的情況下得到 ECDH 產生的 shared secret：
The private key in your KMS key pair never leaves AWS KMS unencrypted. DeriveSharedSecret returns the raw shared secret.
翻了一下其他兩個雲的 Cloud HSM 類服務，好像沒有看到 ECDH 的，不過如果是實際硬體 HSM 的話，Azure Dedicated HSM 似乎有支援，可以在 FAQ 這邊看到：
Dedicated HSM service provisions Thales Luna 7 HSM appliances.
Cryptography (ECDSA, ECDH, Ed25519, ECIES) with named, user-defined, and Brainpool curves, KCDSA
AWS KMS 畢竟是軟體基底的，要支援什麼演算法可以直接加...
在「Flaw has Microsoft Authenticator overwriting MFA accounts, locking users out (csoonline.com)」這邊看到的，原文在「Design flaw has Microsoft Authenticator overwriting MFA accounts, locking users out」，在講 Microsoft Authenticator (Android 版、iOS 版) 這個支援 TOTP 的 MFA 程式的長年 bug... (對一般人比較好理解的，這是六位數字的動態密碼 app)
會造成無法登入的 bug 是因為透過 QR code scan 加入新的帳號時，會蓋掉既有的帳號資料，所以產生的 QR code 就無法在舊的帳號/網站上面使用了：
That’s because, due to an issue involving which fields it uses, Microsoft Authenticator often overwrites accounts when a user adds a new account via QR scan — the most common method of doing so.
原因是因為 username 相同就會蓋掉，而大多數人在不同的地方都會用同樣的 username (像是我的 gslin)：
The core of the problem? Microsoft Authenticator will overwrite an account with the same username. Given the prominent use of email addresses for usernames, most users’ apps share the same username. Google Authenticator and just about every other authenticator app add the name of the issuer — such as a bank or a car company — to avoid this issue. Microsoft only uses the username.
然後 workaround 是不要用 Microsoft Authenticator，或是不要用 QR code scan：
There are multiple workarounds. The easiest is for companies to use any other authentication app. Not using the QR code scan feature — and manually entering the code — will also sidestep the issue, which doesn’t appear to arise when the authenticated accounts belong to Microsoft.
然後這個問題可以找到 2020 年開始有人抱怨，但作者測試看起來 2016 年的版本就已經是這樣了：
CSO Online found complaints of this problem dating back to 2020, but it appears to have been in place since Microsoft Authenticator was released in June 2016. (For historical context, Google was the first Authenticator app, having been launched in 2010.)
然後 Microsoft 確認有這樣的行為，但不認為是 bug 而是 feature (怎麼梗圖突然從腦袋裡冒出來...)：
Microsoft confirmed the issue but said it was a feature not a bug, and that it was the fault of users or companies that use the app for authentication.
然後專欄作者找了其他專家測試其他的 app，可以發現只有 Microsoft Authenticator 的處理是 override 然後炸掉：
By the way, I’ve tested this behavior in 14 other authenticator apps so far. None of them exhibit the same collision behavior that Microsoft Authenticator does,” he added. “I gave up at 14 because at that point, it’s obvious Microsoft are the ones who are doing things poorly here.
大概是大家都懶得吵了，反正可以用 Google Authenticator 或是其他 TOTP app...
在「Apple memory holed its broken promise for an OCSP opt-out (lapcatsoftware.com)」這邊看到的，原文是「Apple memory holed its broken promise for an OCSP opt-out」。
Apple 的系統機制會在每次啟動應用程式的時候去 Apple 自家的 OCSP 伺服器確認這個應用程式是否被 Apple 註銷了：
When you launch an app, macOS connects to Apple's OCSP service to check whether the app's Developer ID code signing certificate has been revoked by Apple.
本來 Apple 有說要改善，但看起來吃書了...
這有明顯的 privacy 問題，所以我的作法是參考 Apple 自家的「Use Apple products on enterprise networks」這份官方資料，把裡面所有 ocsp 相關的 record 都設到 /etc/hosts 內，目前是：
127.0.0.1 ocsp.apple.com ocsp.digicert.cn ocsp.digicert.com ocsp.entrust.net ocsp2.apple.com
可以重開機確保生效，然後用 ping ocsp.apple.com (或是其他 domain) 看看是不是 127.0.0.1。
看到 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 這點...
去年 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 需要這個長度...
在「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 的麻煩。