部落格
關於 TLS、後量子密碼學與內聯攔截的技術筆記—從位元組層級談起。
為什麼我們稱它為「接合」（splice）
這是我們試的第三個名字—先 split、再 bridge、最後 splice。為什麼前兩個詞，各對一個「把兩條 TLS 連線接起來、並在中間轉換密碼學」的東西說了一個小謊，而被捨棄的名字仍在程式碼裡化石般留存。一段取材自 git 的詞源考據。
我們的代理程式拒絕信任了三週的那個 CA
一個代理程式在每一條連線上拒絕了一張完全有效的上游憑證，整整三週。憑證沒問題；主機信任那個 CA。代理程式在開機時讀過一次信任庫，之後再也沒讀。當重啟就能修好，你看到的就是過期的記憶體狀態。
1.2 KB 問題：後量子如何撐破 ClientHello
開啟 PQC，部分連線就失敗—不是密碼學錯誤，而是交握進行到一半卡住或重置。ML-KEM 金鑰交換把 ClientHello 撐過 MTU，於是它跨越多個 TCP 區段，假設只有一個區段的設備就出錯。為什麼它看起來像網路不穩，又為什麼它是遷移的第一隻金絲雀。
為什麼是混合式後量子，而非純 ML-KEM
如果 ML-KEM 才是具量子抵抗力的演算法，為什麼要部署 X25519MLKEM768、還拖著傳統的 X25519？混合式不是把量子安全加倍—X25519 提供的後量子保護是零。它真正的工作，以及那個精確的風險權衡，就顯現在兩個密鑰如何在封包上結合。
後量子 TLS 遷移：實務指南
密碼學是容易的部分—NIST 已經做完了。把 TLS 遷移到後量子實際上要做些什麼，一步一步：設定期限的法令、後量子在封包上的樣貌，以及盤點 → 遷移 → 舉證的順序—包含那條你碰不到的長尾端點。
M-23-02 究竟要求什麼：解碼到封包層的現實
這份聯邦後量子備忘錄常被讀成「現在就部署 PQC」。其實不然—它近期具約束力的要求，是盤點易受量子攻擊的密碼學，而那解碼後就是每次交握的一個欄位。為什麼這首先是個可觀測性問題，以及為什麼設定檔無法回答它。
0x4588 ≠ 4588：一個讓後量子從我們自己儀表板上消失的單字元錯誤
一個十六進位／十進位的失誤，讓每個 ClientHello 都宣告了未被指派的金鑰交換群組—而三層疊加的失誤把它藏了數週。這個故事，以及為什麼封包才是唯一的真相來源。
一條連線、兩次交握：在不更動端點的情況下升級 TLS 加密
一條 TLS 連線如何在傳輸途中升級其加密—兩次獨立的交握、兩套金鑰排程，以及為什麼憑證才是關鍵所在。
逐位元組解析 X25519MLKEM768：封包層上的後量子金鑰交換
後量子金鑰交換在一條 TLS 1.3 連線上真正的樣貌—代碼點、1.2 KB 的金鑰交換、位元組順序，以及如何用一行 openssl 指令驗證。