Category: Privacy

Cavium (被 Marvell 併購) 在 Snowden leak 中被列為 SIGINT "enabled" vendor

標題可能會有點難懂，比較簡單的意思就是在 Snowden 當年 (2013) 洩漏的資料裡面發現了不太妙的東西，發現 Cavium (現在的 Marvell) 的 CPU 有可能被埋入後門，而他們家的產品被一堆廠商提供的「資安產品」使用。

出自 X (Twitter) 上面提到的：

這段出可以從 2022 年的「Communication in a world of pervasive surveillance」這份文件裡面找到，就在他寫的 page 71 (PDF 的 page 90) 的 note 21：

While working on documents in the Snowden archive the thesis author learned that an American fabless semiconductor CPU vendor named Cavium is listed as a successful SIGINT "enabled" CPU vendor. By chance this was the same CPU present in the thesis author’s Internet router (UniFi USG3). The entire Snowden archive should be open for academic researchers to better understand more of the history of such behavior.

Ubiquiti 直接中槍...

而另一方面，在 Hacker News 上的討論「Snowden leak: Cavium networking hardware may contain NSA backdoor (twitter.com/matthew_d_green)」就讓人頭更痛了，像是當初 Cavium 就有發過新聞稿提到他們是 AWS CloudHSM 的供應商：「Cavium's LiquidSecurity® HSM Enables Hybrid Cloud Users to Synchronize Keys Between AWS CloudHSM and Private Clouds」。

而使用者也確認有從 log 裡面看到看到 Cavium 的記錄：

Ayup. We use AWS CloudHSM to hold our private signing keys for deploying field upgrades to our hardware. And when we break the CI scripts I see Cavium in the AWS logs.

Now I gotta take this to our security team and figure out what to do.

居然是 CloudHSM 這種在架構上幾乎是放在 root of trust 上的東西...

用 Little Rat 看哪些 extension 在後面亂連線

還在日本的時候在 Hacker News 上看到「Show HN: Little Rat – Chrome extension monitors network calls of all extensions (github.com/dnakov)」這篇，在介紹「little-rat」這個專案，可以看 extension 做了那些連線。

放上 Chrome Web Store 的版本比較陽春，只能擋而不能看，因為 declarativeNetRequest.onRuleMatchedDebug 不能上：

The reason is that the extension uses the declarativeNetRequest.onRuleMatchedDebug API which is not available for publishing in the Chrome Web Store.

比較完整的功能還是需要自己 git clone 下來後裝，缺點就是要每一台自己裝，另外也要自己更新重跑起來。

裝好後跑一陣子讓他記錄，可以看到有些連線是預料中的，像是 uBlock Origin 會需要定時更新 rule，但也意外的看到一些有問題的 extension 了...

Cloudflare 可以針對不同 Hostname 給不同的 TLS 設定了

Cloudflare 總算是提供付費方案 (包在 Advanced Certificate Manager 裡面)，可以針對不同的 hostname 給不同的 TLS 設定了：「Introducing per hostname TLS settings — security fit to your needs」。

本來的限制是整個 domain 都是一樣的 TLS 設定，這點對免費仔來說還好，但對於企業客戶來說就不太好用了。

遇到客戶端 (甚至是客戶) 是 Java 6 這種不支援 TLS 1.2 的情況 (參考「Qualys SSL Labs - Projects / User Agent Capabilities: Java 6u45」這邊)，你還是得想辦法生一組 TLS 1.0 服務出來，但整個 domain 都開又有可能會死在 PCI-DSS 之類的規範。

以前遇到的時候有兩種解法，第一種是在客戶端自己解決，像是在內網架 SSL proxy (通常會搭配 self-signed CA) 讓 Java 6 的 client 還是可以透過 TLS 1.0 通訊，但是連到 internet 上面會是比較新的 TLS 1.2 或是 TLS 1.3，這種算是比較安全的。

另外一種就是在 Cloudflare 上另外開一個 domain，這樣就可以用 TLS 1.0 半裸奔。

現在這樣等於是讓第二個方案更簡單一點，不用另外開 domain，只需要在 hostname 上設定...

Tails 換網域名稱，從 tails.boum.org 換到 tails.net

看到 Tails 換了一個新的網域名稱，從本來的 tails.boum.org 換到了 tails.net 上：「Welcome to tails.net!」。

看了 tails.net 的 WHOIS 可以發現這也是個老域名了，甚至比 Tails 軟體出現的 2009 年還早：

Updated Date: 2022-08-09T10:30:42
Creation Date: 2002-12-18T11:36:37
Registrar Registration Expiration Date: 2024-12-18T11:36:37

理所當然的，本來的 tails.boum.org 也還會動，目前是重導到 tails.net 上面。

然後研究了一下 boum.org 是什麼，用「site:boum.org -site:tails.boum.org」翻了一下各家搜尋引擎：「Kagi 的」、「DuckDuckGo 的」、「Google 的」。

其實還不少東西？看起來像是某個業餘團體或是組織...

另外如果是用 site:tails.boum.org 找，可以發現除了主站以外，下面其實還不少 subdomain，像是 gitlab.tails.boum.org 這樣的網域，所以應該是還有不少東西要改...

CloudFront 支援 3072 bit RSA 憑證

看到 CloudFront 支援 3072 bit RSA certificate 的消息：「Amazon CloudFront announces support for 3072-bit RSA certificates」。

2048 bit 在一般情況算是夠用，畢竟現在的紀錄也才到 829 bit (參考「RSA Factoring Challenge」)：

1024-bit RSA keys are equivalent in strength to 80-bit symmetric keys, 2048-bit RSA keys to 112-bit symmetric keys, 3072-bit RSA keys to 128-bit symmetric keys, and 15360-bit RSA keys to 256-bit symmetric keys. In 2003, RSA Security claimed that 1024-bit keys were likely to become crackable some time between 2006 and 2010, while 2048-bit keys are sufficient until 2030. As of 2020 the largest RSA key publicly known to be cracked is RSA-250 with 829 bits.

但如果哪天突然又有新的演算法出來威脅到 2048 bit 的話，會多一點緩衝的空間？

玩了一下 OpenSnitch，Linux 下的 Application Firewall

這是在 Hacker News 上的討論「Brute-forcing a macOS user’s real name from a browser using mDNS (fingerprint.com)」這篇看到的，裡面一開始是提到 Mac 上面的 Little Snitch，可以針對特定應用程式設定防火牆規則，而在 Linux 上對應的解決方案則是 OpenSnitch，但一直沒有嘗試，所以就試著用看看...

套件分成兩個部分，一個是 OpenSnitch 的主程式，另外一個是 GUI 的部分。

而在 Ubuntu 22.04 上裝有點麻煩，因為 Ubuntu 22.04 上預設的 grpc package 似乎是有 bug，需要裝新版解決。

不過我在找 PPA 的時候發現有人包了輔助套件：「OpenSnitch - application firewall (Xenial & newer)」。

這個套件本身是沒有包 OpenSnitch 主程式與 GUI 套件的，他只是要「補充」官方套件安裝的問題，所以需要照他的說明安裝：(我把下面指令提到的 1.5.2 換成目前新版的 1.6.0 裝，目前看起來是會動的)

sudo add-apt-repository ppa:savoury1/opensnitch
sudo apt-get update && sudo apt-get upgrade
sudo dpkg -i opensnitch_1.5.2-1_amd64.deb
sudo dpkg -i python3-opensnitch-ui_1.5.2-1_all.deb
sudo apt-get -f install

這邊用 dpkg -i 裝，而不是用 apt install 的原因是故意讓他不裝 dependency，等到後面的 apt-get -f install 時再裝 PPA 裡面提供的 dependency。

裝好後把跑 opensnitch-gui 起來後就會陸陸續續收到系統內不同的應用程式嘗試的連線，像是官網提供的 screenshot 這樣 (會跳出像左邊這樣的視窗)：

這樣可以控的比較細，不過剛開始用會需要花時間把系統內常態性的 request 先設定過一次，還蠻煩的 XD

透過 mDNS 建立內部網路的 fingerprint

在 Hacker News 上看到透過 mDNS 建立 fingerprint 的方式，進而定位使用者身分：「Brute-forcing a macOS user’s real name from a browser using mDNS (fingerprint.com)」，原文在「Demo: Brute-forcing a macOS user’s real name from a browser using mDNS」。

利用發 HTTP(s) request 出去時，雖然都是傳回 Failed to fetch 錯誤，但因為 hostname 存在時會是 connection timeout，而不存在時會直接因為 DNS 查不到而很快 failed 掉，這個時間差異產生了 side channel，可以透過時間差異知道某個 hostname 是否存在。

這個技巧配合字典就可以大量掃描 *.local 的 mDNS 網段，進而產生出內部網路的 fingerprint。

這個問題應該是有標準解法 (或是有被提案過的解法)，就是不讓 internet domain 存取 local domain 的東西，像是避免 internet 上的網站透過 JavaScript 碰到 http://127.0.0.1:xxx/ 的機制。

應該是把 *.local 用同樣方式對待就能避開這個問題？

Let's Encrypt 與 IdenTrust 延長三年的 cross sign 在 2024/10/01 要結束了

先前 Let's Encrypt 跟 IdenTrust 的 cross sign 會在 2024/10/01 到期，可以參考 3958242236 這邊的資訊，可以看到由 IdenTrust 的 DST Root CA X3 對 Let's Encrypt (ISRG) 的 ISRG Root X1 簽名，時間是到 2024/09/30 18:14:03 GMT (換算大概是台灣隔日的清晨兩點多)：

Issuer: (CA ID: 276)
    commonName                = DST Root CA X3
    organizationName          = Digital Signature Trust Co.
Validity
    Not Before: Jan 20 19:14:03 2021 GMT
    Not After : Sep 30 18:14:03 2024 GMT
Subject: (CA ID: 7394)
    commonName                = ISRG Root X1
    organizationName          = Internet Security Research Group
    countryName               = US

所以 Let's Encrypt 這邊也整理出了對應的落日計畫：「Shortening the Let's Encrypt Chain of Trust」。

第一波是 2024/02/08，從這個時間點開始 Let's Encrypt 的 ACME 服務預設組出來的 SSL certificate 將不會帶 IdenTrust 提供的 cross sign 憑證，但你還是可以自己另外設定取用：

On Thursday, Feb 8th, 2024, we will stop providing the cross-sign by default in requests made to our /acme/certificate API endpoint. For most Subscribers, this means that your ACME client will configure a chain which terminates at ISRG Root X1, and your webserver will begin providing this shorter chain in all TLS handshakes. The longer chain, terminating at the soon-to-expire cross-sign, will still be available as an alternate chain which you can configure your client to request.

再來是過期前的 90 天多一點的 2024/06/06，Let's Encrypt 的 ACME 服務將不會提供 cross sign 的憑證：

On Thursday, June 6th, 2024, we will stop providing the longer cross-signed chain entirely. This is just over 90 days (the lifetime of one certificate) before the cross-sign expires, and we need to make sure subscribers have had at least one full issuance cycle to migrate off of the cross-signed chain.

最後就是過期的日子 2024/09/30：

On Monday, September 30th, 2024, the cross-signed certificate will expire. This should be a non-event for most people, as any client breakages should have occurred over the preceding six months.

依照說明，應該是 Android 7.0 以及之前的版本會產生問題，照目前的數字看起來是 100% - 93.9% = 6.1%：

接下來一年應該會再低一些，但不確定會低多少，有機會 <5% 嗎？

無 Internet 也能使用的 IP cam

前幾天在 Hacker News 上看到的討論，有人在問有沒有不需要連網，也不希望透過 app 連的 IP cam：「Ask HN: IP cameras that don't require an app or internet?」。會在意隱私性的人應該會有興趣。

討論裡面意外看到幾個台灣廠商，首先是翻到 GeoVision，奇偶科技：

Geovision cameras are low end and not expensive. They are Taiwanese in origin and are pretty easy to find.

這家的產品在台灣一般 C 端的 EC 通路沒找到，但蝦皮上有翻到一些資料；如果跑去美國的 Amazon 上面找可以看到不少商品，價錢似乎比較便宜？

另外一個是台達旗下的 VIVOTEK：

There's a Taiwanese brand Vivotek that makes some relatively affordable NDAA cameras. I'm hoping to try them out myself, but unfortunately haven't had time yet.

這家在 PChome 與 momo 上面都有擺一些商品，另外在蝦皮上就可以找到蠻多商品；在 Amazon 上面也不少商品。

Google Authenticator 的備份功能不是 E2EE (end-to-end encryption)

前幾天提到了 Google Authenticator 總算是支援備份功能了：「Google Authenticator 支援備份到 Google Account 的功能」，當初操作的時候沒看到自訂密碼之類的功能，就有在猜應該不是 E2EE，直接攔傳輸內容也被證實沒有 E2EE 了，TOTP 的 secret token 都是直接傳輸的：「PSA: Google Authenticator's Cloud-Synced 2FA Codes Aren't End-to-End Encrypted」。

Google 的發言人回應 CNET 的詢問時只說會有計畫做，但沒有給更細的資料：

To ensure that we're offering a full set of options for users, we have also begun rolling out optional E2EE in some of our products, and we plan to offer E2EE for Google Authenticator in the future.

在意的人就還是先不要開...