Firefox 與 Chrome 處理 Intermediate CA 的不同方式

Fediverse 上看到「The recording of my "Browsers biggest TLS Mistake" lightning talk at #37C3」這個,這是出自 37C3 的 lightning talk,影片不長,只有五分鐘,可以在「Browsers biggest TLS mistake」這邊看到。

正常的 HTTPS server 會送出 Intermediate CA certificate 與自己的 TLS certificate:

當伺服器端沒有設定好,通常是只送出自己的 TLS certificate:

這種情況在 Firefox 裡有處理,軟體本身會預載所有的 Intermediate CA 避免這種問題 (當然會需要跟著軟體更新),這點在三年前有提到過:「Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率?」,也就是這張投影片提到的情況:

Chrome 則是去看目前的 cache 資料,找看看是不是在其他地方有看到適合的 Intermediate CA 可以接起來:

這好像可以解釋為什麼之前遇到類似的問題的時候,在 Chrome 上面會需要進 chrome:// 裡面清東西才能重製...

穿越 Firewall 的作法

先看到「SSH over HTTPS (trofi.github.io)」這篇,原文「SSH over HTTPS」講怎麼利用 HTTPS 加上 CONNECT 指令穿過去。

作者有先介紹背景,他需要在醫院待個幾天,而醫院有免費的 WiFi 可以上網,但限制很多,基本上 TCP 的部分只有 80/tcp 與 443/tcp 會通,另外他有行動網路可以用 (但應該不是吃到飽的?),可以當作在現場直接設定 bypass 機制的工具:

I planned to spend 1-2 days in the hospital and did not plan to use the laptop.But now I am stuck here for the past two weeks and would like to tinker on small stuff remotely. The hospital has free Wi-fi access.

The caveat is that hospital blocks most connection types. It allows you only to do HTTP (TCP port 80) and HTTPS (TCP port 443) connections for most hosts. DNS (UDP port 53) and DoT (TCP port 853) seem to work as well at least for well-known DNS providers.

But SSH (TCP port 22 or most other custom ports) is blocked completely.

I wondered how hard would it be to pass SSH through HTTP or HTTPS. I had a GSM fallback so I could reconfigure remote server and try various solutions.

作者的方法就是在 TLS/SSL connection 上面跑 SSH,以前幹過,但就如同 comment 裡面提到的,Cisco 的 AnyConnect (主要是用 open-source client 的 OpenConnect 以及 open-source server 的 ocserv) 比較彈性,而且 AnyConnect 的協定會自動嘗試 UDP-based 的 DTLS,傳輸效率會比 TCP-based 的協定好,另外在 iOS 上可以直接裝 app store 裡面 Cisco 官方的 client 來用。

但從作者的其他文章看起來應該也是熟門熟路了,會這樣做應該是手上有 HTTPS 的 apache server 可以設定來用。

另外作者雖然沒寫出來,但想法應該是有 SSH 就可以在 command line 透過 -D 生出 SOCKS 服務當 proxy 讓其他程式使用,常見的應用程式大多都支援。

應該就是臨時要在醫院裡面待個一兩天時的暫時性方案,如果常態會遇到的話應該是會架 ocserv 來繞...

CloudFront 支援 4096-bit RSA 的 SSL/TLS certificate 了

CloudFront 總算支援 4096-bit 的 RSA SSL/TLS certificate 了:「Amazon CloudFront now supports 4096-bit RSA TLS certificates」。

翻了一下 AWS ACM,看起來是 2020 年以前就支援 4096-bit RSA SSL/TLS certificate 了,CloudFront 晚蠻多的...

另外查了一下目前的強度,NSA 給出 2048-bit RSA 對到 112-bit strength,而 3072-bit RSA 對到 128-bit strength;至於 4096-bit RSA,目前是估算大約在 140-bit strength,有點微妙的數字。

看起來主要應該是給 compliance 需求使用的,有些舊的 library 未必支援 ECC 類的演算法,還是得透過拉高 RSA key size 來增加安全性。

Uptime Kuma:UptimeRobot 的 Open Source Clone

UptimeRobot 算是我自己還蠻喜歡用的監控服務,各種常見的類型都支援,像是 HTTP/HTTPS website 的監控,ICMP Ping 或是 TCP 的監控,另外也提供 SSL certificate 的監控。

前陣子找資料的時候找到 Uptime Kuma,這是香港的 Louis Lam 開發的 open source software,光看名字就懷疑是 UptimeRobot 的致敬版本,裝起來用過後就更確定...

差不多用了一個多月了,基本上功能還蠻完整的,我把他接到我自己的 Slack 以及 Pushover 上,就很方便的可以監控服務:

挑一個點:

Amazon RDS 的 TLS 連線所使用的 CA 要更新了

Amazon RDSTLS (SSL) 連線所使用的 CA 要更新了:「Rotate Your SSL/TLS Certificates Now – Amazon RDS and Amazon Aurora Expire in 2024」。

如果沒有開 TLS 連線的話是不受影響 (像是內網裸奔),但如果有在用 TLS 的話就要注意一下了,看起來得手動更新處理。

比較特別的是新的 CA 簽的超長:

Most SSL/TLS certificates (rds-ca-2019) for your DB instances will expire in 2024 after the certificate update in 2020. In December 2022, we released new CA certificates that are valid for 40 years (rds-ca-rsa2048-g1) and 100 years (rds-ca-rsa4096-g1 and rds-ca-ecc384-g1). So, if you rotate your CA certificates, you don’t need to do It again for a long time.

現有的 rds-ca-2019 可以在 https://s3.amazonaws.com/rds-downloads/rds-ca-2019-root.pem 這邊取得,用 openssl x509 -in rds-ca-2019-root.pem -text 可以看到資料。

crt.sh 上翻過一些字串,沒看到被簽的記錄,所以看起來無法透過一般 trusted store 裡面的 Root CA 一路信任下來。

新的 key 應該也是 Private Root CA,從名字看起來應該是對應的 key algorithm。其中 RSA 2048 的簽了 40 年,而 RSA 4096 與 ECC 384 的簽了 100 年,雖然說是自家弄的 CA,但目前的 compliance 沒有要求 key rotation 嗎...

Anyway,常用的區域基本上都是 August 22, 2024 這個日期,大約還有九個多月的時間更新,依照 AWS 的慣例,後面應該還會提醒幾次:

話說 2020 年的時候也有更新,當時是 Jeff Barr 出來說明的:「Urgent & Important – Rotate Your Amazon RDS, Aurora, and Amazon DocumentDB (with MongoDB compatibility) Certificates」,現在看起來一些常態性的說明都陸續交棒給 Channy Yun 了...

不過這次這樣搞 40 年 & 100 年,後續要更新應該都是演算法的推進了,比較不會是要到期...

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 上的行為。

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

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 上設定...

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% 嗎?

Windows 3.1 下的 GPT client

前幾天在 Hacker News 上看到「Show HN: WinGPT – AI assistant for Windows 3.1 (dialup.net)」這篇,原始文章「WinGPT: AI Assistant for Windows 3.1」在介紹 Windows 3.1 下的 GPT client。

雖然反差很大 (一個 20 世紀的 GUI 環境配上最新科技),但從 Hacker News 的討論可以看到,最熱烈的是在 16-bit 環境下實作 TLS 1.3 連線,也就原文裡的這段,提到了他是原生支援 TLS 1.3:

WinGPT connects to the OpenAI API server natively with TLS 1.3, so it doesn't require a proxy on a modern machine to terminate TLS. To see how I did this and some of the challenges, take a look at Modern TLS on 16-bit Windows. (As you'll see on that page, this is not a secure implementation).

不過他不是從零開始解,而是基於 wolfSSL 的實作,因為 wolfSSL 有支援 16-bit compiler,就不需要從零開始:

WolfSSL stood out among the pack as it had explicit 16-bit compiler support while being fully-featured and well-supported.

這是讓人看到會「蛤?」的東西 XD