單元 14 TLS、HTTPS 與可見資訊
學習目標與問題
先讀 13。你應能追蹤經驗證的 TLS 連線，區分憑證鏈與名稱驗證，說明 SNI／ECH 及 0-RTT 限制。連線能加密，不代表連線的是預期對象。
14.1 TLS 保護的端點
HTTPS 以 HTTP 承載在 TLS 等安全傳輸上。TLS 通常提供伺服器身分驗證、保密及完整性；客戶端憑證驗證屬於另行設定。網頁帳號密碼是應用登入，不等同 TLS 客戶端認證。TLS 終止在反向代理／CDN 時，該裝置可讀 HTTP 明文，往後一段需獨立分析。
14.2 TLS 1.3 握手概念
以非 PSK、臨時金鑰協商的一般握手為例，ClientHello 提供版本、key share 等；ServerHello 選參數並建立握手 key；後續包含憑證、簽章和 Finished 等，確認身分與 transcript。TLS 1.3 大部分後續握手已加密。重試、恢復、PSK 及客戶端認證使流程變化，圖解要先寫所採情境。
TLS 用記錄層保護應用 bytes，記錄邊界不等於 HTTP 訊息或 TCP recv 邊界。QUIC 使用 TLS 的握手與金鑰協商，但不是把完整 TLS 記錄層再套在 UDP 上；其封包保護由 QUIC 完成。
14.3 憑證鏈與名稱
驗證至少需要可信根／設定、鏈、有效期、用途與預期名稱。連線 localhost 時，即使伺服器憑證由可信來源簽署，SAN 不符合 localhost 仍應失敗。SNI 讓服務端知道希望連到的名稱；SNI 提供名稱不表示客戶端已驗證回傳憑證。IP 位址也有對應的 SAN 型別，不能以任意 DNS 名稱憑證自動通過 IP 驗證。
L13 只把實驗憑證加入該 Python SSLContext，不修改 OS 信任庫。對錯誤名稱和預設不信任分別做負面測試。停用驗證可讓錯誤消失，卻同時放棄預期的安全性，不能當成修復。
14.4 SNI、ECH 與中間節點可見性
沒有 ECH 時 ClientHello 通常可暴露 SNI 及其他協商資訊；TLS 1.3 本身不自動隱藏 SNI。ECH 已於 RFC 9849 標準化，但實際成功依賴客戶端、服務端、設定發現與網路支援。即使 ECH 成功，目的 IP、封包大小、時間、外層 ClientHello 的 public_name 及其他管道仍可能透露資訊。若 DNS 未加密，名稱查詢也可能暴露。
| 觀察位置 | 通常能看到 | 是否能看到 HTTP 內容 |
|---|---|---|
| 本地應用 | URL、名稱、內容 | 能 |
| TLS 前的本地 proxy 入口 | 若 CONNECT，含目標 host:port | 不終止內層 TLS 則不能直接讀取內容 |
| 客戶到 proxy 路徑 | proxy IP、流量後設資料（metadata）；未保護協定可能暴露更多 | 看保護範圍 |
| proxy 出口 | 最終目的 IP 及相關協商 | HTTPS 正常端到端時仍不讀 HTTP 明文 |
| 終止 TLS 的伺服器／CDN | 解密後請求與回覆 | 能 |
14.5 恢復與 0-RTT
會話恢復可降低後續握手成本；0-RTT early data 在完成新握手前送資料，有重放風險，並不具有與正常 1-RTT 資料相同的前向保密條件。應用需決定哪些操作可安全重試／重放。支付、修改狀態等不能只因它「比較快」就允許重複執行。效能報告還需分開首次連線、恢復、early-data 被接受或拒絕。
實驗、習題與檢核
做 L13 的正確名稱／錯名稱／未信任三項。記錄錯誤類別，不要求各系統完全相同文字。
- 可信憑證為何仍可能名稱驗證失敗？
- TLS 1.3 是否一律隱藏 SNI？ECH 保護後仍可見什麼？
- 代理若不終止目標 TLS，可以看到哪些目的資訊？
- 為什麼應用要另行處理 0-RTT 重放？
檢核：能在拓樸上標示 TLS 起點、終點與信任根。QUIC/TLS 整合見 RFC 9001；HTTP early data 處理見 RFC 8470。來源：RFC 9846、RFC 9525（服務身分）、RFC 9849（ECH）、Python ssl 文件。
TLS 版本註記：2026 年修訂的 RFC 9846 取代 RFC 8446，協定版本仍為 TLS 1.3；ECH 參考 RFC 9849。