TLS 如何實際保護 HTTPS 連接？

人們說「HTTPS 表示加密」就到此為止，但有趣的部分是兩個互不認識的網路陌生人如何在充滿可能竊聽的網路上達成共同的祕密，而無需見面。這就是 TLS 的作用，如果你接觸網路、網頁開發或安全性，這些機制值得理解。

逐步握手

當你的瀏覽器連接到 https://example.com 時，大致會發生以下情況（TLS 1.3，大多數網站現在使用）：

1. ClientHello — 瀏覽器送出支援的密碼套件、隨機 nonce，以及對金鑰交換的金鑰分享猜測（使用類似 X25519 或 secp256r1）。
2. ServerHello — 伺服器選擇密碼套件，送出自己的金鑰分享，並返回其憑證加上簽名以證明持有與該憑證相符的私鑰。
3. 金鑰衍生 — 雙方現在各自獨立利用其金鑰分享上的 Diffie-Hellman 式數學計算出相同的共同祕密。雙方都不會傳輸祕密本身；它是衍生出來的，而非傳送的。
4. Finished 訊息 — 雙方透過在整個握手記錄上送出 MAC 確認握手未被竄改。

之後，所有內容都使用從共同祕密衍生出的對稱金鑰加密，通常是 AES-128-GCM 或 ChaCha20-Poly1305。TLS 1.3 將 TLS 1.2 的雙往返握手縮減為有效的單一往返，這在大規模使用時是真正的延遲優勢。

為什麼憑證的重要性超過加密

沒有身份驗證的加密毫無意義 — 任何人都可以建立加密通道，包括執行中間人攻擊的攻擊者。憑證將公鑰綁定到網域名稱，並由憑證授權機構（CA）如 Let's Encrypt 或 DigiCine 簽署。

你的瀏覽器信任已嵌入到作業系統或瀏覽器信任儲存中的固定根 CA 清單。伺服器的憑證透過中間憑證鏈結到這些根之一。如果鏈結驗證失敗，或憑證中的網域與你要求的不符，你會看到紅色警告頁面。這個信任鏈模型是實際的安全邊界 — 竊取 CA 的簽署金鑰，你就能為任何網域簽發有效憑證，這就是為什麼 CA 洩露被視為重大事件。

對稱與非對稱加密在此的作用

非對稱加密（RSA 或橢圓曲線）速度慢且昂貴，所以 TLS 只在握手期間使用它 — 用於驗證伺服器和幫助建立共同祕密。完成後，所有實際資料（HTML、JSON，無論什麼）都以快速對稱密碼加密。這種混合方法是你在 SSH、PGP 和大多數真實世界加密系統中會看到的相同模式：用非對稱加密進行身份和金鑰交換，用對稱加密進行大量資料。

前向保密是值得了解的相關細節：因為共同祕密來自每個工作階段新生成的暫時 Diffie-Hellman 金鑰分享，即使有人記錄你的流量並稍後竊取伺服器的私鑰，他們仍無法解密舊工作階段。舊版僅 RSA 金鑰交換中不存在此特性。

自己檢查

你不需要盲目信任綠色掛鎖圖示。執行：

openssl s_client -connect example.com:443 -tls1_3

這顯示你協商的密碼套件、憑證鏈和握手是否實際完成。若要快速查看瀏覽器看到的內容，curl -v https://example.com 會在 HTTP 回應前列印 TLS 版本和憑證詳細資訊。

你也可以在啟動 Chrome 或 Firefox 前匯出 SSLKEYLOGFILE 環境變數，在 Wireshark 中解密自己的流量 — 對於偵測 TLS 問題非常有用，而不必猜測。

這在實踐中實際上在哪些地方出現問題

大多數真實世界的 HTTPS 故障不是密碼學破裂，而是操作上的：過期憑證、配置錯誤的中間鏈、停留在舊 TLS 版本的用戶端，或混合內容（HTTPS 頁面載入 HTTP 資源）。對現代 TLS 1.3 的實際協議級別攻擊很少見，因為規範關閉了困擾 SSL 3.0 和早期 TLS 的大部分填充 oracle 和降級技巧。現在的弱點通常在端點 — 遭到洩露的 CA、竊取的私鑰，或使用者點過他們不應該點的憑證警告。

如果你想進一步了解，Korra Studio 的網路和加密部分涵蓋基礎 Diffie-Hellman 數學和封包級協議分析的更多深度。