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

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

在「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 有關？

在「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:// 變小，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 要弄六天的版本 (參考「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 在自動幫你塞 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 也是夠硬了...

在 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 可以抓。

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

在 Lobsters 上看到「Security Standards and Name Changes in the Browser Wars」這篇 2014 的文章，裡面提供了當初加密協定 SSL 變成 TLS 的由來。

當初 Netscape 弄出 SSLv2 後變得很熱門，但也發現了不少問題，所以微軟弄出自己的 PCT 準備競爭，不過後來 SSLv3 修掉了不少問題，加上 Netscape 當時的領先地位，IE 還是有支援 SSLv3。

接下來是大老們看到可能的分歧，找到關鍵人物開會取得共識，讓 IETF 來領隊：

And we negotiated a deal where Microsoft and Netscape would both support the IETF taking over the protocol and standardizing it in an open process, which led to me editing the RFC.

不過 SSLv3 把當時已知的問題都修掉了，但為了政治上的問題，故意小修了 SSLv3 裡面的東西，然後改名成 TLS：

As a part of the horsetrading, we had to make some changes to SSL 3.0 (so it wouldn't look the IETF was just rubberstamping Netscape's protocol), and we had to rename the protocol (for the same reason). And thus was born TLS 1.0 (which was really SSL 3.1). And of course, now, in retrospect, the whole thing looks silly.

差不多是三十年前的故事了...

月初 AWS 宣布 CloudFront 支援 HTTPS record，號稱可以加速 HTTPS 連線速度：「Boost application performance: Amazon CloudFront enables HTTPS record」。

這邊提到的加速主要來自於 HTTP/3，但傳統的作法會需要先用 TCP 的 HTTP/2 或是 HTTP/1.1 連線，在看到 Upgrade header 後才會用 HTTP/3。

而 HTTPS record 目前最大的用途是讓瀏覽器在 DNS query 時就知道可以用 HTTP/3，不需要透過 Upgrade header 得知，像是 www.google.com 就有 HTTPS record：

$ host -t https www.google.com
www.google.com has HTTPS record 1 . alpn="h2,h3"

不過 HTTP/3 是否比較快還有爭論，加上遇到 firewall 的 fallback 機制，說「boost」有點微妙，不過就當作宣傳詞吧... 至少 HTTP/3 發明的陣營是這樣宣傳的。

但 AWS blog 這篇用到的 CloudFront 看起來都沒打開啊：

$ curl -s https://aws.amazon.com/blogs/networking-and-content-delivery/boost-application-performance-amazon-cloudfront-enables-https-record/ | grep -io '[0-9a-z]*\.cloudfront\.net' | sort -u | xargs -n1 host -t https
d1d1et6laiqoh9.cloudfront.net has no HTTPS record
d1fgizr415o1r6.cloudfront.net has no HTTPS record
d1hemuljm71t2j.cloudfront.net has no HTTPS record
d1le29qyzha1u4.cloudfront.net has no HTTPS record
d1oqpvwii7b6rh.cloudfront.net has no HTTPS record
d1vo51ubqkiilx.cloudfront.net has no HTTPS record
d1yyh5dhdgifnx.cloudfront.net has no HTTPS record
d2908q01vomqb2.cloudfront.net has no HTTPS record
d2a6igt6jhaluh.cloudfront.net has no HTTPS record
d2cpw7vd6a2efr.cloudfront.net has no HTTPS record
d36cz9buwru1tt.cloudfront.net has no HTTPS record
d3borx6sfvnesb.cloudfront.net has no HTTPS record
d3ctxlq1ktw2nl.cloudfront.net has no HTTPS record
d3h2ozso0dirfl.cloudfront.net has no HTTPS record
d7umqicpi7263.cloudfront.net has no HTTPS record
dftu77xade0tc.cloudfront.net has no HTTPS record
dgen8gghn3u86.cloudfront.net has no HTTPS record
dk261l6wntthl.cloudfront.net has no HTTPS record

想要找個 CloudFront 有 HTTPS record 的看一下，發現好像都沒找到... 反倒是發現 CloudFront 的 distribution hostname 長度有變？

另外是看文章時意外覺得不太對，發現是這篇介紹文章裡面用的圖片出現了 Comic Sans？(Comic Neue？)

唔，滿滿的槽點...

之前 nginx 要使用 ACME 協定拿到 TLS certificate (像是 Let's Encrypt) 需要透過另外的程式處理，像是 Certbot (官方推薦的) 或是 Dehydrated (我自己愛用的)，這次 nginx 則是宣佈可以在 web server 透過 HTTP-01 申請 TLS certificate 了：「NGINX Introduces Native Support for ACME Protocol」。

在這之前，在 web server 上面可以直接走 HTTP-01 申請的應該就是 Caddy，不過早期 binary 是非開源的 (但 source 本身還是用 Apache License 2.0 放出來)，但後來到 2019 年的時候全部改 Apache License 2.0 了：「Caddy Server 要採用 Open Source...」，在這之後有看到不少人開始嘗試用 Caddy... 但我應該是今年才跳進去的？

回到 nginx 的設定部分，可以看到目前官方的範例是這樣，還是露出了實作上的細節 (cache 的設定)，另外有點怪，server_name 部分不確定是什麼：

server { 

    listen 443 ssl;

    server_name  .example.com;

    acme_certificate letsencrypt;

    ssl_certificate       $acme_certificate;
    ssl_certificate_key   $acme_certificate_key;
    ssl_certificate_cache max=2;
}

整體算是往好的方向走，再過個幾版對這些設定調整一下，加上也有計畫要支援 DNS-01 的認證方式，到時候 wildcard domain 也可以掛上去，應該會更好用。

前幾天頗熱門的消息，StarDict 的預設安裝下，會將剪貼簿的內容透過 HTTP 傳到中國的伺服器上：「StarDict sends X11 clipboard to remote servers (lwn.net)」，文章是 LWN 的付費內容，所以連結是 SubscriberLink 分享出來的：「StarDict sends X11 clipboard to remote servers」。

整串 mailing list 上的討論可以在「Debian Bug report logs - #1110370 stardict-plugin: CVE-2025-55014: YouDao plugin sends the user's selection from other apps to Chinese servers」這邊看到，不長但有不少訊息透露出來。

其中一個點會發現這個套件不是第一次了：

• 2009 年的「Debian Bug report logs - #534731 stardict broadcasts clipboard context over network」，
• 2011 年的「Debian Bug report logs - #613236 stardict: Always uses Dict.cn even when net dictionnaries are disabled」，
• 2015 年的「Debian Bug report logs - #806960 Stardict leaking user data in default configuration.」，
• 這次 2025 年的「Debian Bug report logs - #1110370 stardict-plugin: CVE-2025-55014: YouDao plugin sends the user's selection from other apps to Chinese servers」。

可以看到類似的問題不斷的在重複發生。

另外一個問題是現任 maintainer 的問題，在 id=44879832 提到的：

It's clearly a defensive excuse, as it is extremely unrealistic to expect final users to read all the docs of all the dependencies of a Linux distro. It's the responsibility of the maintainer to read the subset of docs relevant to the package(s) they're contributing, not the user's.

It could be that they were caught with their pants down and posted an ill-thought response, but I'd lean strongly towards malice with such a poor defense, it borders on confession. Clipboards are one of the most critical privacy/security features, you don't ever want to leak them unintentionally.

在 id=44889789 則是更清楚描述了信任關係：

> It's the responsibility of the maintainer to read the subset of docs relevant to the package(s) they're contributing, not the user's.

I agree a lot with this. You're supposed to trust your distributions packages. If you can't trust your distro, who can you trust? If you don't, find one you do trust, as that's a viable alternative. If none are trustworthy to you, then the only real option is to become your own package maintainer and have fun with Linux From Scratch.

使用這個 distribution (這邊是 Debian)，代表你需要信任這個 distribution，而這次的情況可以看出，身為這個 distribution 的 official package maintainers 之一，對於 privacy issue report 處理的態度已經是 malicious behavior 的等級了。

現在事情被鬧大的以後，才「計畫」要在 3.1 拆出來 (2025/08/09 的回覆)，但現在都已經過一個禮拜了，可以從 https://packages.debian.org/search?keywords=stardict 這邊看到完全沒看到 3.1，大概會被三催四請後才丟出來。

在 Hacker News 首頁上看到「Certificates for Onion Services (torproject.org)」這篇，提到了 Tor 的 onion service (hidden service) 上申請 TLS certificate 的需求：「Certificates for Onion Services」。

四年前寫過「讓 Tor 的 .onion 支援 HTTPS」這篇有提到這件事情，看起來後面沒有太多進展？

Tor 的 onion service 在 v3 後，網址本身就是 public key 了 (在「Onion Service 第二版的退場計畫」這邊有提到)，可以直接放下 256-bit 的 ed25519 public key：

The most obvious difference between V2 and V3 onion services is the different address format. V3 onion addresses have 56 characters instead of 16 (because they contain a full ed25519 public key, not just the hash of a public key), meaning that migrating from V2 to V3 requires all users to learn/remember/save a new onion address address.

但上 TLS certificate 還是有很多好處，第一個馬上想到的是 browser 有很多 API 只支援在 https:// 的情況下才能使用：

Some browser features are available only with HTTPS, like Secure Contexts, Content Security Policy (CSP), Secure cookies, WebAuthn, WebRTC and PaymentRequest.

另外一個是 HTTP/2 雖然在「規格上」有支援 plaintext 模式，但「實作上」只有支援 HTTPS 模式，而 HTTP/2 的速度會比 HTTP/1.1 快不少：

Allows for the usage of HTTP/2, since some browsers only support it if on HTTPS. In the future, HTTP2 and HTTP3 may only work with TLS, and thus valid certificates.

這兩點對於透過 Tor 的應用來說幫助蠻大的，看看這波討論能不能再推動一些進度...

目標是希望把 Port 443 同時用在 HTTPS 網站以及 HTTPS Proxy (i.e. 瀏覽器到 Proxy 中間有加密的協定)，其中 HTTPS Proxy 是跑 Squid，本來是用 nginx 做這件事情 (透過 ngx_stream_ssl_preread_module 的 ssl_preread_server_name 判斷 hostname)，但遇到了 nginx 無法動態決定是否要啟用 proxy_protocol 的問題：「How to set the proxy_protocol to 'on' in a conditional manner in nginx?」，不確定是 bug 還是 feature。

第二個問題是 Squid 對 proxy protocol 的支援是透過 require-proxy-header 指定在 http_port 上的，而 https_port 不支援這個參數，也就是說在配合這個情境下，如果還想讓 Squid 可以記錄正確的 IP address 資訊，就需要讓 nginx 解 TLS，用 HTTP Proxy 協定丟進 Squid，這個也就是 TLS termination。

最後遇到的問題是 nginx 這邊的「網站端 vhost」會記錄到錯誤的 IP address，永遠是 127.0.0.1，這個問題卡了一年多沒解我就放掉了，剛好發現 Raspbery Pi 3B 上面跑的是 32-bit 版的 OS，就想說趁著重裝 64-bit 版的 OS 後改用 Caddy。

Caddy 這邊目前是透過 github.com/mholt/caddy-l4 這個模組實作「讀取 TLS SNI 資訊決定後續行為」，我是透過 xcaddy 編譯 Caddy 裝起來的，裝好後需要的設定是這樣：

        layer4 {
                :443 {
                        @proxytwhinet tls sni proxy-tw-hinet.gslin.com
                        route @proxytwhinet {
                                tls {
                                        connection_policy {
                                                alpn http/1.1
                                        }
                                }
                                proxy {
                                        proxy_protocol v1
                                        upstream 127.0.0.1:3128
                                }
                        }

                        route {
                                proxy {
                                        proxy_protocol v1
                                        upstream 127.0.0.1:444
                                }
                        }
                }
        }
        servers 127.0.0.1:444 {
                listener_wrappers {
                        proxy_protocol {
                                allow 127.0.0.1/32
                                fallback_policy require
                        }
                        tls
                }
        }

看到 proxy-tw-hinet.gslin.com 後往 127.0.0.1:3128 丟，其他的都往 127.0.0.1:444 丟。

這邊有個比較特別的是針對 proxy-tw-hinet.gslin.com 要強制走 HTTP/1.1 協定，這是因為 Squid 這端的 http_port 不吃 HTTP/2，而 Firefox 連 HTTPS Proxy 時讀到 Caddy 透過 ALPN 說可以用 h2，於是就不會通，所以針對這個 domain 我只收 HTTP/1.1。

再來就是網站的部分，127.0.0.1:444 都要吃 proxy protocol 的 IP address 資訊。

而每個網站實際定義的部分則是這樣，裡面把不相關的設定都刪掉了：

proxy-tw-hinet.gslin.com:444 {
        tls caddytls@gslin.com
        [...]
}

rent-hinet.gslin.com:444 {
        tls caddytls@gslin.com
        [...]
}

接下來是 Squid 這邊，主要就是 require-proxy-header 以及允許哪些來源的 IP address 才是合法的：

http_port 3128 require-proxy-header
proxy_protocol_access allow localhost

當初就只差記錄正確的 IP address，為了做到改下去這包工程好大，但總算是都搞定了...

tab 上放蠻久的工具 httpjail，可以 MITM 攔截 HTTPS 連線，依照設定的邏輯，或是掛進來的 javascript script 邏輯處理連線。

目前支援 macOS 與 Linux，然後有不同的限制：

看起來可以省掉自己搞 CA 與 isolated environment 的功夫。

軟體發展蠻快的，上次看到跟這次看到發現補了不少文件？

在「HTTPS by default (via)」這邊看到一年後的版本 (2026/10) 要預設 HTTPS only 了：

One year from now, with the release of Chrome 154 in October 2026, we will change the default settings of Chrome to enable “Always Use Secure Connections”. This means Chrome will ask for the user's permission before the first access to any public site without HTTPS.

2015/09/14 的時候 Let's Encrypt 生出了第一個 domain，所以大約花了十一年的時間讓主流瀏覽器預設開 HTTPS only。

上禮拜看到的文章，作者在 AWS 上面只用 25.5 個小時就爬了 1B 個頁面，在 tune 過效能後的成本是 US$462：「Crawling a billion web pages in just over 24 hours, in 2025 (via)」。

作者在文章裡面有提到一篇 2012 年的「How to crawl a quarter billion webpages in 40 hours」，當時用了 39.5 個小時左右，花了 US$580 爬了 250M 個頁面：

For some reason, nobody’s written about what it takes to crawl a big chunk of the web in a while: the last point of reference I saw was Michael Nielsen’s post from 2012.

這次是純 HTML (沒有 JavaScript)，在 2012 年的文章沒有特別提，應該也是沒有在管 JavaScript：

HTML only. The elephant in the room. Even by 2017 much of the web had come to require JavaScript. But I wanted an apples-to-apples comparison with older web crawls, and in any case, I was doing this as a side project and didn’t have time to add and optimize a bunch of playwright workers.

裡面有提到幾個有趣的問題，一個是 parsing 的部分其實很吃 CPU，會是瓶頸之一，主要的原因是現在頁面比 2012 年大許多了，中位數與平均數都大很多：

Profiles showed that parsing was clearly the bottleneck, but I was using the same lxml parsing library that was popular in 2012 (as suggested by Gemini). I eventually figured out that it was because the average web page has gotten a lot bigger: metrics from a test run indicated the P50 uncompressed page size is now 138KB, while the mean is even larger at 242KB - many times larger than Nielsen’s estimated average of 51KB in 2012!

他的解法是換 parsing library，從 lxml 換成 selectolax，效能有巨大的提升：

I switched from lxml to selectolax, a much newer library wrapping Lexbor, a modern parser in C++ designed specifically for HTML5. The page claimed it can be 30 times faster than lxml. It wasn’t 30x overall, but it was a huge boost.

另外一個就是 HTTPS 的 handshake overhead 了：

That said, one part of fetching got harder: a LOT more websites use SSL now than a decade ago. This was crystal clear in profiles, with SSL handshake computation showing up as the most expensive function call, taking up a whopping 25% of all CPU time on average, which - given that we weren’t near saturating the network pipes, meant fetching became bottlenecked by the CPU before the network!

從 Chrome 的 telemetry 可以看出來 HTTPS 的成長速度，這邊比較重要的時間點是 Let's Encrypt 在 2015 年十月的時候透過 IdenTrust 的簽名讓現有的瀏覽器支援 Let's Encrypt：

所以現在的硬體與技術對於 raw data 的取得已經不是太大的問題了 (甚至 2012 年的時候就已經是可行的了...)。

看到 ECH 變成 Standards Track 了：「RFC 9849 TLS Encrypted Client Hello (via)」。

瀏覽器都在 2023 的下半年預設啟用了 (Firefox 119 是 2023/10/24，Chromium 117 是 2023/09/12)。

ECH is enabled in Firefox by default since version 119, and is recommended by Mozilla to be used along with DNS over HTTPS. In September 2023, Chromium version 117 (used in Google Chrome, Microsoft Edge, Samsung Internet, and Opera) enabled it by default, also requiring keys to be deployed in HTTPS resource records in DNS.

而 server 端看起來最近也都支援了：nginx 的「Encrypted Client Hello Comes to NGINX」、Caddy 的「Automatic HTTPS」。

這個算是基礎建設，再降低可被偵測到的部分。從 ESNI 走到 ECH 這樣也五六年了：

• 中國開始擋 ESNI 了...
• Cloudflare 改推 ECH 加密整個 TLS 的 ClientHello
• Firefox 也打算淘汰 ESNI，改推 ECH
• T-Mobile US 打算要賣使用者的瀏覽記錄了
• 英國的 ISP 開始記錄使用者的連線資訊
• Cloudflare 正式推出 ECH (Encrypted Client Hello)

在「API Shouldn't Redirect HTTP to HTTPS (jviide.iki.fi)」這邊看到的，原始文章在「Your API Shouldn't Redirect HTTP to HTTPS」這邊。

仔細想一下沒錯，API 應該要一開始就被正確設定，所以要 fail fast。

另外在 id=40505525 這邊還提到了透過 HTTP 的 token 會自動被 revoke 掉，這個作法也很漂亮：

The Stack Exchange API used to revoke API keys sent over HTTP (and return an error message), which is my favorite way to handle this.

另外一個想法是直接不聽 port 80，不過這點在 Endpoint 的 IP 不是自己專用的情況下不一定能做到 (像是大多數的 CDN 環境)。

的確有戳中我手上預先準備好的 nginx config，來想看看怎麼改會比較好... 也許改成整個傳回 403，只開 /.well-known/acme-challenge/ 讓 ACME (Let's Encrypt) 的 HTTP-01 認證可以過。

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

這幾個連續的改變可以一起看，應該是 Amazon S3 團隊在 review 同一包東西時一併做出來的。

首先是五月的時候有寫到的「Amazon S3 改變 403 的收費方式」，當時的其中一個公告在這邊：「Amazon S3 will no longer charge for several HTTP error codes」，主要就是針對非自己帳號的 Amazon S3 不再收費，然後這幾天公告總算是全部改完了：「Amazon S3 no longer charges for several HTTP error codes」。

後續是針對自己帳號產生的 403 會提供更多細節資訊，這樣可以讓找問題的過程更容易：「Amazon S3 adds additional context to HTTP 403 Access Denied error messages」。

Amazon S3 now includes additional context in HTTP 403 Access Denied errors for requests made to resources within the same AWS account.

This new context includes the type of policy that denied access, the reason for denial, and information on the AWS IAM user or role that requested access to the resource.

不過看起來過去將近二十年的吃進去不會吐出來就是了...