Tag: tls

HTTP/3 + QUIC 的效率問題

前天看到討論蠻熱烈問題，提到了 HTTP/3 + UDP-based 的 QUIC 的效率比起 HTTP/2 + TCP-based 的 TLS 慢很多的問題：「QUIC is not quick enough over fast internet (acm.org)」，原文在「QUIC is not Quick Enough over Fast Internet」，如果要看 PDF 的話可以看預印本上的「QUIC is not Quick Enough over Fast Internet」。

之所以會有這麼多討論，是因為這篇文章說 HTTP/3 + QUIC 得到的效果與當初宣稱的完全相反，在所有的測試下都比 HTTP/2 + TLS 慢很多。

包括了在高速的網路下差了 45.2% (而且是網路愈快差距愈大)：

We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Moreover, the performance gap between QUIC and HTTP/2 grows as the underlying bandwidth increases.

以及在輕量的使用下也是 HTTP/2 + TLS 比較快，這邊提到包括各種桌機與手機環境，以及各種瀏覽器：

We observe this issue on lightweight data transfer clients and major web browsers (Chrome, Edge, Firefox, Opera), on different hosts (desktop, mobile), and over diverse networks (wired broadband, cellular).

讀完 PDF 的分析後，看起來是因為 TCP 大家花了很多精力在上面最佳化 50 年了，這邊累積的資產不只是軟體層級上面的最佳化，OS 與硬體上面也是有很多 offload 幫助。

而自己幹輪子的結果就是軟體層也還缺很多東西，硬體層也不支援新的協定...

透過 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 這點應該也算清楚。

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 的行為 (提前？)，畢竟讓他再做四個月的生意也是很危險？

超長網域名稱會遇到的 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)？

Chrome 124 啟用了 X25519Kyber768

在「Google Chrome's new post-quantum cryptography may break TLS connections」這邊看到的，出自「Q1 2024 Summary from Chrome Security」這邊的公告。

Chrome 124 預設啟用 X25519Kyber768 了：

After several months of experimentation for compatibility and performance impacts, we’re launching a hybrid postquantum TLS key exchange to desktop platforms in Chrome 124. This protects users’ traffic from so-called “store now decrypt later” attacks, in which a future quantum computer could decrypt encrypted traffic recorded today.

如果遇到問題的話可以在 chrome://flags 裡面的 #enable-tls13-kyber 關閉後重開瀏覽器... 不過應該是還好，大多數的 HTTPS server 應該都沒有實作 X25519Kyber768，就算是 Cloudflare 應該預設也是關的。

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 上，就很方便的可以監控服務：

挑一個點：