curl 8.22 新增 HTTP 訊息簽章：採用前先測試代理路徑
curl 8.22.0 於 2026 年 9 月 2 日發布，新增對 RFC 9421 HTTP Message Signatures 的實驗性支援。命令列用戶端可用 Ed25519 或 HMAC-SHA256 為選定請求元件簽章，libcurl 也提供對應的驗證與簽章選項。
這項能力讓接收端驗證 HTTP 請求中的特定屬性，但不會自動讓代理路線變得可信。curl 官方文件明確標記此功能為實驗性，並警告不要用於正式環境。將 curl 與正向代理、安全隧道、地區出口、重試或重新導向結合的團隊，應先確認「簽署的請求」與「驗證端收到的請求」是否一致。
curl 8.22 增加了什麼
新的命令列選項涵蓋四類輸入：
- 簽章演算法；
- 簽章金鑰或金鑰檔案；
- 讓驗證端查找金鑰的識別碼；
- 納入簽章的衍生元件與請求標頭。
若未指定元件清單，curl 預設簽署 method、authority、path，並在查詢字串存在時簽署 query。自訂清單可包含衍生元件與明確設定的請求標頭。官方文件也指出，標頭元件取自命令列明確提供的標頭；curl 自動加入的標頭即使出現在網路上，也不會因此自動納入簽章。
若應用希望保護 user agent、content type 或 content digest，就應明確設定與選取，再確認驗證端採用相同解讀。
為何代理路徑必須另外驗證
HTTP 訊息簽章只保護簽署者選定的元件，不會加密請求、授予資料使用權，也不會證明所有中介節點均按預期運作。
透過一般 CONNECT 通道存取 HTTPS 目標時，通道建立後的來源站請求通常位於端對端 TLS 內。代理負責驗證與轉送通道，訊息簽章則由目的端驗證。
其他架構可能終止、重建或轉換 HTTP。明確 HTTP 代理、反向代理、服務閘道、重新導向處理器或應用中介軟體，可能改變 authority、請求目標、路徑正規化、查詢順序或已簽章標頭。即使轉換合理，只要驗證端看到的簽章材料不同，驗證仍會失敗。
不要先假設「代理破壞簽章」。應在受控邊界蒐集去識別化證據，找出第一個不同的元件。
建立六條路徑相容矩陣
| 路徑 | 需要回答的問題 |
|---|---|
| 直接 HTTPS | 驗證端能否通過基準請求？ |
| HTTPS 經 CONNECT | 來源站收到的簽章元件是否相同？ |
| 明文 HTTP 經明確代理 | authority 與請求目標如何表示？ |
| 經代理重新導向 | 是否建立新請求，並按預期重新簽章？ |
| 請求重試 | 本文、摘要、時間與標頭是否一致？ |
| 地區或容錯移轉閘道 | 路由是否改變 authority、path、query 或標頭？ |
只使用自有或明確獲准測試的端點。驗證端應回傳有限結果，如有效、無效、缺少元件、未知金鑰識別碼或不支援演算法，不可回傳秘密材料。
安全執行命令列實驗
建立非正式環境測試金鑰，並避免進入指令歷史、日誌或共享成品。接著向受控驗證端傳送簽章請求：
curl --httpsig-algo ed25519 \
--httpsig-key @test-key.hex \
--httpsig-keyid test-key-01 \
--httpsig-headers "method authority path query content-type:" \
-H "Content-Type: application/json" \
--data '{"probe":"proxy-path"}' \
"$AUTHORIZED_VERIFIER_URL"此環境變數只能設定為已獲授權的驗證端。不可將正式金鑰直接寫入可能被保存的指令。
讓同一邏輯請求依序經過每條獲准代理路線。記錄 curl 版本、代理類型、位址族、要求地區、重新導向策略、簽章元件、驗證結果與本文雜湊。代理憑證、Cookie、簽章值及金鑰材料必須去識別化。
逐一測試元件邊界
Authority
確認驗證端使用的 authority 與簽署者目標一致。預設連接埠、明確連接埠、別名和閘道應分開測試。不可為了修正差異而廣泛信任任何主機。
Path 與 query
檢查百分比編碼、重複查詢欄位、空值、參數順序、結尾斜線與路徑正規化。多個程式庫產生 URL 時，語意相似的請求仍可能有不同位元組表示。
明確標頭
只選擇在預期路徑中穩定的標頭。若追蹤標頭由閘道加入，不要簽署一個用戶端不存在的值，再假設中介節點能修復。
本文與內容摘要
若應用保護 content digest，應一致地計算與設定。確認壓縮、序列化、傳輸編碼及重試不會重建不同本文。
把重新導向與重試視為新安全事件
重新導向可能改變 authority、path、query、方法或本文行為；重試可能發生於部分傳送後，也可能遇到憑證或時間資訊老化。不要將舊簽章自動複製到新建立的請求。
每類重新導向與重試都應規定：
- 用戶端是否允許跟隨；
- 新目的地是否仍在授權範圍；
- 哪些元件必須重新產生；
- 本文能否安全重播；
- 最大嘗試次數與總時間預算；
- 哪種結果必須停止工作流程。
可搭配代理重試預算指南，避免確定性的簽章失敗觸發無限制出口輪換。
分離金鑰與遙測
可觀測資料應協助定位元件差異，但不能洩漏秘密。可記錄 curl 建置版本、演算法名稱、金鑰識別碼、元件名稱、驗證結果、請求關聯編號、路線類別與去識別化錯誤原因。不要記錄私鑰、共享 HMAC 秘密、完整簽章標頭、有效代理憑證或敏感本文。
測試金鑰應有有限權限與明確停用日期，並依環境及擁有者隔離。HMAC 秘密由簽章端與驗證端共同持有；Ed25519 則允許驗證端只保存公開金鑰。
代理團隊升級清單
- 確認執行環境為 curl 或 libcurl 8.22.0 以上。
- 明確記錄 HTTP 訊息簽章仍為實驗功能。
- 建立受控驗證端與非正式環境金鑰。
- 定義真正需要保護的元件。
- 重要標頭必須先明確設定再納入簽章。
- 建立直接 HTTPS 基準。
- 視需要測試 CONNECT、明確代理、重新導向、重試、IPv4、IPv6 與地區路線。
- 比對 authority、path、query、標頭、本文摘要與驗證結果。
- 限制重試；確定性簽章失敗不得觸發自動輪換。
- 去識別化金鑰、簽章、憑證、Cookie 及敏感本文。
- 先透過有限金絲雀啟用。
- 任何正式環境決定前重新核對 curl 文件。
一般上線流程可參考代理試用驗收測試與代理直接回退偵測指南。
常見問題
HTTP 訊息簽章會加密請求嗎？
不會。它協助驗證選定元件。機密性與伺服器驗證仍依賴 TLS，存取授權也必須另行處理。
CONNECT 代理一定會讓簽章失效嗎？
不會。典型 HTTPS CONNECT 通道內的來源站請求位於 TLS 中，但閘道、重新導向和中介軟體可能產生不同結果，因此必須測試實際實作。
為何標頭出現在網路上卻未被簽章？
curl 的實驗性命令列功能會簽署明確提供且明確選取的標頭。自動產生的標頭不一定在簽章輸入內。
是否應立即在正式環境啟用？
不應。curl 將相關選項標示為實驗性，並警告不要用於正式環境。先在隔離環境評估，並持續追蹤後續版本說明。
合規說明
簽章請求與代理只能用於已獲授權的系統、帳戶、資料與地區。簽章證明選定請求屬性，不會授予權限、繞過速率限制或支持規避存取控制。保護金鑰與個人資料，遵守目標條款和供應商政策，遇到授權或政策失敗時停止。
來源說明：curl 專案《Changes in 8.22.0》及 curl 8.22.0 命令列手冊，發布於 2026 年 9 月 2 日。依 98IP 零外鏈規則，資料網址只保存在內部營運紀錄。
