站在路徑之外：介紹 ticketconnect
我們在這裡寫的大多是關於如何進入一條 TLS 連線、以便升級它的密碼學—inline、redirect 或 proxy。這三者每一個都站在路徑上的某處。還有第四種做法，它完全不站在路徑上；今天我們把它開源釋出：ticketconnect。
那些你動不了的端點
後量子密碼學正照著時程表到來，而它一再撞上同一道牆：那條你動不了的端點長尾。一整批跑在 OpenSSL 上的老舊服務，既無法協商 X25519MLKEM768，也來不及在期限的時間表內重新編譯、重建映像檔、重新部署。你無法把一個無法重新編譯的東西升級到後量子。
用恢復連線的方式進場
ticketconnect 倚賴 TLS 1.3 的一個特性：PSK 恢復（resumption）的工作階段金鑰是從票證推導出來的，而不是來自一次全新的金鑰交換。所以只要一個老舊客戶端以一張來自後量子握手的票證恢復連線，那條連線就是由抗量子的金鑰材料所保護—即使客戶端本身從未協商過 PQC。
而它做到這件事，完全不用改動客戶端。一個節點代理程式替客戶端完成它做不到的 X25519MLKEM768 握手，並把得到的恢復用工作階段直接安裝進客戶端自己的行程裡。客戶端的下一條連線就這麼恢復了—用上一把它從未要求過、以 PQC 為根的 PSK。全程在資料路徑之外：沒有 proxy、沒有 socket、沒有設定、也不用重建映像檔。部署一個 DaemonSet，整批機隊的連線就開始以後量子恢復。
只用公開 API
這是我們最自豪的地方。一支 eBPF uprobe 攔截 SSL_connect 並短暫凍結該執行緒；接著透過 ptrace 完成安裝，全程只用公開的 OpenSSL API（d2i_SSL_SESSION 與 SSL_set_session）—絕不碰任何私有結構的偏移量（offset）。
這一條限制，一次消解了三個問題：
- 不需要逐版本的偏移量資料庫。我們呼叫的函式都是匯出的（exported），因此存在於函式庫的
.dynsym—動態符號表；由於動態連結需要它，它在 strip 之後依然存在。函式庫等於自帶了一份位址對照表，我們在執行期讀出來即可。 - 沒有記憶體破壞這一整類臭蟲。我們從不在猜來的偏移量上寫入欄位；寫入是由 libssl 自己、經過驗證的程式碼完成的。壞掉的資料只會讓它回傳
NULL，不會破壞任何東西。最壞的情況是「沒升級」，而不是「行程壞掉」。 - 相容性面積極小—只剩下少數幾種序列化格式、而且失敗即關閉（fail-closed），而不是每個二進位建置各配一份簽章。
它全程失敗即關閉，而且不做無聲降級：一次未命中就退回一般 TLS，並發出一個事件。在線路上，那向來是唯一值得信任的真相。
是證明，不只是展示
我們在意的是不誇大，所以這些主張是被驗證出來的，而不是被宣稱出來的。在一個真實的 Kubernetes 叢集上，一個未經修改、不斷重連的客戶端原本做的是完整握手—接著，就在代理程式部署上去、且客戶端一行都沒改的那一刻，它的連線變成了連續 111 次 X25519MLKEM768 恢復。封包擷取證明了恢復所用的那張票證，與代理程式取得的那一張逐位元組相同；而一組對照實驗顯示，客戶端自己是無法恢復的。所以那確實是被注入的票證，不是巧合。
它是什麼、不是什麼
ticketconnect 是一個誠實、實驗性的 v1—它是一座合規與密碼敏捷性的橋樑，為老舊機隊爭取時間，好讓真正的端點遷移能在數年間慢慢完成；它不是那件事的替代品。目前它只支援 OpenSSL 與 x86-64、單一目的地、且以恢復為基礎（連到一個尚未預熱的目的地時，第一條連線仍是傳統握手）。而它是一個具特權、涵蓋整個節點的代理程式，因此值得用對待任何 eBPF/ptrace 工具的同等審視。我們寧可把這些話講清楚，也不願過度推銷。
它是開源的
ticketconnect 採 MIT 授權，放在 GitHub 上，附有設計文件、安全模型與容器映像檔。你可以在單一主機、用一行指令親眼看整件事發生：
git clone https://github.com/connectedinformation/ticketconnect
cd ticketconnect && ./demo/run_host_demo.sh我們的 inline 方案站在路徑之中，而 ticketconnect 站在行程之旁。兩者都是在替一條「無法自行協商後量子保護」的連線補上那份保護—你就挑一個符合「你被允許動哪裡」的做法。如果你正在做 PQC 遷移，我們很歡迎你來看看它、包括你覺得它哪裡不對的地方：github.com/connectedinformation/ticketconnect。
← 所有文章