AWS 要在歐洲建立一個完全獨立的 Cloud 系統

CNBC 上看到的新聞,AWS 打算在歐洲建立一個完全獨立的 Cloud 系統:「Amazon launches European ‘sovereign’ cloud as EU data debate rages」。

AWS European Sovereign Cloud 會是完全獨立的 cloud:

Amazon on Wednesday said it will launch an independent cloud for Europe aimed at companies in highly-regulated industries and the public sector.

這邊講的「完全獨立」,除了東西都放在歐洲以外,連員工都是歐盟員工:

Customers of the new system will be able to keep certain data in the European Union and only EU-resident AWS employees who are located in the 27-nation bloc will have control of the operations and support for the sovereign cloud.

這個作法倒是頗特別的,看起來是想要試著說服歐盟這樣是 OK 的?推出的時候可以看看還有什麼特別的東西?

ISP 偽造出合法的 SSL certificate,對放在德國的 xmpp.ru 進行 MITM 監聽

標題有點複雜,先講一下 http-01 認證,這是目前 Let's Encrypt 上最常被使用的認證方式,是透過 HTTP 協定完成認證,你只要能回答 http://www.example.com/.well-known/acme-challenge/XXX 的內容就能過。

一般來說,這個 HTTP 位置只有這台伺服器的 owner 才有辦法提供,也就能確保不是任何人都可以申請。

但因為這邊走的是 HTTP,對於 ISP 這種比較特別的身分來說,他可以從中架設 HTTP 的 MITM Proxy 做到這件事情。

而有了合法的 SSL certificate 之後,中間的 MITM Proxy 就不只能聽 HTTP 了,還可以聽 HTTPS 的內容 (甚至修改內容)。

這次發生的事情就是在德國的 LinodeHetzner 機房內的服務,俄羅斯最大的 XMPP 服務 xmpp.ru 被搞出這件事情 (XMPP 是一個開放協定,不熟的話可以想像成類似 Line 或是 Telegram 的服務,但 XMPP 是開放協定,可以用自己喜歡的軟體連上):「Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service」。

他們在 Hetzner 的伺服器上有發現 network offline 的訊號:

[Tue Jul 18 12:58:29 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Down
[Tue Jul 18 12:58:48 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

而在這個 network offline 的時間不久後 Let's Encrypt 發出了 xmpp.ru 與 jabber.ru 的 SSL certificate (crt.sh 上可以查到,在 99976947049997621208):

18 July 2023 issuing time is about the same when Hetzner server has lost network link for several seconds.

這些徵兆符合改接到 MITM Proxy 上的行為。

這次的事情很大條,因為這些伺服器是在德國,不是在俄羅斯... 事情才剛開始被報導出來,後續得繼續追蹤,而且應該也會促成新的機制被引入?

在 Raspberry Pi (32-bit) 上安裝 Tor

Raspbian (bullseye) 裡面的 Tor 版本太舊 (0.4.5.16-1):

0.4.5.16-1 (/var/lib/apt/lists/raspbian.raspberrypi.org_raspbian_dists_bullseye_main_binary-armhf_Packages)
 Description Language: 
                 File: /var/lib/apt/lists/raspbian.raspberrypi.org_raspbian_dists_bullseye_main_binary-armhf_Packages
                  MD5: 9106e8e4b3843ebd532ba2b89615a92e
 Description Language: 
                 File: /var/lib/dpkg/status
                  MD5: 9106e8e4b3843ebd532ba2b89615a92e

這個版本試著連上線的時候會發生像是這樣的錯誤訊息:

Oct  4 10:55:58 myserver Tor[991]: http status 400 ("Tor version is insecure or unsupported. Please upgrade!") response from dirserver 1.2.3.4:80. Please correct.

本來想說可以裝 Tor 官方的版本 (官方有提供 apt repository),結果發現官方不支援 Raspberry Pi 一代用的 armhf 了,只好另外找...

然後翻到「http://raspbian.raspberrypi.org/raspbian/pool/main/t/tor/」這邊有看到新版的 deb 檔案,但拉下來後發現 dependency 需要 libssl3,在 bullseye 上面沒辦法跑。

後來在 Reddit 上翻到有人貼出來的 workaround:「How do I update my TOR relay on a 32-bit armhf bullseye system (Raspberry Pi 3) to the latest version?」,方法是去 Debian 那邊挖 bullseye-backport:「Debian -- Package Download Selection -- tor_0.4.7.13-1~bpo11+1_armhf.deb」。

拉下來以後直接 dpkg -i 幹進去,然後重跑 Tor 看 /var/log/syslog 內容,發現就連上了。

不是最新版 0.4.8.x,但至少能用...?

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 上的東西...

Google Chrome 將在 115 版之後預設使用 HTTPS 連線

Google Chrome (Chromium) 宣布 115 版後將預設使用 HTTPS 連線:「Towards HTTPS by default」。

查了一下 115.0.5790.98 是 2023/07/18 就出的版本,現在才冒出這篇文章有點晚,但大概就是講一下幹了什麼事情?

We're currently experimenting with this change in Chrome version 115, working to standardize the behavior across the web, and plan to roll out the feature to everyone soon.

主要的差異是在於,即使你輸入或是點擊的連結是 http://,他還是會優先嘗試 HTTPS:

Chrome will automatically upgrade all http:// navigations to https://, even when you click on a link that explicitly declares http://.

只有在 http:// 連結遇到 upgrade 到 HTTPS 失敗時才會回頭用 HTTP:

This works very similarly to HSTS upgrading, but Chrome will detect when these upgrades fail (e.g. due to a site providing an invalid certificate or returning a HTTP 404), and will automatically fallback to http://.

而本來就用 https:// 的連線就完全不會碰 HTTP 了。

講到推動 HTTPS 這點,前陣子剛好也是 Snowden 揭露美國 PRISM (菱鏡計畫) 十年的日子,當年在揭露後也因此加速了各種加密技術的基礎建設,像是 Let's Encrypt,而這也使得 HTTPS 更加普及,也讓 Google Chrome 現在可以預設切 HTTPS。

用 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 了...

透過 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 EncryptIdenTrust 的 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.

這家在 PChomemomo 上面都有擺一些商品,另外在蝦皮上就可以找到蠻多商品;在 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.

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