HTTP/3 + QUIC 的效率問題

September 10, 2024, 2:35 am

≫ Next: Python 下追蹤程式建立哪些 HTTP(S) 連線的工具：httpdbg

≪ Previous: Amazon S3 對於錯誤處理的幾個改變

$

0

0

前天看到討論蠻熱烈問題，提到了 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 幫助。

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

---

Python 下追蹤程式建立哪些 HTTP(S) 連線的工具：httpdbg

September 25, 2024, 10:47 pm

≫ Next: Apple 提案要再將 TLS certificate 的有效期降到 45 天？

≪ Previous: HTTP/3 + QUIC 的效率問題

$

0

0

在「Show HN: Httpdbg – A tool to trace the HTTP requests sent by your Python code (github.com/cle-b)」這邊看到的，看起來是作者自己貼到 Hacker News 上的。

作者開發了 httpdbg 套件，可以看 Python 程式有哪些 HTTP(S) 連線，看起來對於開發追蹤還蠻好用的。

從官網可以看到支援了常見的 HTTP(S) library，包括常用的 requests 以及其他套件。

不過特地想提的是看到 urllib3 這個套件，第一次看到這個東西... 這名字看起來就跟以前 Python 2 年代時搞出來的 urllib 以及 urllib2 有關？

Apple 提案要再將 TLS certificate 的有效期降到 45 天？

October 17, 2024, 1:41 pm

≫ Next: X (Twitter) 隱藏推文裡面連結中的 https:// 以及參數的方法

≪ Previous: Python 下追蹤程式建立哪些 HTTP(S) 連線的工具：httpdbg

$

0

0

在「Sysadmins rage over Apple’s ‘nightmarish’ SSL/TLS cert lifespan cuts」這邊看到的，提案細節可以在 GitHub 上看到：「SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods #553」。

這馬上讓我想到 2020 年當時 Apple 的獨幹行為，然後其他瀏覽器廠商也跟進：「TLS 憑證的最長時效將從 825 天降到 398 天」。

另外補上 2017 年的時候，TLS certificate 決定從 1185 天 (約 39 個月) 降到 825 天 (約 27 個月) 當時寫下的記錄：「未來 SSL Certificate 的最大有效時間將降到 825 天」。

將低有效期通常被提出來的考量是避免 key 在秘密洩漏後沒發現，但我一直覺得這個理由是個假議題：你沒有找出洩漏的原因，後續的 key 還是存在一樣的風險。

另外一個也常被提出來的原因是 revoke 的成本太高，但邏輯不通：遇到 leak 就是需要 revoke，沒有放在那邊擺爛等過期的，所以你本來就會需要設計 revoke 的機制。

我覺得合理的原因只有對簽名演算法的攻擊有重大進展時 (像是目前在用的 RSA 或是 ECC)，這時候就得更新簽名演算法的要求了。

考慮到這個理由，從超長的八年降到三年，然後再降到兩年，我覺得都還算合理 (而且也可以看到 CA 方在投票也沒有反對)。

後來降到一年我覺得時程上有點緊張，對於極度嚴謹的單位，security library 的更新會牽扯到 compliance 甚至是 auditing，然後後續的改寫以及測試也會有類似的問題，但大方向我覺得還可以。

但這次提案降到 45 days，我的解讀是要打擊手動更換憑證的手段，這個就值得商榷了：能夠用 ACME 之類的手段自動更新當然很好，但否定手動更新的需求是否合理？

接下來看看其他瀏覽器與 CA 的表態了...

X (Twitter) 隱藏推文裡面連結中的 https:// 以及參數的方法

December 29, 2024, 12:58 am

≫ Next: Let's Encrypt 的六天有效 TLS certificate 計畫

≪ Previous: Apple 提案要再將 TLS certificate 的有效期降到 45 天？

$

0

0

好像從某次 X (Twitter) 改版後就覺得奇怪，怎麼把 https:// 變小，designer 不會覺得很醜嗎：

(原推文在 https://x.com/hikki_staff/status/1872914498857869700 這邊)

剛剛想要自己下 usercss 把 font-size 調回來，才發現這邊的字型大小設定成 0.001px，馬上想到「這樣不是應該不會出現嗎」：

接著就想到我在瀏覽器裡面有額外設定 minimal font size，所以 font-size: 0.001px 被壓回 minimal font size 了，才導致看起來大小不同：

不曉得這樣設計的好處是什麼，不用 display: none; 可能是為了 SEO 或是 accessibility？因為現在的 bot 已經看得懂 display: none; 了？

Let's Encrypt 的六天有效 TLS certificate 計畫

January 16, 2025, 3:06 pm

≫ Next: 在 Linux 下 MITM 的 httptap

≪ Previous: X (Twitter) 隱藏推文裡面連結中的 https:// 以及參數的方法

$

0

0

先前提過 Let's Encrypt 要弄六天的版本 (參考「Let's Encrypt 要嘗試六天的 TLS certificate」)，剛剛在 Lobsters 與 Hacker News 上都看到新消息了：「Announcing Six Day and IP Address Certificate Options in 2025」。

先前在想為什麼要推出六天的憑證？用 CRL 不夠好嗎？這次倒是給出個有趣的概念，之前沒想過這個方面：「因為有效期夠短，所以直接拿掉 revoke 機制」。

Our six-day certificates will not include OCSP or CRL URLs.

我以為 CA/Browser Forum 的 BR (Baseline Requirements for TLS Server Certificates) 強制要求 revoke 機制，不過翻資料的時候翻到這個：

4.9.1.1 Reasons for Revoking a Subscriber Certificate
The CA MAY support revocation of Short-lived Subscriber Certificates.

然後 short-lived 的定義目前是 10 天以下，明年三月會降到 7 天以下 (okay，所以 Let's Encrypt 弄了六天的設計)：

Short-lived Subscriber Certificate: For Certificates issued on or after 15 March 2024 and prior to 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 10 days (864,000 seconds). For Certificates issued on or after 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 7 days (604,800 seconds).

看起來 CA/Browser Forum 對於 short-lived certificate 只用了 MAY 的要求，的確接受沒有 revoke 機制。

回到原來 Let's Encrypt 的說明，看起來二月會先測試 (內測？)，再來是四月讓一些外部的人測試 (封測？)，最後是年底前的 GA (公開上線)：

We expect to issue the first valid short-lived certificates to ourselves in February of this year. Around April we will enable short-lived certificates for a small set of early adopting subscribers. We hope to make short-lived certificates generally available by the end of 2025.

另外一個是簽 IP address 的 TLS certficiate，看起來會是以 short-lived certificate 為前提計畫：

The earliest short-lived certificates we issue may not support IP addresses, but we intend to enable IP address support by the time short-lived certificates reach general availability.

這包看起來是將現有的 revoke 機制當作是 workaround，所以朝著拿掉 revoke 機制的設計走。當初 OCSP 的 stapling (以及 must stapling 機制) 沒有發揚光大有點可惜...

在 Linux 下 MITM 的 httptap

February 5, 2025, 1:00 pm

≫ Next: 不該用 DoH (DNS over HTTPS) 的原因

≪ Previous: Let's Encrypt 的六天有效 TLS certificate 計畫

$

0

0

這兩天看到的有趣東西，可以在 Linux 在自動幫你塞 root CA，然後自動 MITM 攔截 HTTPS 連線的工具：「Httptap: View HTTP/HTTPS requests made by any Linux program (github.com/monasticacademy)」，GitHub 專案頁在 monasticacademy/httptap 這邊。

在「How it works」這邊說明了用到的技術，把程式放到獨立的網路環境去跑，這樣就可以攔截 HTTPS 連線：

Httptap creates a TUN device and runs the subprocess in an environment in which all network traffic is routed through that device.

也因為是直接處理 raw packet，變成要實作 TCP stack (至少一部分)：

The traffic from the network device is delivered to us as raw IP packets. We must parse the IP packets as well as the inner TCP and UDP packets, and write raw IP packets back to the subprocess. This requires a software implementation of the TCP/IP protocol, which is by far the most difficult part of httptap. The TCP/IP implementation in httptap is missing many aspects of the full TCP protocol, but still works reasonably well for its purpose.

但這樣只能看到加密過後的 HTTPS traffic，為了要看到裡面的內容，httptap 在跑起來的時候會產生一組 root CA 塞進隔離環境裡面，這組 root CA 可以在後續要對 HTTPS 連結 MITM 用的：

When httptap starts, it creates a certificate authority (actually a private key plus a corresponding x509 certificate), writes it to a file on the filesystem visible only to the subprocess, and sets a few environment variables -- again only visible to the subprocess being run -- that add this certificate authority to the list of trusted certificate authorities. Since the subprocess trusts this certificate authority, and httptap holds the private key for the certificate authority, it can prove to the subprocess that it is the server which which the subprocess was trying to communicate. In this way we can read the plaintext HTTP requests.

這樣大多數的情況下都可以抓出來 (只要沒遇到 certificate pinning 的情境)，值得記錄起來，之後用的到的場景比較容易想起來...

話說自己刻部分的 TCP stack 也是夠硬了...

不該用 DoH (DNS over HTTPS) 的原因

June 8, 2025, 10:46 am

≪ Previous: 在 Linux 下 MITM 的 httptap

$

0

0

在 Lobsters 上看到的連結，2018 年的文章提到不要用 DNS over HTTPS：「Why not use DNS over HTTPS (DoH)?」。

最後一段蠻有趣的，提到了過度包裝的問題，當初看到 DNS over HTTPS 時就在想為什麼不走 DNS over TLS 就好：

But the protocol itself is a good idea

No, it is not. Abusing HTTP as a transport protocol for DNS data adds a unneeded complexity to the protocol. You must add a HTTP module to all DNS servers or interact with a separated HTTP server on the same system in order to support DoH. That is a lot of code which can contain a lot of bugs and security flaws. Complexity is the enemy of security.

另外就可以自己延伸想到不少東西，像是 DNS over HTTPS 多了太多東西可以被 fingerprint，相比於 DNS over TLS 只有 TLS library 的 fingerprint 可以抓。

另外就是打散足跡的概念，不要讓單一單位有過多的記錄，降低記錄被組合成資訊的機率。