網版印刷風網際網路閘道精確區分有效安全指令與相似但無效的標記

curl 8.22.0 改變了 HSTS 解析器辨識指令名稱的方式:已知名稱現在必須完整比對一個 token,不能只比對前綴。該版本於 2026 年 9 月 2 日發布,相關 curl 專案修復在 8 月下旬完成。

問題說明列出兩種具體影響:以 includeSubDomains 開頭的相似名稱可能被當成真正指令;以 max-age 開頭的相似名稱則可能干擾後續有效 max-age 指令的處理。修正後的解析器把更長的相似名稱視為未知指令,並依語法繼續處理真正被辨識的指令。

這對代理蒐集和驗證系統很重要,因為 HSTS 決策發生在用戶端。快取政策可能在代理協商前就把 HTTP URL 升級為 HTTPS,進而改變目標協定、連接埠、CONNECT 行為、TLS 交握與連線池鍵,即使輸入 URL 沒有變化。

curl 8.22 改了什麼

curl 發布說明將修復概括為 HSTS 精確字串比對。相關變更說明舊行為使用不區分大小寫的前綴比較;新版本先擷取完整指令名稱,再與已知名稱進行完整比較。

因此解析結果更精確且更可預測:完全符合的有效指令維持其定義;只以有效名稱開頭的較長 token 被視為未知;相似名稱不應啟用子網域政策,也不應阻止後續真正有效的指令被處理。

這是解析正確性修復,不代表可以降低 TLS 驗證或忽略異常回應標頭。升級後仍需驗證應用程式依賴的具體行為。

為什麼代理工作流程需要回歸

HSTS 狀態由 HTTP 用戶端持有,不由代理出口 IP 決定。用戶端將請求升級為 HTTPS 後,HTTP 代理可能收到 CONNECT,而不是一般 HTTP 請求;SOCKS 路徑也可能承載不同目標連接埠。TLS 政策、憑證驗證和連線重用接著都會作用於升級後的目標。

相關合法情境包括地區可用性檢查、需要保留協定與重新導向軌跡的廣告驗證、跨工作程序重用 HSTS 快取的網頁蒐集、透過多條授權路由重放 URL 的市場研究,以及升級 libcurl 卻沒有區分舊快取狀態的長期服務。

這不表示所有工作都應清空 HSTS,而是必須用受控回歸將解析、快取政策、代理路由和來源站行為分開。

建立安全回歸環境

使用組織自有的主機名稱、HTTPS 端點、憑證及代理路由,不要向第三方服務傳送構造的測試回應標頭。

準備四個隔離案例:

  1. 有效的 max-age 指令;
  2. 測試父網域上的有效 includeSubDomains 指令;
  3. 名稱只以 includeSubDomains 開頭的未知 token;
  4. max-age 開頭的未知 token,後面再放一個有效 max-age

使用合成主機名稱和很短、固定的測試週期。保持憑證與主機名稱驗證啟用,並記錄用戶端版本、HSTS 快取身分、輸入協定、實際協定、目標連接埠、代理模式、連線重用及最終結果。

升級流程可參考代理連線池年齡測試,TLS 設定隔離可參考代理 TLS 信任設定指南

升級後的預期結果

在 curl 8.22 或包含修復的供應商版本中:

  • 有效 max-age 案例依預期建立或更新政策;
  • 有效子網域案例只在受控父網域政策下生效;
  • 較長的子網域相似名稱被當成未知項目,不啟用子網域政策;
  • 較長的 max-age 相似名稱被忽略,後續精確 max-age 仍可處理;
  • HTTP 到 HTTPS 的升級在代理及 TLS 階段前可見;
  • HTTPS 憑證與主機名稱驗證維持啟用。

每個案例先使用全新快取執行,再用同一快取重複。沒有保存快取的新程序作為對照。若差異只在狀態重用時出現,應先檢查快取來源與政策期限,而不是歸因於代理路徑。

觀察完整請求路徑

記錄測試編號、curl/libcurl 版本、測試案例名稱、HSTS 快取的建立/載入/重用狀態、輸入與實際 URL 協定、目標主機及連接埠類別、HTTP 代理/CONNECT/SOCKS 路徑、新建或重用連線、TLS 驗證結果、重新導向次數、最終回應驗證,以及快取更新或到期結果。

不得記錄 Cookie、Token、代理密碼、私鑰、客戶 URL 或完整瀏覽紀錄。測試環境不得包含正式身分和資料。

在不隱藏狀態的前提下升級

確認服務程序實際載入的 libcurl,包括容器、靜態程式、語言繫結和 sidecar。升級至 curl 8.22.0,或供應商明確記錄包含該修復的版本。

滾動升級時依用戶端版本區分測試 HSTS 快取,以便比較新舊解析結果而不混合狀態。依變更流程重啟或排空工作程序,同時保留一個受控的升級前測試工件作為對照。不要把正式瀏覽狀態複製到測試環境。

上線後監控異常協定升級、CONNECT 比例、TLS 失敗、目標連接埠變化、HSTS 快取寫入及通過內容驗證的成功率。健康部署應保留真正有效指令,並忽略較長的相似名稱。

驗收清單

  • [ ] 服務程序使用 curl/libcurl 8.22.0 或已記錄修復的版本。
  • [ ] HSTS 快取位置與擁有者明確。
  • [ ] 精確指令與相似指令分別測試。
  • [ ] 子網域相似名稱不會啟用子網域政策。
  • [ ] max-age 相似名稱不會阻斷後續有效指令。
  • [ ] 輸入與實際 URL 協定都有記錄。
  • [ ] 代理模式及目標連接埠有記錄。
  • [ ] TLS 憑證與主機名稱驗證維持啟用。
  • [ ] 已比較新快取與重用快取結果。
  • [ ] 連線重用不會掩蓋政策變化。
  • [ ] 日誌不含憑證與正式瀏覽資料。

常見問題

代理會替 curl 解析 HSTS 嗎?

不會。curl 的 HSTS 行為發生在用戶端;所得的協定與連線變化接著才決定代理需要承載什麼流量。

未知 HSTS 指令會讓整個回應標頭失敗嗎?

本次修復確保較長的相似 token 進入未知指令路徑,同時繼續處理已辨識的指令。仍應測試應用程式實際依賴的用戶端行為。

此修復能取代憑證驗證嗎?

不能。HSTS 可以觸發 HTTPS 升級,但用戶端仍必須依信任政策驗證憑證鏈與主機名稱。

每次升級都必須清空 HSTS 快取嗎?

不一定。應保留預期政策,但測試狀態需要版本化及受控,避免舊解析結果讓回歸結論含糊。正式快取處理應遵循安全與變更流程。

來源與合規說明

內部研究依據:curl 專案於 2026 年 9 月 2 日發布的 curl 8.22.0 公告;curl 專案「hsts: match complete directive names」變更,於 8 月 23 日提出、8 月 26 日合併;HTTP 嚴格傳輸安全規範。外部資料 URL 只保存在內部營運記錄,公開文章不含外部連結。

只對自己擁有或獲准評估的網域、端點、憑證及路由執行解析器和代理測試,並遵守隱私、服務商限制、服務條款與組織變更流程。